Intake: what a run asks you for

Before a run starts, YAMO asks you for whatever the Playbook says it needs. That list is not improvised: a Playbook declares its inputs in its own document, so the questions are the same every time and you can read them before you ever run it.

Two kinds of input

• Run inputs are asked every time. The URL SEO Audit template asks for one: the page to audit.
• Config inputs are set once for the Instance and reused. They are part of setting the work up rather than part of doing it, so a scheduled run has everything it needs when nobody is there to type.

An input can also carry a default, which is what makes an unattended run possible. A recurring Playbook ships defaults precisely so its schedule can run without you, and setting them to your own values before switching a schedule on is part of the setup rather than an optional polish.

The types an input can be

Nine, and each one changes what you are asked for:

text, longtext, number, date, choice, url, file, files, and connection.

A choice input offers the options the Playbook declared. A file or files input takes an upload, which is stored against your Instance. A connection input resolves against a tool you have already authorised, so you pick rather than type.

The builder can currently author five of those nine: text, longtext, number, date and url. The other four are honoured at run time and read correctly from a definition that declares them, but there is no control for adding one to a Playbook you are writing.

How you are asked

The Instance conversation walks the list one question at a time, acknowledges each answer, and shows you how far through you are. It is a deterministic walk rather than a chat: the questions come from the contract, in order, and nothing is invented in between. If it helps, you can answer several at once by labelling them, one per line.

The declared intake mode in a Playbook's document is shown on its page and on the Service, but nothing at run time branches on it today. Every Instance is taken through the same walk.

When something is missing

A required input with no answer stops the run before it starts, and before anything is charged. The conversation says which one it was and asks again, rather than proceeding with a gap. The same is true of an answer that does not fit its type: a url that is not a URL and a date that is not a date are both refused with the reason, and the walk waits.

That is the rule the whole runtime follows. Missing information produces an honest request or an honest failure. It never produces invented data.