Mission contracts

A mission contract says what correct means for one mission. It is a list of clauses, and Madebook checks them continuously against what was actually reported.

You reach it from a mission's Mission info → Contract tab.

What correct means for this mission, in clauses the system checks continuously.

The six clause kinds

Kind	Heading on the page	What it says
success	Must become true	The outcome.
preserve	Must not break	Something that already works and must keep working.
forbidden	Must not be introduced	Something that must not appear.
architecture	Shape it must follow
security	Security properties
proof	Evidence required	What has to demonstrate it.

A contract needs at least one proof clause to be approved. Without one, "done" can never be computed, only claimed.

Machine checks

A preserve or forbidden clause can carry a check Madebook runs itself.

Check	Value	What it proves
dependency_absent	A package name	Nothing matching it was added to a manifest.
import_absent	A string	Nothing matching it was touched.
symbol_unchanged	A symbol	Its public shape is the same.
path_untouched	A path prefix	Nothing under it changed.

The dialog's guidance is direct:

Prefer a clause a machine can check to one a person must judge.

A clause with no check is prose, and the page labels it: "prose — needs a person's judgment."

A proof clause carries an evidence kind instead: unit test, integration test, browser run, security review, or human review.

Clause states

State	Badge
satisfied	green
violated	red
unverifiable	amber
unverified	grey

What each state's detail says

The verifier writes the reason in plain words. These are the exact forms:

Proof clauses

• "No unit test evidence has been recorded."
• "{label} failed: {detail}"
• "{label} passed (12/12) — signed off by a person." / "— observed by Madebook."
• "The agent reported "{label}" passing, but nothing independent confirmed it. A reported pass is a claim, not proof."

Machine checks

• "redux was added to the dependency manifest." / "No dependency matching "redux" was added."
• "src/Auth/Token.cs matches "auth/"." / "Nothing matching "auth/" was touched."
• "ClaimsService.GetDocument changed shape — returns ExportResult, not Stream." / "ClaimsService.GetDocument still has the same public shape."
• "src/Legacy/Claims.cs was modified." / "Nothing under src/Legacy/ was changed."

The other states

• "No change set has been reported for this mission yet."
• "This clause is written in prose with no machine-checkable form. It needs a person to confirm it, or a check that expresses it."
• "This was attested against an earlier change set. The work has moved since, so the attestation no longer applies — someone needs to look again."

Attestation

A prose clause can be signed off by a person holding mission.attest — owner, admin or member. An icon appears on prose clauses only, titled "Record your judgment on this clause", and asks what you checked before offering Satisfied or Violated.

Two things are refused:

• A proof clause: "This clause is satisfied by evidence, not by attestation. Record the evidence instead."
• A clause with a machine check: "This clause has a machine check. Its result stands — attestation is only for prose clauses."

An attestation goes stale when the work moves. If it was made against an earlier change set, it no longer applies and somebody has to look again.

Verification

Verify work is done on the mission. It is disabled with no change sets reported:

No change sets have been reported yet — there is no work to check against the contract

The result is either "The work satisfies the contract" or:

Not done yet — the contract is not satisfied. The clauses in Mission info say what is missing.

What "satisfied" means, exactly

Every clause must be satisfied. Zero violated, zero unverifiable, zero unverified, and at least one clause.

An unverifiable clause blocks exactly as hard as a violated one, because "we could not check" is not "it is fine."

Each verification also records deterministic coverage — how much of the contract a machine checked rather than a person judging. The history panel keeps the last ten.

A contract with violated clauses raises an attention item. If any of them is a forbidden clause, the disposition is intervene at urgency 90; otherwise decide at 72.

How a contract is generated

Two layers, and the first one runs whether or not a model is available.

Layer one: the deterministic skeleton

• Each of the first 12 acceptance criteria becomes a success clause.
• Each enforced rule of the current approved constitution that carries a conflict list becomes a forbidden clause with a dependency_absent check.
• Always at least one proof clause: "Unit tests for the new behaviour."
• An integration_test proof if a confirmed testing standard mentions integration.
• A browser proof if the workspace's kind is web or mobile.

Deterministic open questions are raised when there are no acceptance criteria at all, or when a criterion contains a word that does not decide anything — manage, handle, appropriate, properly, as needed, etc. At most four.

Layer two: the model, if one is approved

It rewrites the skeleton and adds preserve, security and architecture clauses, each with a cited reason. Between 1 and 30 clauses, at most 8 open questions.

Two corrections are applied whatever the model said: a machine check is kept only on preserve and forbidden clauses, and a proof clause with no evidence kind defaults to human_review.

With no model

There is no invention: the skeleton IS the draft, stamped as assembled without a model, at a fixed confidence of 40, with this note:

Assembled from the acceptance criteria and the constitution without a model. No preserve or security clauses were inferred — add the ones this change needs.

The mission page repeats it in the approval callout, and tells you what to do about it.

Versions

Every change to an approved contract bumps the version and returns it to draft. Every version is frozen as a snapshot with the reason it was made: created, generated, edited or approved.

Frozen copies — what a session was held to.

A session records the contract version it was briefed on. A version bump caps that session's mission-understanding health at 50, because what it was told is no longer what the mission says.

The approval callout

Until a contract is approved, the mission carries this:

Approval required — agents are locked out of {reference}

Nobody can point an agent at this mission until a lead approves contract v{n} — the agent API refuses the session outright. Approving is the human gate: it records that a person read every clause and vouches for what should be built.

The second paragraph depends on how the draft was made:

• Assembled without a model: "no preserve or security clauses were inferred. Read it in Mission info and add what this change needs."
• Written by a model: "Read every clause in Mission info — a clause you cannot justify is a clause to remove."
• Written by hand: "Read the clauses in Mission info before approving."

Test plans

From the contract and the change surface, Madebook can produce a structured test plan: cases with a title, an evidence kind, a priority, numbered steps and an expected result.

Each case can be linked to the evidence that covers it, so the plan doubles as the evidence checklist.

It is requested, not automatic — a button on the mission. Firing a model on every risk calculation would spend an organization's quota on changes nobody is reviewing yet.

A plan written against an older contract version is badged stale.

Madebook does not run your tests. Running customer test suites would mean executing customer code inside Madebook, and that is not something it does.

Related

• Missions
• Evidence and gates
• Architecture rules