The Workflow # A delivery system that retains specialist judgment. Specification-First Delivery does not ask one engineer, or one AI system, to replace the knowledge held across product, domain, architecture, quality, security, and operations. It makes that judgment available, reviewable, and usable throughout delivery. ## AI changes the work, not who is accountable. ### AI contributes It retrieves context, identifies questions, structures drafts, and executes approved technical work. ### Specialists decide Qualified people remain accountable for the judgment within their professional responsibility. ### The organization retains Reviewed knowledge, decisions, specifications, and evidence remain available when people, teams, or tools change. The working agreement ## Respect professional judgment. Retain it. The workflow gives each contributor a clear role in producing an organizational result. It does not collapse product, engineering, domain, quality, security, and operational accountability into one generalized role. ### Respect each specialty No one contributor is expected to replace every specialist. The people responsible for product, domain, security, reliability, architecture, quality, or delivery judgment contribute it where the change needs it. ### Keep named ownership Every material document has an accountable owner. AI can draft and challenge it, but it does not own the document or substitute for its review. ### Treat answers as organizational assets A confirmed answer improves the Knowledge System rather than remaining in a private conversation or in one person’s memory. The question and review cycle ## Every material question has a route to an accountable answer. This cycle recurs while discussions, specifications, architecture, technical work, and test specifications are developed. When AI has no further material questions, that is a review signal, not a transfer of human responsibility. ### 1. Ask against available knowledge Use AI to inspect the request, existing code, documented decisions, and relevant constraints for missing information, conflicts, exceptions, and dependencies. ### 2. Consult the accountable role When a question falls within another specialty, ask that colleague to decide, clarify, or review it rather than inferring an answer. ### 3. Update the document and Knowledge System Record the decision in the appropriate discussion, specification, glossary, methodology, constraint, or decision-history source. ### 4. Review line by line The named owner examines the resulting document for accuracy, clarity, scope, constraints, protected behavior, and acceptance conditions. The delivery flow ## One visible flow, with accountable work at every stage. The stages below show how a request moves from a considered discussion into clearly scoped implementation. The question and review cycle may return the work to an earlier stage whenever the evidence requires it. ### 1. Frame the change from available knowledge and code Discuss the new feature, application, or requirement before deciding how to implement it. Make the current product intent, decision history, code, constraints, interfaces, and operating context available to the people and AI systems examining the change. - **Accountable roles:** For a significant feature, the product owner leads. For a smaller feature, a product or program manager may lead. Business analysts define business requirements. Security and reliability specialists contribute where the change affects their responsibilities. - **Primary artifact:** A discussion document and recorded due diligence against the relevant knowledge and codebase. - **Knowledge System:** The request may reveal missing glossary entries, product intent, calculation methodology, use cases, current technical context, or external connectivity information. - **Ready when:** The team can explain the requested outcome, the context inspected, the people who must decide, and the material questions that remain. ### 2. Review and develop the discussion document Ask AI to identify open questions, answer them with the responsible colleagues, then revise the document. Repeat until AI identifies no further material questions from the available context, and the owner judges the discussion ready to specify. - **Accountable roles:** The named owner of the discussion document leads the review, with input from the specialists responsible for the questions it raises. - **Primary artifact:** A line-by-line reviewed discussion document with answers, assumptions, unresolved decisions, and links to supporting knowledge. - **Knowledge System:** Confirmed answers update the sources that future work will need, including terminology, business rules, product intent, constraints, and decision history. - **Ready when:** The accountable owner has reviewed every statement and has either resolved material questions or identified the role and process that will resolve them. ### 3. Write functional and non-functional specifications Describe the behavior people must be able to observe, including normal paths, exceptions, errors, dialogs, business rules, and acceptance conditions. Non-functional specifications state reliability, observability, alerting, security, performance, or technical requirements when those are necessary. - **Accountable roles:** The person accountable for the requirement writes or owns the specification, drawing on product, business analysis, security, reliability, quality, and operational expertise as needed. - **Primary artifact:** Functional specifications and, where needed, non-functional specifications. - **Knowledge System:** The specifications make agreed behavior, operational expectations, and acceptance evidence reusable for engineering, QA, and future change. - **Ready when:** The expected behavior and operating expectations are sufficiently explicit for technical design, technical specification, and test design to begin without guesswork. ### 4. Design the solution when an architectural decision is needed (Optional) Where a change introduces or changes system responsibilities, interfaces, dependencies, technology choices, or significant constraints, translate the relevant specifications into an architectural design. Patches and low-risk changes may not require this stage. - **Accountable roles:** An architect owns architectural decisions, working with the development lead and affected specialists. - **Primary artifact:** A reviewed design document, when the change requires one. - **Knowledge System:** The design records the decisions, alternatives, rationale, consequences, and constraints that engineering needs to preserve. - **Ready when:** The architectural decisions needed for implementation are explicit, reviewed line by line, and have no remaining material questions within their scope. ### 5. Create technical specifications for execution Translate the agreed requirements and any architectural design into technical work that engineers or AI coding agents can execute. A larger requirement may legitimately split into three, twenty, or another appropriate number of technical specifications. - **Accountable roles:** Engineers write the technical specifications, with the development lead and other specialists reviewing questions that affect their responsibilities. - **Primary artifact:** A set of technical specifications. One functional or non-functional specification may produce several technical specifications. - **Knowledge System:** New implementation constraints, codebase findings, interfaces, and decisions return to the discussion, requirements, design, or knowledge sources when they change the agreed understanding. - **Ready when:** Engineers judge that each technical specification has no remaining material questions for its execution scope and authority. ### 6. Implement the agreed technical specification Once engineers judge a technical specification ready, the execution instruction can be as direct as “Implement the specification.” New information does not get silently absorbed into code. It returns to the accountable owner and the appropriate earlier artifact. - **Accountable roles:** Engineers remain accountable for executing the technical specification and escalating any newly discovered question that exceeds their authority. - **Primary artifact:** An implementation, verification results, and evidence that the agreed specifications have been met. - **Knowledge System:** The resulting code, deviations, verification evidence, and operational learning become part of the knowledge available for the next change. - **Ready when:** The implementation has been verified against the technical, functional, non-functional, and test specifications, then presented to the appropriate role for acceptance and release decisions. A parallel quality path ## Test specifications begin from the requirements, not from the implementation. QA and test engineers develop test specifications from the functional and non-functional specifications. This keeps acceptance evidence connected to the outcome and operating expectations that were agreed before code was written. ### 1. Derive test specifications Translate the specified behavior, exceptions, reliability expectations, observability requirements, and alerting conditions into testable scenarios and evidence. ### 2. Use the same question cycle QA engineers ask AI to surface unanswered test questions, update the Knowledge System, and review the test specification line by line. Questions that belong to another specialty return to that accountable colleague. ### 3. Make acceptance evidence visible Tests and operational evidence show whether the agreed conditions were met. They support acceptance decisions without redefining the requirement after implementation. Capability Continuity ## Every delivery increment leaves the organization better prepared for the next change. The workflow continuously improves the shared system of knowledge and evidence. It reduces reliance on one person’s memory without reducing the value of professional judgment. - Glossary, product intent, business rules, and calculation methodologies - Use cases, exceptions, constraints, and protected behavior - Architecture decisions, current technical context, and external connectivity - Reliability objectives, observability, alerts, test specifications, and acceptance evidence - Discussion history, decisions, implementation learning, and reviewed deviations ## Teamwork makes specialist judgment durable. Everyone brings a different skill set. Specification-First Delivery helps those people turn their judgment into a shared delivery capability, so AI strengthens organizational results instead of making people fear replacement. [Begin with one delivery stream](https://specfirstdelivery.org/en-us/framework/adoption)