Specification-First Delivery

What is Specification-First Delivery?

Specification-First Delivery, or Spec-First Delivery, is a practical cross-functional engineering framework. It turns product intent, domain knowledge, constraints, and accountable judgment into a shared system that guides human and AI execution through acceptance, so organizations can deliver software they understand, trust, and are prepared to own.

Specification-First Delivery from different roles.

Specification-First Delivery brings each role’s knowledge and judgment into delivery while keeping decision authority and acceptance clear.

CTO / Engineering Manager

For CTOs and Engineering Managers, Specification-First Delivery is a delivery operating model that turns organizational knowledge, engineering constraints, decision authority, and professional judgment into a durable system for human and AI-assisted delivery. It makes delivery less dependent on individual memory, informal handoffs, or a particular team or tool, while preserving the authority and evidence needed to govern change.

AI has made an old delivery problem impossible to ignore

  1. AI capability is scaling faster than organizational capability.

    Access to capable models does not automatically create the ability to formulate work, expose assumptions, provide the right context, or evaluate results.

  2. Clear prompting does not replace problem formulation.

    A good prompt cannot create missing product intent, domain knowledge, constraints, decision authority, or acceptance criteria.

  3. AI exposes knowledge that traditional delivery kept implicit.

    Context previously recovered through meetings, experienced individuals, and informal handoffs must now be made durable and accessible.

  4. Professional judgment remains specialized.

    Faster implementation does not make product, architecture, security, reliability, or quality judgment interchangeable.

Make knowledge and judgment part of the delivery system

  • Make product intent, domain semantics, architecture, constraints, decisions, and operational knowledge durable and accessible. It gives every qualified delivery participant the relevant context to interpret a change, while keeping the knowledge that shaped it connected to the product’s current state.
  • Bring the relevant disciplines together to interpret a delivery need against applicable shared knowledge. Their accountable judgment makes the change’s scope, requirements, constraints, decisions, exceptions, and acceptance conditions explicit. Material questions are resolved by the role with authority before they become hidden implementation assumptions.
  • Humans and AI implement the agreed change within explicit scope, authority, context, and constraints. Engineers exercise technical judgment over implementation questions that established knowledge leaves open, and escalate material uncertainty to the accountable decision owner. Execution stays efficient while authority remains with the people who hold it.
  • Evaluate the integrated increment against the conditions that defined the work, using suitable tests, inspections, measurements, and reviews. Accountable owners decide whether the evidence and conformance review are sufficient to accept the resulting product state. Acceptance establishes a trusted increment the organization can explain and own.
  • Preserve accepted decisions, changed knowledge, implementation learning, code, and evidence as connected current-state knowledge. Future delivery can then begin from an accurate record of what changed, why it changed, and what evidence supports the accepted product state.

Trusted Increment

  1. Shared Knowledge

    Make product intent, domain semantics, architecture, constraints, decisions, and operational knowledge durable and accessible. It gives every qualified delivery participant the relevant context to interpret a change, while keeping the knowledge that shaped it connected to the product’s current state.

  2. Discuss & Specify

    Bring the relevant disciplines together to interpret a delivery need against applicable shared knowledge. Their accountable judgment makes the change’s scope, requirements, constraints, decisions, exceptions, and acceptance conditions explicit. Material questions are resolved by the role with authority before they become hidden implementation assumptions.

  3. Authorized Execution

    Humans and AI implement the agreed change within explicit scope, authority, context, and constraints. Engineers exercise technical judgment over implementation questions that established knowledge leaves open, and escalate material uncertainty to the accountable decision owner. Execution stays efficient while authority remains with the people who hold it.

  4. Verify & Accept

    Evaluate the integrated increment against the conditions that defined the work, using suitable tests, inspections, measurements, and reviews. Accountable owners decide whether the evidence and conformance review are sufficient to accept the resulting product state. Acceptance establishes a trusted increment the organization can explain and own.

  5. Retain Learning

    Preserve accepted decisions, changed knowledge, implementation learning, code, and evidence as connected current-state knowledge. Future delivery can then begin from an accurate record of what changed, why it changed, and what evidence supports the accepted product state.

From intent to trusted increment

Product, domain, architecture, engineering, quality, and accountable owners contribute where their judgment is needed throughout the same delivery path.

  1. Establish the context

    Product, domain, architecture, operational, and other relevant knowledge establishes what the change means and which constraints already apply.

  2. Define the change

    The relevant disciplines contribute requirements, decisions, constraints, exceptions, and acceptance conditions directly to the specification.

  3. Execute within authority

    Engineers and AI implement the change within the explicit scope and constraints. Engineers retain responsibility for technical judgment and implementation quality.

  4. Accept with evidence

    Accountable owners evaluate evidence against the requirements and acceptance conditions they contributed. Acceptance closes the increment and feeds durable learning back into the knowledge system.

A Spec-First Organization

A Spec-First Organization keeps the knowledge, decisions, roles, specifications, authority, evidence, and learning needed to continue responsible software delivery available across changes in people, teams, vendors, and tools.

  1. Direct contribution by Specification Architects

    Product, domain, architecture, engineering, security, reliability, and quality contributors are Specification Architects: they place their relevant judgment directly into the delivery system, where it can guide specifications, execution, and acceptance.

  2. Conversational context → Durable knowledge

    Important rationale, terminology, constraints, and decisions become accessible knowledge rather than remaining primarily in meetings, chats, or individual memory.

  3. AI autonomy → Bounded authority

    AI can execute substantial implementation work, but within explicit scope, constraints, decision authority, and acceptance conditions.

  4. Code completion → Trusted acceptance

    Producing code is not the end of delivery. An increment is accepted when appropriate evidence demonstrates that the intended requirements and constraints have been satisfied.

What Specification-First Delivery is: and what it is not

Specification-First Delivery is sociotechnical, specification-driven, cross-functional, and tool agnostic. It scales discussion, specification, review, and evidence in proportion to the work’s ambiguity, risk, dependencies, and consequences.

What Specification-First Delivery is

  • A sociotechnical delivery framework that brings technology, organizational knowledge, professional judgment, roles, authority, and human and AI collaboration into one operating model.
  • A tool-agnostic form of Specification-Driven Development that works with different coding agents, development environments, specification formats, repositories, and workflow tools.
  • A cross-functional delivery system in which business, domain, engineering, architecture, security, reliability, quality, and other relevant disciplines contribute directly to the knowledge and specifications that govern delivery.
  • A framework for governed human and AI execution that provides explicit context, constraints, authority, acceptance conditions, and retained knowledge around implementation.

What Specification-First Delivery is not

  • A replacement for Agile, Scrum, or other development methodologies, or for tools such as Spec Kit. Specification-First Delivery connects their workflows to shared knowledge, accountable judgment, and acceptance evidence.
  • A replacement for engineering, product, domain, security, or other professional judgment.
  • A requirement to document everything before implementation begins.
  • A return to waterfall delivery. Specifications evolve through discussion, implementation, evidence, and retained learning.
  • Dependent on autonomous AI. The same delivery model can govern human-only, AI-assisted, or highly agentic implementation.

Trusted delivery that survives changes in people, teams, and tools.

The organization retains the meaning, decisions, constraints, and evidence needed to continue responsible software delivery.