Artifacts: what a run produces
The run folder and everything in it: the inputs it was given, each step of the work, the finished deliverable, and the receipt that itemises the cost.
On this page
Every run keeps its evidence. Not just the finished piece of work, but what it was given, what each step produced along the way, and what it cost. That collection is the run folder, and it is what makes a run explainable after the fact rather than a result you have to take on trust.
What the folder holds
- The inputs snapshot. Exactly what this run was given, which is the first thing worth checking when a result is not what you expected.
- Each step's document, in order. The work between the input and the deliverable. The research notes and the written report are separate documents because they were separate steps.
- The deliverable. Identified separately from the working documents, so "the outcome" is never a matter of scrolling to the last thing.
- The receipt.
A Playbook can also declare named outputs rather than one document, and then a run produces each of them as its own file with one marked as the primary deliverable. The Content Engine template does this: a content pack plus the article and the social posts, separately.
What you see, and what you can take away
Finished work is rendered in place. A document is rendered as a document; a data file with a table in it is rendered as a table with the first rows shown and a note about how many more there are.
Four other output kinds can be declared and are rendered as plain documents with a line saying so, because the delivery behind them is not built yet. That label is deliberate: a page that rendered an unbuilt channel as though it had been delivered would be lying about work that did not happen.
Downloads are Markdown. There is no PDF, spreadsheet or archive export.
The receipt
If the run was of your own Service, the receipt is itemised, in two groups kept deliberately apart: the model cost, at what we paid for it with no markup, one line per step; and the platform operations, priced per operation. The total is rounded up to the nearest penny, once.
If the run was of somebody else's published Service, the receipt is the price you agreed, once. There are no cost lines, because those are the platform's cost basis and the operator's margin rather than anything you bought.
Token counts are shown as a transparency readout. You are never billed per token.
More in Run
Related
Intake: what a run asks you for
How a run collects what it needs: the input contract, the difference between what is asked every time and what is set once, and what a missing answer does.Triggers: what starts a run
The four ways a run begins on YAMO: someone confirms it, a schedule fires, an approved agent calls it, or an approved run picks up where it paused.Schedules: running on a cadence
How a Playbook carries a cadence, what a scheduled run does differently, how to pause one, and the honest state of changing a cadence today.Approvals: pausing before an action
What an approval gate does to a run, who is allowed to decide, what a rejection means, and why approving is not the same as the action succeeding.Delivery: where the outcome lands
How finished work reaches you: in the work rail beside the conversation, and by email with the deliverable in the body. What is live, and what is not.Pricing
How YAMO charges: you pay for the runs you make, and nothing for the ones you do not. What a run is, what it includes, and what publishing costs.Who it's for
The six kinds of expert YAMO is built for, and what changes when the method you already follow becomes a Service that somebody else can run.
Open a Playbook that does this
Every template in the library publishes its contract and a real example output.