Lessons 84.1 and 84.2 mapped the operation and found the constraint. Now someone — you, a colleague, an automation platform, an agent — is about to build something that acts on its own. Enthusiasm is high and specifications are vague. That combination causes most automation damage.

The fix is a contract written before anything is connected: a short, implementation-ready document that bounds the workflow completely.

The contract's vocabulary

• Trigger. The event that starts a run. Two kinds: a webhook (another system calls you — "payment completed") or a schedule (time calls you — "every Monday at 9:00").
• Input schema. The exact fields the workflow may accept, with types and required-versus-optional marked. Anything not in the schema is rejected, not guessed at.
• Action. The bounded thing the workflow does: validate, file, summarize, queue. Bounded means listed in advance, not invented at runtime.
• Output. The observable result: a queued item, a filed record, a sent confirmation.
• Log. The run record: when it ran, what input arrived, what it did, what came out. Lesson 84.5 will read these logs.
• Exception. Anything outside the expected path: malformed input, vendor timeout, duplicate event, ambiguous content.
• Owner. One named human accountable for the workflow's behavior.
• Escalation. Where exceptions go, and how fast: a review queue, a message to the owner, a pager — never silence.

The core pattern

Every contract in this part follows one sentence:

Read it as four gates. No approved input, no run. Action outside the bounds, no execution. Output nobody can observe, no deployment. Exception with nowhere to go, no launch. A workflow missing any gate is a proposal, not a system.

Sonariq: trigger validation, not publication

The Sonariq research desk is the running example. When source collection completes, that event could — recklessly — trigger autonomous publication of a findings report. It must not. Collection finishing is evidence that material exists, not that conclusions are correct.

The correct contract: completed collection triggers validation (are all required sources present, cited, and fresh?) and then places the draft in an expert review queue. Publication stays behind a human approval gate, which Lesson 84.4 will design. The automation does the tedious, checkable part — completeness, formatting, deduplication — and deliberately stops where judgment begins.

This is the difference between "automate the workflow" and "automate the checkable steps inside the workflow." The contract forces you to say which is which, in writing, before credentials are issued.

Contracts also age, which is why the owner and review cadence are fields, not footnotes. A workflow that was correct in January can be wrong by June: the vendor changed its payload, the schedule collides with a new process, exception volumes tripled and the escalation inbox overflows. The contract review — monthly for young workflows, quarterly once stable — re-reads the logs against the bounds: did every run stay inside its actions, did exceptions reach their targets in time, do the NEVER permissions still hold given what the workflow can now reach? Lesson 88.5 will turn this into a full thirty-day automation review; build the habit here while the workflow is small enough to hold in your head.

Exercise: write your AUTOMATION-CONTRACT.md

Pick the constraint-adjacent step from Lesson 84.2 — something repeated and understood. Write the contract:

# AUTOMATION-CONTRACT — [workflow name]

- Trigger: [webhook event or schedule, with source]
- Input schema: [fields, types, required/optional]
- Bounded actions: [numbered list — nothing else permitted]
- Output: [observable result + where it appears]
- Log: [what is recorded per run + where logs live]
- Exceptions → escalation: [each failure case → where it goes, response time]
- Owner: [one named human]
- Review cadence: [how often the owner audits runs]
- NEVER permissions: [actions and data this workflow must never receive]

The NEVER section is the most important lines in the file. Examples: never send a public claim without review approval; never move money; never change account permissions; never publish to the customer-facing site; never read or store credentials outside the secret manager. Write them as prohibitions a reviewer can test, not vibes ("be careful with customer data").

Finish line: a specification detailed enough that a competent builder — human or AI — could implement the workflow without asking what it is allowed to do.

Verify: for each bounded action, ask "what credential does this need?" Then check the NEVER list against those credentials. If a credential would permit a NEVER action, the scope is too broad — narrow it before building. Least privilege is Lesson 88.3's subject; practice it here first.

Common failure mode: writing the happy path only. List at least five failure cases: malformed input, duplicate event, vendor delay, unexpected reply, ambiguous content. Each needs an escalation target. Lesson 88.4 will expand this into retries and runbooks.

Check your understanding

1. Why must the input schema reject unexpected fields rather than ignore them? 2. Give one Sonariq example of a safe bounded action and one action that must stay behind review. 3. What makes a NEVER permission testable rather than decorative?

Next, Lesson 84.4: the contract says where automation stops. Now design what waits on the other side — the human loop, with queues, gates, and a green-amber-red map of every step.