What a published workflow is
When you publish from the canvas, what leaves is the structure: the nodes, their connections, their settings. Your final frames stay yours unless you choose to include some as examples.
Somebody who opens it gets a working graph they can run, change and build on — the shape of your thinking rather than a result they can only admire. They can see which reference feeds which shot, what you held constant and what you let vary, and that is the part that is actually teachable.
It is also the part that survives. A striking image from eighteen months ago is a historical artefact. A graph that solves character consistency is still solving it, against whatever model is current, because the structure was never the model-specific bit.
How it works today
Build it in the canvas
Any project can become a workflow. The ones that travel well have clear inputs — an obvious reference slot somebody can swap for their own without reading a manual.
Publish
From the canvas, choose what to include: structure always, example frames only if you say so, a description in your own words.
It appears in Explore
Other people find it, run it and build on it. Use counts and likes are visible to you on your own workflows.
You keep the credit
Attribution stays attached wherever it is used or forked. Somebody who builds on your graph is visibly building on your graph.
You keep improving it
A published workflow can be updated. Versioning that does not break the graphs people built on top of yours is on the roadmap under Next.
What makes a workflow worth publishing
Observed from the ones people actually run.
- It solves one problem
- A graph that does character consistency well beats one that does six things adequately. People come looking for a specific problem.
- The inputs are obvious
- One clearly named slot for the thing the user supplies. If somebody has to reverse-engineer where their own image goes, they will close it.
- It is documented in the description
- What it does, what to put in, what to expect out, and what it is bad at. The last one earns more trust than the first three.
- It degrades sensibly
- It should still produce something reasonable with a mediocre input, because most inputs are mediocre.
- It is one you actually use
- The best published workflows are the ones people built for their own work twice, then cleaned up. Workflows built to be published rarely survive contact with a stranger.
The creator programme
Credits for use
Workflows other people actually run earn credits back to the author. The rewards ledger records what was earned and why, entry by entry — it is a ledger rather than a number that changes without explanation.
Featured placement
A small number of workflows are featured in Explore. Chosen by people on the basis of whether the thing is good, not by volume of output or recency.
Early access
Programme members get new node types and model routes before general release — and are expected to say clearly when they are bad, which is the actual point of the arrangement.
A direct line
A channel to the people building the product. What breaks for you gets fixed sooner because you can say so to somebody who can fix it.
There is no application form. Publishing workflows that people use is the qualification, and we reach out. If you think you should be in it and are not, write — that is not an awkward thing to do.
Earnings
| Status | Detail | |
|---|---|---|
| Credit rewards | Live now | Earned when others run your published workflow. Spendable on generation. Every entry visible in the rewards ledger with its reason. |
| Featured placement | Live now | Curated by people. No payment involved in either direction. |
| Cash revenue share | Not open | The direction. Terms will be published in full before anyone is asked to opt in. |
| Payouts | Not open | No payout mechanism exists yet. There is no button that would take your bank details. |
When revenue share opens, these are the things that will be published before it does, because they are the things that determine whether it is worth participating in: the split, the payout threshold, the schedule, what counts as a qualifying run, and what happens to accrued earnings if a workflow is removed or if you leave.
We would rather say that plainly now than ship a payout button that does nothing and let people plan around it.
Questions
Who owns a published workflow?
You do. Publishing grants other people the right to run and build on it inside the product; it does not transfer ownership and it does not let anyone resell it as their own.
Can I unpublish?
Yes. Existing copies people have already opened into their own canvas remain theirs — that is a copy, not a link — but it stops appearing in Explore.
What if somebody forks mine and it gets more popular?
Attribution to the original stays attached through forks. That is the mechanism, and it is deliberately visible rather than buried in metadata.
Do you take a cut of anything today?
There is nothing to take a cut of. Credit rewards flow to authors; no money changes hands between creators and us in either direction.
Can I publish a workflow that uses a client's material?
Publish the structure without the references and you are publishing your method rather than their assets. Check your client agreement anyway — method can be covered too.