Solution Contract Before Any Build

Why this matters

Most AI builds start with a tool or a demo and then try to reverse-engineer the requirements. That produces brittle systems — ones that cannot be evaluated, constrained, or safely changed, because nobody ever wrote down what they are supposed to do. Before you build anything, write a clear contract for what the system is allowed to do. The contract is what the rest of this pack hangs on: the permission list, the agent boundaries, the acceptance criteria, and the verification record all answer to it.

What you will be able to decide after this

Whether the system's job is precise enough to build, evaluate, and change.
What the system may and may not do — and where the ambiguity is.
What "good" means, well enough to measure against.

Core lesson

A useful solution contract includes ten elements. Each one has to be checkable:

User and trigger — who starts it, and what event starts it. Not "employees"; "a case manager submits a form with the escalation field completed."
Desired result — the outcome, written the way the user would describe it.
Authoritative inputs it may use — the sources it is allowed to read, named.
Output schema or format — what the output looks like, field by field.
Quality and acceptance criteria — the measurable bar for "good."
Explicitly prohibited behavior — the things it must never do, named.
Permissions and tool access — what it may touch.
Human decision points — where a person must act before the work proceeds.
Fallback when it cannot complete the task — what happens when it cannot do the job.
Latency and cost expectations — how fast, and how expensive, is acceptable.

If the contract is boring and precise, the build is more likely to stay safe. The tell is whether a sentence can be checked. "Produces high-quality replies" cannot be checked. "Drafts a reply between 40 and 200 words, citing only the two approved source documents" can be. Every element of the contract should survive the question "how would I know this was violated?"

Worked example

A team wants an agent that answers internal support questions. The demo was impressive. The contract is the correction. User and trigger: an employee submits a question in the internal portal. Desired result: a draft answer with citations, ready for human review. Authoritative inputs: the two approved knowledge bases, nothing else. Output: 40–200 words, numbered citations, plain text. Quality criteria: 90% of drafts accepted with minor edits in a pilot; every citation traceable to the named source. Prohibited: no creating tickets, no contacting customers, no answering from anything outside the two knowledge bases, no claiming a human reviewed it. Permissions: read-only on the two bases; no write; no send. Human decision points: a named team member approves before any answer goes out. Fallback: if it cannot answer from the sources, it says so and offers the escalation path — it does not improvise. Latency and cost: under ten seconds, under a defined per-draft cost. Then the verification pass catches the classic: the demo's ticketing integration would let the agent create tickets "when needed." The contract does not allow that, so the integration is cut from the build. The contract just saved the project from its own demo.

Practice

Take a use case you care about. Write only the first two elements — user and trigger, and desired result — as checkable sentences. Rewrite anything that cannot be checked.

Apply — produce the artifact

Write the one-page solution contract for a real, bounded use case you care about. Leave no major ambiguity about what the system may and may not do.

Verify

Have someone who will live with the consequences read the contract. If they can find a way the system could take an action you did not intend, tighten the prohibitions and permissions.

Sources

This module is original practice guidance based on the authoring standard and does not depend on a specific external factual claim. Editorial review is still required.