Specification-First Delivery

Specification-First Delivery, or Spec-First Delivery, is a cross-functional engineering framework for turning organizational knowledge and professional judgment into specifications that can reliably guide software delivery.

The framework starts from a familiar problem. Important assumptions remained in meetings, architectural reasoning stayed with a few experienced engineers, exceptions were understood by a domain specialist, and acceptance expectations emerged only after implementation had begun. The software was delivered, but part of the knowledge required to understand and continue it never traveled with the delivery.

A field study of 17 large software projects identified thinly distributed application-domain knowledge, fluctuating or conflicting requirements, and communication bottlenecks as recurring problems in software design.¹ These are delivery-system problems: the knowledge required to make a correct decision may be distributed across people and may not travel with the work. Faster implementation makes the consequence more immediate because an incomplete interpretation can turn into code sooner.

Generative AI makes this weakness harder to ignore. It can implement an interpretation of a requirement very quickly, but it does not automatically know which interpretation the organization intended. When product intent, domain knowledge, architecture, security expectations, or operational constraints remain implicit, an AI system has the same fundamental problem as a new engineer joining the team: it must discover the missing context, ask for it, or infer an answer.

Specification-First Delivery is concerned with the organizational system around that problem. It asks how product, domain, architecture, engineering, quality, security, reliability, operations, and AI execution can contribute to one delivery process without expecting a single person or model to reconstruct everybody else's judgment.

Although Specification-First Delivery includes specification-driven development, it is better understood as a combination of established practices:

• Specification-Driven Development (SDD)

• Cross-functional product delivery governance

• Technical program or product management

• Architecture Decision Records (ADRs)

• Evidence-based acceptance

• Human-in-the-loop AI software engineering

It sits at the intersection of software engineering and organizational management.

The other Delivery Foundations papers develop the main parts of this model. The Shared Knowledge System defines the durable context that delivery draws on and updates. Requirements, Structured Discussion, and Increments explains how a delivery need is interpreted and shaped into a coherent change. Knowledge Convergence Across the Increment Lifecycle addresses the professional judgment and implementation learning produced while that change is delivered. Trusted Increments and Acceptance Evidence explains how conformance, evidence, and accountable acceptance establish the resulting product state.

Back to top

1. Existing Specification Practices and Their Limitations

Requirements engineering was already concerned with discovering stakeholder needs and expressing them in forms suitable for analysis, communication, and implementation long before generative AI.³ Business requirements, functional specifications, architecture documents, interface contracts, technical designs, test plans, runbooks, and acceptance criteria are all familiar parts of software engineering. Few established organizations genuinely operate by handing developers an entirely context-free idea and asking them to invent everything else.

Software design adds another continuity requirement. Teams learn, requirements evolve, and constraints become clearer while design is underway. Future participants still need a coherent record of the decisions that emerged so review, implementation, and maintenance can proceed from established reasoning.

The problem is that these practices have usually formed a loose collection rather than a coherent delivery system, and they make substantial assumptions about what people already know about the organization and the product. A requirement may begin with a Product Owner, be interpreted by a Business Analyst, refined by an architect, implemented by an engineer, and finally tested against another participant's understanding of what should have been built.

Zoom out

100%

Zoom inReset zoom and position

The formal artifacts tell only part of that story. Experienced teams compensate through conversation and memory. An engineer knows whom to ask about an unusual business rule. An architect remembers why an apparently simpler design was rejected. A long-serving team member recognizes that strange existing behavior is actually an important compatibility requirement.

These informal mechanisms are useful, but fragile. They depend on the right people remaining available and recognizing when accumulated context matters to the current change. The limitation is therefore not that software organizations have never used specifications. It is that the specifications and supporting records often remain disconnected and continue to depend on knowledge held informally by experienced participants.

AI makes this weakness more consequential because incomplete interpretation can become implementation much faster. The underlying delivery problem, however, existed before AI and remains an organizational problem rather than a tooling problem.

Back to top

2. Delivery Practice and Tooling

Much of the current discussion about AI-assisted software engineering begins at the implementation layer: coding agents, IDE integrations, planning modes, specification templates, repository instructions, context protocols, orchestration frameworks, and multi-agent workflows. These technologies matter, but they do not answer the more fundamental question of how an organization should work.

Practice must come before the tool.

An organization first needs to decide how product intent becomes an engineering commitment, where architectural authority sits, how security and reliability requirements enter delivery, which decisions may be delegated, and what evidence is required before a change is accepted. Only then does it make sense to decide how a particular tool should represent or consume those decisions.

Zoom out

100%

Zoom inReset zoom and position

Many teams start from the tooling instead. They begin with requests such as "I want to build an agent," then design workflows around the tool's operating assumptions. This implicitly allows the tool to define part of the organization's delivery model. When the tool changes, the practice changes with it, or the organization searches for another tool that can preserve a process it never defined independently.

Specification-First Delivery treats delivery practice as primary. Tooling implements that practice and should be treated as the last mile of solution delivery. This is particularly important because tooling is improving quickly. AI has made execution substantially cheaper, but it has not reduced the need for sound product, domain, architectural, security, or engineering judgment. If anything, rapid execution increases the cost of leaving those decisions ambiguous.

A specification may be stored in Markdown, a document platform, an issue-management system, or a structured specification service. An AI coding tool may access it through repository context, retrieval, APIs, generated prompts, or a future mechanism. None of those choices defines the framework. A mature organization should be able to change tools without rediscovering how it wants software decisions to be made. Organizations can adapt their platform integrations as their tooling evolves.

Faster execution increases the value of deciding what must be settled before execution and what can safely remain delegated. AI makes execution cheaper. It does not make judgment cheaper.

Back to top

3. Knowledge in Software Delivery

Software is usually described through code, systems, services, interfaces, data, and infrastructure. Yet every material software system also depends on knowledge that cannot be reconstructed reliably from source code alone.

A system carries product intent, domain concepts, business rules, architecture, security expectations, reliability requirements, data meaning, operational experience, interface obligations, rejected alternatives, and historical compromises. Some of that knowledge is visible in the implementation. Much of it is not.

Some delivery knowledge begins in individual experience and becomes reusable when the organization records it in durable, shared sources. AI changes what can happen once that knowledge is explicit and authoritative. Product intent, architectural rationale, constraints, or operating knowledge can be reused directly by engineers and AI instead of being repeatedly re-explained, rediscovered, or translated into ad hoc instructions. It can also constrain execution itself. The Shared Knowledge System develops this organizational knowledge model in detail.

Specification-First Delivery brings that organizational insight into engineering. Knowledge is the material from which a specification is formed. Discussion, analysis, and professional judgment turn that knowledge into decisions about what must be true, what may change, which constraints apply, who has authority, and how the result will be assessed.

Once reviewed, those specifications themselves become part of organizational knowledge. Implementation then produces another layer: code, accepted deviations, test evidence, operational observations, and lessons that should influence future work.

Zoom out

100%

Zoom inReset zoom and position

The circular relationship is central to Specification-First Delivery. Documentation is produced as part of the engineering work rather than treated as a separate activity before or after it. Knowledge shapes specification; specification guides implementation; implementation changes what the organization knows; and the resulting knowledge is documented as part of the same delivery process.

There is, however, a harder problem than preserving information: deciding which information is authoritative. A ticket may conflict with an architecture decision. Existing code may preserve obsolete behavior. A test may encode a historical assumption that the Product Owner now wants to change. A recent meeting may reach a decision that has not yet propagated to downstream specifications.

More context can simply provide more contradictory information. Giving an AI system access to all these sources does not resolve the conflict. Specification-First Delivery therefore treats ownership and authority as part of specification. Material decisions need an identifiable owner, an authoritative source, an understood scope of applicability, and a governed path for change. Conflicts can therefore be resolved in one of two ways:

• An AI coding agent follows the established authoritative path when the applicable source and precedence are clear; or

• The issue is raised with the appropriate human decision owner, and the confirmed resolution becomes part of the knowledge available to future work.

The objective is to turn the knowledge relevant to delivery into something that humans and AI can act on without repeatedly reconstructing the organization's intent.

Back to top

4. Specification Scope and Uncertainty Reduction

Every useful specification should remove a material guess by resolving uncertainty that should not be delegated to the next participant in the delivery chain. A specification that removes no material uncertainty should not exist; this is addressed later through the proportionality principle.

Consider a request to introduce a new piece of product behavior. Before that request reaches implementation, several fundamentally different questions may need answers:

They require different forms of knowledge, experience, and organizational authority.

When an implementable technical specification reaches the engineer or coding agent, these material issues should have been clarified. The executor should understand what the change is intended to achieve, which constraints apply, what must not change, what the acceptance criteria are, and which decisions remain within delegated implementation authority.

Specification-First Delivery emphasizes domain-specific and engineering judgment in implementation.

An engineer still chooses algorithms, abstractions, local structures, naming, implementation techniques, and other details where those choices fall within delegated authority. An AI coding agent can be given similar implementation freedom. Together, the relevant specifications form a Specification Set.

A Specification Set is better understood as a dependency graph because different specifications depend on different inputs. One specification can become an input to another until the relevant decisions converge in implementable technical specifications. Functional, architecture, security, reliability, data, and integration specifications may develop concurrently when their dependencies allow it. Each removes a different class of uncertainty while also constraining or exposing questions in the others.

For instance, a functional specification could describe how the system is supposed to behave even though the architecture and security specifications were still under refinement. A security constraint could render part of the planned functional behavior invalid. An architecture choice could introduce a reliability requirement. Testing could reveal exception behavior that had never been specified.

Zoom out

100%

Zoom inReset zoom and position

Note that a delivery process does not require every element in every change. Small changes can go straight from discussion to technical specifications; major changes may require several specialist specifications. The important point is to remove the material guesses that should not be delegated downstream.

When delivery exposes an issue that was not previously clear, the authority to resolve it depends on the nature of the decision, not on where the issue was discovered. If the resolution falls within the executor's delegated implementation authority, engineering can resolve it. If it affects authoritative product behavior, architecture, security, reliability, data meaning, or acceptance criteria, the relevant specification should be reopened and the decision referred to the accountable role.

This becomes especially important when AI participates in delivery. AI is strong at producing plausible responses to incomplete questions. That is useful when the missing element is a delegated implementation choice and dangerous when the model is silently making a decision for which it has neither organizational authority nor sufficient context.

A guess removed upstream does not need to be rediscovered by every engineer, supplier, future maintainer, or AI session that encounters the same system. A reviewed specification lets the organization make a material judgment once and reuse it throughout delivery. Later participants can spend their effort on new decisions instead of reconstructing old ones.

Back to top

5. Cross-Functional Responsibility and Professional Judgment

Software engineers are increasingly expected to broaden their knowledge, skills, and competencies. An engineer may be expected to think about product context, understand the domain, architect systems, consider security, write and test code, operate production systems, talk to users, and now coordinate AI agents. Roles such as the Forward Deployed Engineer reflect part of this trend.

This breadth is valuable. Engineers need to understand the context in which software is developed. Specialization without awareness of broader consequences is detrimental. The problem begins when a broad perspective becomes a replacement for specialist expertise and authority:

• A developer who understands product thinking does not automatically possess the domain knowledge, customer context, decision authority, or experience of the Product Owner.

• Familiarity with common security principles does not make every engineer a security specialist.

• An architect should understand reliability and quality, but that does not make the architect the accountable owner of every operational or testing decision.

The universal-developer model, expecting a hero engineer, appears to simplify the organization by putting more capability in one role. In practice, it often moves unresolved organizational complexity to the engineer. The engineer becomes the place where incomplete requirements, undocumented decisions, specialist concerns, and conflicting assumptions are reconciled. If the organization has not decided something explicitly, the engineer is expected to work it out.

AI makes this model tempting. A capable engineer can now use AI to research an unfamiliar domain, draft security considerations, generate tests, compare architecture options, and explore product questions. The apparent range of one individual expands considerably. What does not expand automatically, however, is authority or professional competence.

An engineer can use AI to understand a security issue more quickly, but that does not necessarily make the engineer the proper owner of a material security decision. AI can help a Product Manager explore architecture options, but architectural responsibility does not shift to product management.

Specification-First Delivery connects professional depth across roles. Software-team research provides a direct basis for the coordination part of this model. Faraj and Sproull define expertise coordination as knowing where expertise is located, knowing where it is needed, and bringing the needed expertise to bear; in their study, stronger expertise coordination was associated with better team performance.² The framework adds an explicit delivery responsibility: experience, knowledge, and competence must be connected to the decisions they inform, with clear ownership of each material decision.

AI coding tools can help each function contribute its professional judgment directly to delivery. Product decisions define specifications that shape product behavior. Architectural judgment becomes explicit system responsibilities and constraints. Security and reliability considerations shape technical specifications from the outset. Quality considerations become part of acceptance criteria before work is considered complete.

Engineers remain critical; they challenge specifications, understand technical implications, implement decisions, and build technically sound deliverables from reviewed requirements. What should be avoided is requiring engineers to silently recreate professional judgment that belongs to other accountable roles.

Not every specialist needs to participate in every change. A low-risk local change does not require a meeting with every function in the organization. The principle is narrower:

When material professional judgment is required, it should come from the appropriate accountable role before the executor is forced to infer it.

Back to top

6. Human and AI Roles, Authority, and Delegation

AI changes the composition of the delivery organization because an AI coding agent is no longer only a code-completion tool. An agent can receive context, interpret requirements, suggest solutions, implement changes, write tests, update documentation, and participate in review workflows. It is therefore useful to treat AI as an active participant in delivery while clearly distinguishing it from the humans who remain accountable for material decisions and outcomes.

One important difference is continuity. A new AI session can resemble a newly arrived, highly capable colleague with little organizational memory. It may analyze the repository quickly, but it does not automatically understand why the organization made earlier choices.

AI is your new colleague every day.

The model may not know that a seemingly awkward implementation exists because a simpler architecture failed in production. It may not know that a stakeholder explicitly rejected an alternative six months earlier, that an unusual business rule applies only to one customer segment, or that an existing test preserves behavior the organization now considers obsolete.

A large context window improves access to information. It does not create authority, resolve contradictions, or distinguish deliberate design from accidental history. Those are delivery-system concerns rather than model-capability concerns. More importantly, attention is a scarce resource for both large language models and humans.

Specification-First Delivery addresses this by providing humans and AI with a common delivery system in which material decisions are specified and preserved before execution.

The Specification System provides a durable record of discussions and decisions that new colleagues, including AI coding agents, can reference. Product discovery, design discussion, architecture debate, implementation feedback, and review remain necessary. The important change is that decisions with lasting delivery consequences should not disappear when the conversation ends.

The same holds true for professional judgment. Specification does not automate every decision. It records what decisions have been made, what remains open, and where the next participant is expected to exercise judgment.

This produces a more practical concept of AI autonomy. Rather than debating whether an agent is autonomous in general, the organization defines the scope and authority within which that autonomy applies.

An executor may have considerable freedom in how work is implemented while lacking authority to change product behavior. It may refactor components while lacking authority to add a dependency between systems, or generate tests while lacking authority to redefine acceptance criteria set by accountable roles. This is delegated autonomy: authority to act within an explicit scope while escalating material decisions outside it.

Back to top

7. Specification-First Delivery Operating Model

For an individual change, Specification-First Delivery resembles a familiar engineering process: define the requirement, prepare the necessary specifications, execute the work, and verify the result. At organizational scale, however, the implications go further. Specification-First Delivery describes how authority, information, professional expertise, delegation, and accountability flow through an organization that delivers software.

Three aspects are especially important: authority, delegation, and continuity.

The first is authority. Software delivery constantly involves decisions that belong to different roles. Product behavior, architecture, security controls, operational risk, and implementation details should not acquire authority merely because one participant happened to express an opinion first. A functioning delivery system needs to make clear who can decide what and how those decisions become authoritative.

The second is delegation. Traditional management can fall into two extremes. One is detailed control of implementation, where senior engineers or managers become bottlenecks because they need to inspect or approve every decision. The other is vague delegation, where a team or AI agent is given an outcome but must discover the important constraints while executing it.

Specification-First Delivery aims for a more deliberate middle ground. The organization invests judgment in defining the work, its constraints, decision ownership, and acceptance conditions, then allows implementation to proceed with meaningful autonomy inside that scope.

With AI coding agents performing more implementation work, the delivery team can micromanage specifications, not code. Detailed review is most valuable when it examines the decisions that shape implementation, after the specifications have removed material guesses and defined the agent's execution authority. Skilled AI coding agents can then carry out implementation within that delegated scope.

The third concern is continuity. If organizational intent and technical rationale remain primarily in individual memory, every change in staffing becomes a partial reset. The new participant must rediscover not only the code but also the reasoning around it. A shared Specification System reduces that dependence.

Zoom out

100%

Zoom inReset zoom and position

The Specification System is an important component within the Shared Knowledge System through which authoritative intent, constraints, decisions, and acceptance expectations remain connected to execution. This makes accountability compatible with increasing automation. AI may perform more implementation work without acquiring authority over decisions the organization never intended to delegate.

Back to top

8. Framework Application and Proportionality

A framework needs to help practitioners decide what to do when real work arrives. Specification-First Delivery covers the practices that connect an initial request to an accepted software change: how requirements are explored, which specifications are appropriate, how different professional functions contribute, how authority is recorded, how implementation work is scoped, how deviations are handled, and what evidence is required for acceptance.

These practices are deliberately tool-agnostic. A Shared Knowledge System may use a document repository, a knowledge graph, or another suitable technology. It is adequate when human participants and AI coding agents can consistently locate and interpret the applicable knowledge and code. A repository's docs/ directory can be one suitable implementation when it meets that need.

These practices are also proportionate. Specification depth should reflect the material ambiguity, novelty, dependencies, risk, and consequence of the work. Specification-First Delivery does not turn a two-line change into a twenty-page process; doing so is over-specification. The following scenarios can all be consistent with Specification-First Delivery:

• A minor wording correction may need little more than a clear instruction, a small implementation change, and confirmation that related documentation remains coherent. It may not need to contribute anything new to the Knowledge System.

• A normal feature may justify a functional specification followed by one or more technical specifications.

• A change involving sensitive information, complex integration, material security exposure, significant availability requirements, or an irreversible migration may require architecture, security, reliability, data, and integration specifications as well.

Under-specification pushes unresolved decisions downstream without saying so. Over-specification spends time resolving details that could safely have remained within the executor's professional discretion and can contribute to context bloat, where humans or AI receive more information than is useful for the task. Both reduce delivery efficiency. The aim is to specify enough to remove the material guesses before execution, while leaving legitimate implementation judgment where it belongs.

A mature Specification-First Organization should therefore be measured by whether its specifications make delivery more reliable, accountable, understandable, and repeatable. The number of specifications produced is not a meaningful Key Performance Indicator (KPI).

Back to top

9. The Specification Architect

If Specification-First Delivery changes how professional judgment enters the delivery process, it also changes what practitioners need to be good at. The framework uses the term Specification Architect for a professional who can make the judgment of their discipline usable within a Specification-First Delivery value chain. The title is function-agnostic and does not imply a software engineering background.

A Product Owner can operate as a Specification Architect by making product intent, trade-offs, scope, and decision ownership explicit enough to guide downstream work. A Business Analyst can do so by turning domain knowledge and business behavior into precise functional specifications. An architect does it by making structural decisions, interfaces, dependencies, and constraints usable by implementation teams.

Engineers practice the same discipline when they challenge ambiguity, identify missing upstream decisions, transform reviewed requirements into implementable technical specifications, and decide which technical choices should remain delegated to implementation. Similarly, security, reliability, quality, operations, and other specialists apply the discipline within their own areas of professional accountability. What these practitioners share is a disciplined way of making professional judgment usable by others. They are therefore collectively described as Specification Architects.

A Specification Architect needs to recognize when an apparent implementation question is actually an unresolved product or architecture decision. They need to distinguish authoritative requirements from useful background information, identify assumptions that could become chained guesses downstream, and express constraints without unnecessarily dictating implementation.

They also need to work effectively with AI. That includes using AI to explore alternatives, test the completeness of a specification, identify ambiguity, and accelerate execution without treating the model's confidence as organizational authority.

A Specification Architect should be able to connect decisions across the delivery chain. Product intent should remain recognizable in functional behavior; architecture should shape technical work; security and reliability requirements should reach implementation and testing; acceptance evidence should trace back to the expectations that justified the work.

When implementation reveals that a specification was incomplete or wrong, the response should not be to preserve the fiction that specifications are always correct. The specification must be challenged and changed through an appropriate decision path. Specification Architecture is therefore a distributed professional capability.

A Specification-First Organization distributes Specification Architects across specialist areas. They contribute directly to the delivery value chain and express their knowledge clearly enough for others, including AI, to act on it. Assigning one individual to write or own every specification would recreate the concentration of interpretation that the framework is designed to avoid.

Back to top

10. Organizational Delivery Continuity

The objective of Specification-First Delivery is therefore to achieve capability continuity: the organization should retain enough knowledge, authority, and decision history to continue delivering and evolving software even as people, teams, vendors, models, and tools change.

Software systems often outlive the teams that designed them. Product Owners, architects, engineers, and domain specialists move to other projects or leave the organization. Vendors change, AI models and development tools can be replaced, and organizational structures can change as well. Over time, a service may be maintained by people who have never spoken to anyone involved in its original design.

Without a durable delivery knowledge system, these transitions create two different losses. The organization loses the departing professional's future contribution, but it may also lose knowledge that should already have become part of the organization's capability. The first loss is unavoidable. The second should not be.

New participants inevitably need to investigate an unfamiliar system. The problem arises when that investigation becomes organizational archaeology: searching through old tickets, chat histories, source code, and undocumented behavior because nobody can explain which decisions were intentional or which sources remain authoritative. AI makes this problem more frequent because every new agent session can effectively behave like another newly onboarded participant.

A qualified new participant should be able to determine which behavior is intentional, which constraints still apply, who owns unresolved decisions, why material choices were made, what evidence supported acceptance, and where new professional judgment is now required. They should not need to reconstruct the organization's entire decision history simply to understand what the system is supposed to do.

This does not make professionals replaceable. Losing an experienced engineer, architect, Product Owner, or domain specialist still means losing expertise, relationships, intuition, and future judgment that no specification system can fully preserve. Specification-First Delivery is designed to prevent that departure from also erasing knowledge that should already belong to the organization.

This is what Specification-First Delivery means by capability continuity. The knowledge system must ship together with the software. Before AI, the practical standard may have been whether the necessary documentation existed. With AI coding agents, a more demanding test becomes possible:

Can an AI coding agent start working on a new increment without making any significant guesses?

If every new coding-agent session requires a senior engineer to restate the same architecture history, reconstruct the same constraints, and explain the same exceptions, then the knowledge system has not yet become part of delivery. The organization is still depending on individual memory as its integration layer.

Capability continuity therefore provides a practical test of the framework itself. A specification system may produce large volumes of documentation and still fail if a qualified participant cannot determine what is authoritative, why the system behaves as it does, or what they are permitted to change.

A functioning Specification-First system should allow work to continue with proportionate rediscovery: enough investigation to understand the current problem and exercise fresh professional judgment, but not a complete archaeological reconstruction of previous decisions.

Back to top

11. Conclusion

Specification-First Delivery treats software delivery as a process for converting distributed organizational knowledge and professional judgment into trusted software.

Specifications have always been part of that process, but they have often existed as disconnected artifacts around a delivery model that continued to rely heavily on informal communication and individual memory. AI has made the limitations of that arrangement more visible because implementation can now move faster than the organization's ability to notice that an assumption was never properly resolved.

The Specification-First Delivery framework gives each accountable function a direct way to contribute the judgment it owns. Specifications carry that judgment into execution at a level proportionate to the work. Engineers and AI retain meaningful implementation freedom inside explicit authority. Evidence connects the delivered result back to what the organization intended. The decisions and learning produced by delivery then return to the organization's knowledge system.

This is unlikely to change even if substantially more capable AI models are released. AI does not automatically inherit organizational dynamics, contractual obligations, or the history of a development project.

This creates a different relationship between knowledge, specification, and code. Knowledge is not merely background material for software development, and specification is not documentation written around the code. Knowledge provides the basis for specification; specification makes relevant knowledge actionable; implementation produces software and evidence; and the resulting decisions become part of the knowledge available to the next delivery.

The same model explains why Specification-First Delivery is both an engineering framework and, at organizational scale, an operating model for software delivery. It addresses not only how work is described, but how authority is exercised, professional depth is connected, execution is delegated, outcomes are accepted, and delivery capability survives changes in people and tools.

AI increases the urgency of these questions, but the underlying challenge predates it. Organizations are now encountering the accumulated technical debt created when decisions and history remain undocumented. An organization that builds software needs a reliable way to carry what it knows, what it has decided, and what its professionals judge to be important into the software it ultimately owns.