What exactly do I get with a Build Specification?

You get three things: the Build Specification itself, as PDF, Word or Markdown; a one-page executive summary for the owner; and an AI build package that coding tools and development teams can read directly. All three are produced from the same stored version, so they say the same thing.

You can download any version, in any of these formats, at any time.

What's in the specification?

The document people read and approve has these parts:

• Build readiness: whether the spec is Build Ready, anything that was let stand and why, and a coverage statement saying what was and wasn't looked into.
• The problem and the goal: what's wrong today and what should be true once the software exists, with the approved scope.
• People: who uses it and what each role does.
• Requirements: each requirement as one testable statement with its own trace ID, marked as confirmed, assumed, open or decided.
• Disagreements and decisions: each conflict between experts, who decided it and why.
• Data and connected systems: the information the software keeps and the other systems it touches.
• Agent boundaries, when the application takes actions on its own: the limits on what it may do, and checks that try to get around them.
• Acceptance checks and tests: how anyone can confirm each requirement was built correctly.
• Ownership after handoff: who will run, support, secure and eventually retire the application.
• Traceability: where each item came from and what depends on it.
• Approval record: who signed off, and when.

Until a project is Build Ready, every version is labeled as a draft.

What's in the executive summary?

One page for the owner or sponsor: the problem and the goal, what's in and out of scope, how the value will be measured, and where readiness stands.

What's in the AI build package?

A zip file with:

• build-package.json: everything in structured form, with a trace ID on every piece: requirements, acceptance criteria, tests, data model, access rules, error handling, security, decisions, assumptions, a build sequence and a definition of done.
• build-package.schema.json: the published schema the file follows.
• BUILD_PACKAGE.md: the same content as one readable file.
• specification.md: the full specification, so the package stands on its own.
• tools/: optional instructions for AI coding assistants, including an AGENTS.md file, and an optional safety guard.

The package carries one standing instruction for the builder: when something is missing or unclear, ask instead of guessing.

Is anything else included?

A record of every answer and decision behind the specification, changes you approve for 90 days after handoff, and access for your builder's tools through the MCP server and API. To see a complete example, read the sample specification.