Skip to content

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 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 — 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. 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.

Terms used across these pages are collected in the plain-English glossary.