---
title: "The Contract Keystone · Agentic Atlas"
description: "The Contract Keystone: contract ↔ verification ↔ re-dispatch."
canonical: "https://agentic-atlas.dev/nodes/the-contract-keystone"
last-updated: "2026-08-19"
---

# The Contract Keystone · Agentic Atlas

[← the survey](https://agentic-atlas.dev/atlas)

1. concept
   The Contract Keystone
   Hook
   contract ↔ verification ↔ re-dispatch
   Thesis
   An LLM-facing contract is persuasion, not enforcement, so verification moves as many clauses as possible from promise toward enforcement; the contract is not one foundational principle among many but the substrate that makes the other patterns safe to compose.
   Laws & fences
  - A declaration makes the mechanically expressible contract visible and an enforcement mechanism makes selected clauses structural; a model can read a beautifully documented contract and still hand back something off-spec; the boundary is aspirational until something checks it.
  - An acceptance criterion is what makes re-dispatch governable: with no legible expectation you cannot tell a bad result from a good one, cannot verify, and cannot safely re-dispatch.
  - Three premises compose: the contract makes checking possible, verification asymmetry makes it affordable, and effect discipline makes the recovery move legal; only the mechanically enforced clauses become guarantees, the rest gain measured assurance.
  - Re-dispatch is one tactical option after a failed check, not the proof that the seam is safe; the recovery may also be reject, adjust, fall back, or escalate.
   When to reach
  - Reach for it when a seam already runs on the instinct of verifying a sub-agent's output and re-running when it looks wrong; that instinct was already depending on an implicit contract the whole time, and naming the contract turns the instinct into a tool you can hand someone.
  - Skip it for the practice of writing a contract, the applied loop, or a premise's own failure boundary; the keystone owns how the three premises compose, and each of those belongs to its own node.
   Provenance
   [the-contract-keystone/definition-the-analogy-declaration-versus-enforcement](https://agentic-atlas.dev/nodes/the-contract-keystone#definition-the-analogy-declaration-versus-enforcement) · v1.0.2
   Addresses
   atlas_cards the-contract-keystone
2. [
   No Duck Left Behind
   ](https://agentic-atlas.dev/nodes/no-duck-left-behind)
3. [
   The Contract
   ](https://agentic-atlas.dev/nodes/contract-documentation)
4. [
   Foundations
   ](https://agentic-atlas.dev/nodes/foundations)
5. [
   Statelessness
   ](https://agentic-atlas.dev/nodes/statelessness)
6. [
   The Shared Shape
   ](https://agentic-atlas.dev/nodes/shared-shape)

The card, in place · its connections drawn edges from atlas_links the-contract-keystone

On this plate

[definition-the-analogy-declaration-versus-enforcement](https://agentic-atlas.dev#definition-the-analogy-declaration-versus-enforcement)[why-it-matters-why-verification-enables-the-rest](https://agentic-atlas.dev#why-it-matters-why-verification-enables-the-rest)[model-and-claims-one-move-three-names](https://agentic-atlas.dev#model-and-claims-one-move-three-names)[scope-and-boundaries-where-the-argument-stops](https://agentic-atlas.dev#scope-and-boundaries-where-the-argument-stops)[implications-the-consequence-map](https://agentic-atlas.dev#implications-the-consequence-map)[evidence-what-the-argument-rests-on](https://agentic-atlas.dev#evidence-what-the-argument-rests-on)[examples](https://agentic-atlas.dev#examples)[relationships](https://agentic-atlas.dev#relationships)[lineage](https://agentic-atlas.dev#lineage) [relationships](https://agentic-atlas.dev#relationships)

Every section is addressable on its own. Read only the ground you need.

## Definitionthe analogy: declaration versus enforcement

[](https://agentic-atlas.dev#definition-the-analogy-declaration-versus-enforcement)

definition-the-analogy-declaration-versus-enforcement.md

An agentic component is *like* a function in that it exposes an input/output interface. The analogy is genuinely useful: both let a caller reason about a component without reopening its implementation. The important difference is how much of the interface the surrounding system can declare and enforce.

- A **function declaration** can make mechanically expressible parts of the [contract](https://agentic-atlas.dev/glossary/contract) structural: parameter names and types, return types, and—in richer systems—selected invariants. A compiler or runtime may enforce those declared parts. Semantic intent still exceeds the declaration and needs tests, assertions, or review.
- An **LLM-facing** contract is often prose addressed to a *probabilistic reader*. It is **persuasion, not enforcement.** The model can read a beautifully documented contract and still hand back something off-spec — confidently, fluently, plausibly. The boundary is aspirational until something checks it.

> **A declaration makes the mechanically expressible contract visible; an enforcement mechanism makes selected clauses structural. An LLM-facing [seam](https://agentic-atlas.dev/glossary/seam) begins with more of its contract in prose, so verification moves as many clauses as possible from promise toward enforcement.**

## Why it matterswhy verification \*enables\* the rest

[](https://agentic-atlas.dev#why-it-matters-why-verification-enables-the-rest)

why-it-matters-why-verification-enables-the-rest.md

An acceptance criterion is what makes [re-dispatch](https://agentic-atlas.dev/glossary/re-dispatch) governable in the first place. You can only "throw it away and re-run" if you have something to check the return against. No legible expectation → you can't tell a bad result from a good one → you can't verify → you can't safely re-dispatch. The silent, instinctive version of this — verifying a sub-agent's output and re-running when it looks wrong — was *already depending on an implicit contract the whole time*. Naming the contract turns instinct into a tool you can hand someone.

## Model and claimsone move, three names

[](https://agentic-atlas.dev#model-and-claims-one-move-three-names)

model-and-claims-one-move-three-names.md

*Contract documentation*, *validated seam*, and *re-dispatch* are not three separate patterns. They are one move seen from three angles:

| Role | In a function | At an LLM-facing seam |
| --- | --- | --- |
| **Spec** | declaration / type signature | contract documentation |
| **Assertion** | compiler, runtime check, test, `assert` | deterministic or probabilistic validation at the return seam |
| **Recovery** | reject, throw, retry, compensate | reject, re-dispatch, adjust, fall back, or escalate |

- **Write the contract** to make intent legible (the spec).
- **Check the return against it** because the reader is probabilistic (the assertion).
- **Choose a recovery** after a failed check. For an effect-disciplined [dispatch](https://agentic-atlas.dev/glossary/dispatch), discarding can be cheaper than repairing. Re-dispatch is one tactical option, not the proof that the seam is safe.

You have reconstructed an assurance ladder around a reader that can ignore the declaration: prose → structured shape → deterministic clauses → probabilistic residue → human judgment. Only the mechanically enforced clauses become guarantees; the rest gain measured assurance.

### Why the check doesn't regress

The contract makes checking *possible*; a second premise makes it *affordable*: **verification asymmetry** (`../verification-asymmetry.md`). The verifier may be the same kind of probabilistic reader as the producer. The loop becomes useful only for clauses where checking a candidate against a documented spec is materially easier and measurably more reliable than producing it. One level is enough only when the checker terminates deterministically or its measured residual risk is acceptable. The two are sibling premises: the contract is the possibility condition of checking, the asymmetry its affordability condition.

### Why the discard is safe

Re-dispatch's economics assume throwing a run away costs nothing but the tokens. That is an engineering achievement, not a given: a dispatch that wrote files, called an API, or committed state before returning off-spec has already changed the world, and "discard" would silently mean "keep the mess." **Effect discipline** (`../effect-discipline/effect-discipline.md`) is the third premise: dispatches that may be discarded must be pure, idempotent, or isolated — and effects that escape those guarantees are either compensated at the seam they landed on, or gated *before* they happen rather than validated after. The contract makes checking possible, the asymmetry makes it affordable, effect discipline makes the recovery move legal.

## Scope and boundarieswhere the argument stops

[](https://agentic-atlas.dev#scope-and-boundaries-where-the-argument-stops)

scope-and-boundaries-where-the-argument-stops.md

The keystone is the argument, **not another pattern**: it owns how the three premises compose, not the premises themselves. The practice of writing a contract belongs to `../contract-documentation/contract-documentation.md`, which this node generalizes; the applied loop belongs to `../../verification/validated-seam-redispatch.md`; and each premise's own failure boundary belongs to that premise's node. Where the asymmetry fails — intent the clauses can't cover, verifiers that can't discriminate, absence-claims that invert the gap — assurance runs out with it; that boundary lives in the asymmetry node.

## Implicationsthe consequence map

[](https://agentic-atlas.dev#implications-the-consequence-map)

implications-the-consequence-map.md

Every other pattern leans on it. Deferral, externalization, heavy agents — they all create a **seam** between components. A seam becomes more trustworthy as its load-bearing expectations are made explicit and pushed toward checking at the rigor its consequence warrants. The contract isn't one foundational principle among many; it's the **substrate that makes the others safe to compose.**

## Evidencewhat the argument rests on

[](https://agentic-atlas.dev#evidence-what-the-argument-rests-on)

evidence-what-the-argument-rests-on.md

This is an argument assembled from three premises rather than a standalone empirical claim: each premise is grounded in its own node, and whatever revises one of them revises the composition here. What the keystone stands on directly is the instinct named above — practitioners already verify a sub-agent's output and re-run when it looks wrong, and that move already depends on an implicit contract. Each premise names the result that would revise it: a seam where the verify-and-re-run move is routinely safe with no legible expectation to check against would break the possibility condition; a seam where checking is no easier than producing breaks the affordability condition; a discarded run that already changed the world breaks the legality of the recovery. [No Duck Left Behind](https://agentic-atlas.dev/nodes/no-duck-left-behind) holds those three roles at one return seam: declared shape, deterministic assertion, bounded redispatch.

## Examples

[](https://agentic-atlas.dev#examples)

examples.md

- **[No Duck Left Behind](https://agentic-atlas.dev/nodes/no-duck-left-behind)** — a sorter omits one duck and duplicates another; a deterministic census rejects the manifest with a bounded error report; the fresh return passes.

## Relationships

[](https://agentic-atlas.dev#relationships)

relationships.md

- Generalizes `../contract-documentation/contract-documentation.md`.
- Applied, concrete form: `../../verification/validated-seam-redispatch.md`.
- Most directly load-bearing for `../../context-engineering/mechanisms/cost-relocation/subagent-offload/heavy-agent/heavy-agent.md` (the return contract) and `../../verification/fresh-context-trials.md` (the assertion).

## Lineage

[](https://agentic-atlas.dev#lineage)

lineage.md

Design by Contract (Meyer, *Object-Oriented Software Construction*; Eiffel): preconditions, postconditions, and invariants declared at an interface. The spec/assertion/recovery split is Meyer's obligation table with the enforcement removed — an agentic contract documents what a compiler used to check.

The relationships ledger

Evidence-bearing references

## Relationships

Every connection keeps the section where it was found. The map above orients; this ledger carries the evidence.

### Outbound references 2

1. in-slice · occurrence 1
   [No Duck Left Behind](https://agentic-atlas.dev/nodes/no-duck-left-behind)
   a deterministic duck census rejects one manifest and turns its errors into a bounded redispatch
   Evidence: [Evidence](https://agentic-atlas.dev/nodes/the-contract-keystone#evidence-what-the-argument-rests-on) · occurrence 1
2. in-slice · occurrence 1
   [No Duck Left Behind](https://agentic-atlas.dev/nodes/no-duck-left-behind)
   a deterministic duck census rejects one manifest and turns its errors into a bounded redispatch
   Evidence: [Examples](https://agentic-atlas.dev/nodes/the-contract-keystone#examples) · occurrence 1

### Inbound references 7

1. in-slice · occurrence 1
   [The Contract](https://agentic-atlas.dev/nodes/contract-documentation#model-and-claims)
   contract ↔ verification ↔ re-dispatch
   Evidence: [Model and claims](https://agentic-atlas.dev/nodes/contract-documentation#model-and-claims) · occurrence 1
2. in-slice · occurrence 1
   [The Contract](https://agentic-atlas.dev/nodes/contract-documentation#relationships)
   contract ↔ verification ↔ re-dispatch
   Evidence: [Relationships](https://agentic-atlas.dev/nodes/contract-documentation#relationships) · occurrence 1
3. in-slice · occurrence 10
   [Foundations](https://agentic-atlas.dev/nodes/foundations#model-and-claims)
   contract ↔ verification ↔ re-dispatch
   Evidence: [Model and claims](https://agentic-atlas.dev/nodes/foundations#model-and-claims) · occurrence 10
4. in-slice · occurrence 3
   [Foundations](https://agentic-atlas.dev/nodes/foundations#relationships)
   contract ↔ verification ↔ re-dispatch
   Evidence: [Relationships](https://agentic-atlas.dev/nodes/foundations#relationships) · occurrence 3
5. in-slice · occurrence 1
   [The Shared Shape](https://agentic-atlas.dev/nodes/shared-shape#verification)
   contract ↔ verification ↔ re-dispatch
   Evidence: [Verification](https://agentic-atlas.dev/nodes/shared-shape#verification) · occurrence 1
6. in-slice · occurrence 3
   [Statelessness](https://agentic-atlas.dev/nodes/statelessness#implications-the-consequence-map)
   contract ↔ verification ↔ re-dispatch
   Evidence: [Implications](https://agentic-atlas.dev/nodes/statelessness#implications-the-consequence-map) · occurrence 3
7. in-slice · occurrence 5
   [Statelessness](https://agentic-atlas.dev/nodes/statelessness#relationships)
   contract ↔ verification ↔ re-dispatch
   Evidence: [Relationships](https://agentic-atlas.dev/nodes/statelessness#relationships) · occurrence 5

[↑ back to the top](https://agentic-atlas.dev#content) [← the survey](https://agentic-atlas.dev/atlas)

Node the-contract-keystone · corpus 31de4cb · Catalog revision 35263c4c415da742953d0462804fb14424e2244dae4c63efd27e468988de70ab