---
description: >-
  The Spec Manifest: the unit of production for agentic delivery — a versionable, authorizable, compilable, executable, auditable intent contract.
---

# The Spec Manifest

Before a commercial building goes up, one document set governs
everything: the permit drawings. The owner signs them. The inspector
checks the built work against them. Every trade — electrician, plumber,
framer — works from the same sheets, and when a question comes up on
site, the drawings answer it. Change the design and someone issues a
stamped revision that gets re-approved. What no construction project
runs on is seventeen private interpretations of a conversation with the
architect.

Enterprise AI projects, today, run on exactly that. As
[the delivery gap](../why/delivery-gap.md) documents, agentic projects
die because no artifact carries the business intent of the project from
conception through production — intent gets rebuilt by hand at every
boundary, and every rebuild loses something.

The **Spec Manifest** is that missing artifact: the unit of production
for agentic delivery. It is a declarative, intent-bearing,
provenance-carrying, machine-actionable document, compiled from the
engagement's [digital twin](digital-twin.md) — the living model of what
the customer wants, what exists, and what has been decided. Where the
twin holds everything the engagement knows, the Spec Manifest states,
in one governed document, what is to be built and on whose authority.

## An intent contract

The most useful way to read the Spec Manifest is as a contract that
binds business intent to action, with five properties:

- **Versionable.** It has revisions, like code. Intent changes; the
  document changes with it, and the history of what changed survives.
- **Authorizable.** Someone accountable signs what it may do. The
  authorization is written into the artifact, not implied by a meeting.
- **Compilable.** Plans and work packages derive from it mechanically —
  not reconstructed from memory by whoever picks up the project next.
- **Executable.** Implementers, human or AI, act on it directly. It is
  the working document, not the documentation of one.
- **Auditable.** Every clause traces to the evidence and decisions
  behind it. When a trust review asks who authorized this action, over
  which data, the document answers.

One borrowed phrase captures the register: *RFC 2119 for probabilistic
implementers*. RFC 2119 is the internet-engineering convention that
gave "MUST" and "SHOULD" their precise meanings — internet protocols
read like treaties
because independent implementers have to interoperate without ever
meeting. The Spec Manifest brings that treaty language to a new kind of
implementer, one that interprets instead of merely executing. It tells
the implementer — a person or an agent — what MUST hold, what SHOULD
hold, and what is deliberately left open, so that judgment operates
inside stated boundaries rather than guessed ones.

## What it is not

It is not a requirements document: a PRD describes intent for humans to
interpret, while the Spec Manifest is machine-actionable. It is not a
workflow diagram: workflows assume every step behaves deterministically,
and agents do not — the Spec Manifest survives non-determinism by
stating what must be true rather than scripting every step. And it is
not a prompt: prompts are volatile, private, and tied to a model
version, while the Spec Manifest is durable, owned, and governed.

A contract is only as good as the trust behind it. How provenance,
decision traces, and a maturity ladder earn that trust — without
pretending agents are deterministic — is the subject of
[Governance as trust](governance.md). And the Spec Manifest's
engineering ancestry — spec-driven development, GitHub's Spec Kit,
and what had to change for SaaS — is traced in
[Borrowed from software engineering](engineering-lineage.md).

---

*Terms used across these pages are collected in the
[plain-English glossary](glossary.md).*