What one run includes
A run is one execution of a Playbook, from the trigger that started it to the artifact it returns. It is also the unit that gets metered and receipted.
On this page
A run is one execution of a Playbook, from whatever started it to the artifact it returns. It is the smallest thing on the platform that a person cares about, and it is the unit that gets metered, receipted and charged for.
What happens inside one
Four things, in order, and each of them was declared in the Playbook before any run existed.
| Stage | What happens |
|---|---|
| Trigger | Somebody asks for a run, or a schedule or event asks for one |
| Intake | The run collects what it was told it needs |
| Plays | The ordered steps execute, each handing on to the next |
| Delivery | The artifact arrives where the contract said it would |
An approval gate, where the Playbook has one, sits between the Plays and the delivery: the run pauses and waits for a person to authorise what happens next. Nothing about that is decoration. It is where an owner keeps a judgement call they are not willing to give away.
Why the run is the billable unit
Because it is the only unit that maps onto work. A Service that nobody runs has produced nothing, and a Service that runs two hundred times has produced two hundred artifacts. Charging for the middle thing, the account or the seat, makes the price a guess about volume rather than a measurement of it.
If you are not running it, you are not paying for it.The consequence
What the receipt is for
Every run leaves a record of what it did. That record is what makes an automation claim checkable rather than asserted: you can look at the run, see the Plays that executed, and see the artifact they produced.1
This is also the honest limit of what a run can promise. A Play that reads a source which was unavailable produces a run that says so, rather than a run that quietly produced less.
Notes
- 1The same principle applies across the product. Every claim about work being done sits next to something you can inspect: an approval, the step list, or an example output on the template's own page. ↩
Read next
From Playbook to published Service
Publishing turns a Playbook into a Service that other people can pay to run. What the public contract says, and what a customer gets when they buy.Connectors and Connections are not the same
A Connector is the tool a Playbook says it needs. A Connection is the authorisation that lets a run reach it. Two words, and the difference matters.The method is the asset
An expert who has delivered the same outcome enough times owns a method. Doing the work again by hand for every customer is what that method costs them.What a Playbook actually is
A Playbook is the method an expert captures, written down as a document the runtime follows. What goes in it, what a Play is, and what stays yours.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.
Read a Playbook that does this
Every template in the library publishes its contract and a real example output.