Specification-First Delivery

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.

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.

1

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.

2

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.

3

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