Every automation in Part XVI rests on a contract from Lesson 84.3, extended by 88.4's failure cases, 88.3's permissions, and 88.5's review. This template collects all of it in one implementation-ready file. Fill it before building; no blank sections ship to production — write "N/A with reason" rather than leaving hope.

Template

# AUTOMATION-CONTRACT.md — [Workflow] — version ___ — date ___

## 1. Purpose (one sentence)
- When ___, do ___, so ___.

## 2. Trigger
- Type: event / schedule / manual — detail: ___ (link EVENT-FLOW.md for webhooks)
- Verification (for events): signature check ___ / dedupe key ___

## 3. Input schema (approved in)
- Required fields + types: ___
- Rejected inputs → ___ (error queue + reason logged)

## 4. Bounded action (exactly what it may do)
- Steps 1–n: ___ (each with green/amber/red per 84.4)
- Must never: ___ (explicit prohibitions — refunds, deletes, publishes, etc.)

## 5. Output (observable)
- Creates/updates/sends: ___ / Logged where: ___ / Customer-visible: ___

## 6. Permissions (per 88.3)
- Actor ___ may ___ / must never ___ / secret in ___ / revoke: ___

## 7. Failure cases (per 88.4 — all five)
1. Malformed: detect ___ → ___
2. Vendor delay: timeout ___ / backoff ___ / then ___
3. Duplicate: idempotency key ___ in ___ → on dupe ___
4. Unexpected: examples ___ → route ___ with ___ / SLA ___
5. Takeover: stop switch ___ / pulled by ___ / resume ___

## 8. Review queue
- Location ___ / fields ___ / owner + cadence ___ / aging → escalate ___

## 9. Measure (per 88.5)
- Baseline: ___ / 30-day review date ___ / owner ___ / verdict options noted

## 10. Signatures
- Builder ___ / Owner ___ / Approver ___ / Date ___

How to fill it well

Bound the action narrowly — "create CRM note and queue draft reply" rather than "handle billing." Name the never-list from real fear: the Sonariq example forbids autonomous publication; a support flow forbids money movement; a content flow forbids public posting. Each prohibition should map to a missing scope or an approval gate, so violation is impossible, not merely discouraged.

Set the review date at signing — thirty days out, owner named. A contract without a review becomes a permanent permission slip. Version the file; when the workflow changes, the contract changes first, then the implementation. Keep executed contracts in the OPERATIONS-PLAYBOOK folder (Part XVI completion artifact) alongside the map, scorecard, matrix, runbook, guardrails, and review agenda.

Worked mini-example (Sonariq intake)

Purpose: when source collection completes, validate the packet and queue it for analyst review — so nothing publishes unvalidated. Trigger: status field → collection_complete (system event, not chat message). Input schema: source list, dates, collection notes; missing sources → error queue. Bounded action: run validation checks, create review-queue item; must never publish or contact the requester directly. Failure cases: malformed packet → error queue with reason; validator slow → timeout 60s, retry twice, then human queue; duplicate event → packet-ID dedupe; unexpected analyst reply → route to lead; takeover → owner pauses intake via scenario switch. Review: weekly, analyst lead. This contract fits on two pages and any builder could implement it on n8n, Make, or Zapier without guessing.

Signing checklist (before build starts)

• [ ] Every section filled or marked N/A with reason — no blanks.
• [ ] Never-list maps to missing scopes or gates (technically enforced, per 88.3–88.4).
• [ ] All five failure cases have detectors, actions, and owners.
• [ ] 30-day review dated with a named owner (88.5).
• [ ] Builder, owner, and approver all signed. Unsigned contracts don't run.