Jobs and plans

A job is one process that runs: its trigger, its plan, the tools it may use, its limits and its ROI fields.

The plan

Before a line of code exists, the job is written as a plan in plain language. It contains:

• The steps, each with what it reads and what it writes.
• The fields, as a table: what is written where, and where each value comes from.
• The decisions, with the way out for each one. See Three ways out.
• The guarantees: what will never happen, whatever the input.
• The open questions, where the plan needs an answer from you.

You approve it, or you ask for changes. Asking for changes rewrites the plan; it does not patch it.

Why the plan and not the code

You cannot review code you did not write, and a screenshot of a canvas does not tell you what happens when a field is missing. A plan in your own vocabulary is the thing you can actually hold somebody to, and it is what the platform measures the job against later.

Taking over an existing flow

If the process runs today in another tool, the existing flow is read and documented as it really runs before anything is rebuilt. When the new job goes live, the old flow is listed and switched off deliberately, not left running in the background. The platform asks for that list before a job that replaces something is switched on for the first time.

Changing a job later

Every change goes the same way: plan, approval, measurement. A job that is already live keeps running while the change is prepared.