Writing a process

A process is plain text that a person, an agent and an auditor can all read. A useful one needs only the fields below, and you add the rest when the work calls for them. The offboarding example uses exactly these fields.

Start with these

1. The headerIt gives the process's name, its id and version, its owner, and the date this version took effect.
2. The triggerIt says in one plain sentence what starts a run, and a concurrency line says whether two runs may overlap.
3. Named stepsEach step has a name, a kind, an owner, and an after: line naming the steps it waits for.
4. The closing stepOne step closes the run, and a goal line says what is true once it has.
5. Automation levelsEach step carries one of manual, assisted, supervised, autonomous or never.
6. HandoffsEach handoff says what one step hands to the next and what it has to contain.
7. RecordsA records list says what a finished run leaves behind, so anyone can check it later.
8. The versionEvery change that alters how a run goes gets the next version and a new effective date, with a line saying why.

Kinds of step

• A person's stephuman: A person acts outside any system.
• A system's stepsystem: A system does something, such as a payroll run, a scheduled post or a record written.
• A step an agent works out on its ownharness: <what the agent works out> The process hands the step to an agent that runs its own loop and owes only the output the step names, as described under Where Agent Processes fits.
• A step worked in a shared roomconvenes <collab pattern>: Agents and people work the step together in one room, following an Agent Collab playbook.

Add these when you need them

The specification defines more. Each of these serves a situation some processes have, and none is needed to start.

• A step can carry deadlines, with by: and not-before:.
• A step can run another process and wait for it to close.
• Exception and deviation edges say where a run goes when a step cannot finish.
• Run-scoped lines cover work that lasts the whole run, such as a weekly status report.
• Bindings say who holds each role, which systems a run may touch, and what it reads.
• Policy lists the legal, compliance and brand rules a run is held to.
• Measures say what a good run looks like.
• Handoff keys and record keys give software stable names to store.
• Failure edges say what to undo when a run is abandoned.
• Reference processes are published with blanks for an organization to adopt.
• A step held by an outside agent can name the agreement it runs under.
• A process can span two organizations.

Next: The specification