Why AI-Native Development Needs an Executable Artifact Chain, Not More Specs

Many Documents Do Not Equal a Development Baseline

The previous article discussed how AI coding acceleration shifts bottlenecks to requirements, design, verification, release, and operations. Connecting these stages requires stable artifacts. Here Spec means an explicit expression of goals, boundaries, design constraints, and acceptance criteria; SDD is Spec-Driven Development.

However, using different SDD tools reveals a problem: documents proliferate, yet developers don't know which one to trust. A batch-import case illustrates this. Business initially asked only for "Excel bulk import of customer data." Through discussions, chat logs accumulated requirements on file size, field validation, duplicate submission, partial success, permissions, and task recovery. An agent organized these into requirements specs, design proposals, task plans, and test suggestions.

Despite abundant material, four problems emerge at development time:

The same rule is expressed differently across several documents.

Newly generated plans still reference outdated designs.

Development threads see only partial summaries, missing critical exception boundaries.

When design changes, test and acceptance criteria are not updated synchronously.

Version control shows files changed but cannot automatically indicate which content is the current authoritative baseline or prove consistency across artifacts.

What Each Link in the Artifact Chain Answers

AI-native R&D does not mandate fixed filenames, but each artifact type must have a clear responsibility. The following seven artifacts form a continuous reference chain: plans reference design versions, code changes link to tasks and acceptance criteria, test evidence ties to code versions and environments, and incident improvements feed back into new business intent or design changes. If any link loses its reference, downstream roles may continue working on obsolete facts.

Business Intent — Why are we doing this, what business outcome is expected? Cannot replace detailed requirements and technical design.

Requirements & Boundaries — What to do, what not to do, rules and acceptance criteria? Cannot replace architectural trade-offs and implementation plans.

Design Baseline — How are objects, states, interfaces, permissions, exceptions, and runtime constraints organized? Cannot replace code and real runtime evidence.

Implementation Plan — Which tasks execute in what dependencies and order? Cannot replace requirements decisions and acceptance authority.

Code & Configuration — What does the system actually implement now? Cannot replace validation of whether business intent is correct.

Verification Evidence — Which version passed which checks in what environment? Cannot replace uncovered risks and production authorization.

Reviews & Incident Records — Who made what judgment based on what facts? Cannot replace the assumption that current conclusions remain permanently valid.

Authoritative Sources, Working Copies, and References Must Not Be Mixed

The most common issue in AI collaboration is every thread maintaining its own "latest requirements" understanding. A safer approach distinguishes three information types:

Authoritative Source — Confirmed by the responsible person, drives subsequent work as the current baseline.

Working Copy — Drafts prepared by roles for analysis and modification, not yet formally effective.

References & Summaries — Extracted snippets to reduce context cost, must be traceable to the authoritative source.

Authoritative sources need not be Markdown or live in Git; existing requirement systems, architecture repositories, API management platforms, test platforms, and change systems can serve as formal records. The key is not tool unification but that every decision can answer: who maintains it, what is the current version, when does it take effect, and which downstream artifacts reference it.

Artifacts also need explicit states: drafts are for discussion only; after responsible-person confirmation they become the current baseline. When an upstream baseline changes, affected plans, code, and tests must shift to "pending review" rather than retaining "completed" status.

Summaries help agents reduce context, but must not silently replace the original baseline. On conflict, return to the authoritative source instead of letting the model vote among summaries.

Artifact Handoff Requires Explicit Entry Criteria

Submitting a document from the previous phase does not mean the next phase can start. Before bulk-import development begins, at minimum confirm:

Business scope, non-goals, and user permissions are clear.

File scale, processing latency, duplicate submission, failure and recovery rules have conclusions.

Interfaces, task states, data structures, and error semantics can support implementation.

Acceptance criteria can be translated into tests or manual checks; remaining issues won't block current tasks.

These criteria are not about document perfection but judging whether uncertainty is low enough to safely enter implementation. Similarly, development completion needs exit criteria: code linked to current design version, agreed checks actually executed, known deviations explicitly resolved — not just uploading a "development complete" note.

When Development Finds Design Gaps, Don't Invent Rules in Code

Suppose a developer implementing the import task discovers the document doesn't specify whether the first 4,999 rows are retained when row 5,000 fails. If the developer unilaterally chooses "full rollback" to keep moving, that decision permeates transaction design, task status, result pages, and tests. Even with high code quality, it may contradict business expectations entirely.

Correct handling:

Non-blocking issues can be recorded and worked around; blocking issues cannot be guessed across. Developers may propose design suggestions but must not directly modify confirmed business rules and declare them effective.

Design Changes Must Propagate Invalidation

Correcting the document is only step one; new design conclusions can invalidate downstream artifacts. For example, changing bulk import from "all succeed or all fail" to "allow partial success" impacts task state, transaction commit, retry compensation, UI prompts, test cases, and runbooks.

If only the design file is updated without marking affected nodes, development and testing may continue around old rules. The artifact chain therefore needs not just versions but dependency and impact relationships. This is where a task graph provides real value: it not only schedules parallel work but also identifies which nodes must re-execute when an upstream baseline changes.

Document Quantity Should Be Driven by Decision Density

An artifact chain does not mean generating a large document for every phase. Three principles matter:

Single Responsibility — Each rule is fully defined in one authoritative location; other artifacts reference it, never duplicate it.

Expand on Demand — Business intent stays concise; design expands only what truly affects boundaries, states, and risks; implementation details belong in code and task plans.

Consumer-Oriented — Documents consider who reads them, for what decisions, and how to verify. Content with no downstream consumer and no impact on subsequent judgments need not be endlessly expanded for "completeness."

Context economy isn't writing fewer documents; it's ensuring every piece of context entering the current task has a clear purpose.

Version Records Are Not Correctness Evidence

Submitted artifacts and archived review records only prove actions occurred at a point in time. They cannot substitute for:

Requirements correctness — needs business confirmation and scenario acceptance.

Design feasibility — needs technical validation and impact analysis.

Implementation conformance — needs testing, diff checks, and runtime evidence.

Release permission — needs risk review and explicit authorization.

These three capabilities — version references, verification evidence, and review records — cannot replace each other.

Small Systems Can Start with a Minimal Artifact Chain

Low-risk small projects don't need a full requirement repository, architecture library, task graph, and evidence platform upfront. A single baseline document containing goals, boundaries, key design, and acceptance criteria, a set of development tasks linked to that version, and a CI pipeline that preserves test results can form the minimal chain.

When roles multiply, parallel tasks increase, and rules change frequently, then split artifacts and add dependency, state, and impact analysis. Artifact structure should solve real collaboration problems, not become a new documentation burden.

Summary

Specs are not better when more numerous. Real value lies in an executable artifact chain that connects business intent, design, plans, code, and verification evidence. It lets every role know what to trust now, where to return when gaps appear, and which downstream work becomes invalid when baselines change.

The next article will discuss: teams already have project charters, standards, and wikis — why do agents still repeatedly violate requirements, and how does organizational knowledge truly enter controlled execution processes.