# 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. ### Business For business contributors, including Product Owners, Product Managers, Business Analysts, domain experts, and other accountable contributors, Specification-First Delivery is a way to contribute product intent, domain knowledge, business rules, exceptions, and acceptance judgment directly to software delivery. Their expertise becomes authoritative delivery knowledge that engineering and AI can work from, rather than context that must be repeatedly interpreted through handoffs. ### Engineers For engineers, Specification-First Delivery is an engineering system that provides the context, decisions, constraints, and acceptance conditions needed to implement a change with confidence. Engineers retain responsibility for technical judgment while spending less effort reconstructing missing product or organizational context, and AI can execute within explicitly defined authority. ## AI has made an old delivery problem impossible to ignore ### 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. ### Clear prompting does not replace problem formulation. A good prompt cannot create missing product intent, domain knowledge, constraints, decision authority, or acceptance criteria. ### 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. ### Professional judgment remains specialized. Faster implementation does not make product, architecture, security, reliability, or quality judgment interchangeable. ### Central proposition > The bottleneck moves from producing code to formulating, governing, and validating the work that code is meant to perform. ## Make knowledge and judgment part of the delivery system ### 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. - **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. - **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. - **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. - **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. - **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. A trusted increment brings the relevant disciplines into one delivery path, from the context that shapes the change through acceptance and retained learning. ### Establish the context Product, domain, architecture, operational, and other relevant knowledge establishes what the change means and which constraints already apply. ### Define the change The relevant disciplines contribute requirements, decisions, constraints, exceptions, and acceptance conditions directly to the specification. ### Execute within authority Engineers and AI implement the change within the explicit scope and constraints. Engineers retain responsibility for technical judgment and implementation quality. ### 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. ### Direct contribution by Specification Architects Product, domain, architecture, engineering, security, reliability, and quality contributors are [Specification Architects](https://specfirstdelivery.org/en-us/framework/specification-architect): they place their relevant judgment directly into the delivery system, where it can guide specifications, execution, and acceptance. ### Conversational context → Durable knowledge Important rationale, terminology, constraints, and decisions become accessible knowledge rather than remaining primarily in meetings, chats, or individual memory. ### AI autonomy → Bounded authority AI can execute substantial implementation work, but within explicit scope, constraints, decision authority, and acceptance conditions. ### 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.