World Cup matches are often decided before the ball reaches the penalty area.

A striker may score the goal.

But the midfield made the goal possible.

The midfielder received under pressure, scanned the field, recognized which passing lane was still open, protected the team’s shape, and moved the ball before the opportunity disappeared.

A weak midfield does not always lack talent.

Sometimes it lacks continuity.

The defenders cannot connect with the attackers. The team has possession, but no progression. The ball moves, yet the idea behind the play is lost.

AI-native software delivery has the same problem.

Business intent may begin in a client conversation, a workshop, a product requirements document, or a strategic decision. From there, it travels through charters, requirements, specifications, plans, work items, code, tests, pull requests, reviews, approvals, and release evidence.

Every handoff is a chance to lose meaning.

By the time the software reaches production, the implementation may be technically valid and still fail to express the decision that started the work.

The challenge is not simply to give AI more context.

It is to preserve an authoritative thread of intent while the work moves.

The problem is not context volume. The problem is context continuity.

Context at rest is not context in play

Most organizations do not suffer from a complete absence of information.

They have meeting notes, roadmaps, product documents, policies, tickets, architecture decisions, security standards, design files, code repositories, and knowledge bases.

The difficulty is that those artifacts often live in different systems, follow different versions, and serve different audiences.

A document repository can store the playbook.

It cannot guarantee that the right rule will shape the next decision.

A product requirements document can explain the desired outcome.

It cannot, by itself, ensure that every task, code change, test, and approval remains connected to that outcome.

A ticket can tell a developer what to do next.

It may not explain why the work exists, which constraint has authority, or what evidence will prove that the result is acceptable.

Article 3 of this series established that context must be situated and reusable. Specs and constitutions can make human intent more legible to AI.

This article begins where that one ended.

Google Cloud’s 2026 DORA ROI report offers the same systemic warning: AI can create localized productivity that disappears in downstream chaos when the surrounding workflows and engineering systems are weak. Intent decay is one concrete way that chaos enters the delivery process.

The question now is not only:

What context exists?

It is:

How does approved context move through execution without becoming fragmented, stale, or unverifiable?

Intent decay happens one reasonable handoff at a time

Intent is rarely lost through one dramatic mistake.

It usually decays through a sequence of reasonable local decisions.

A client says:

Customers should be able to request a refund without contacting support, but high-value transactions and suspicious accounts must still be reviewed.

The meeting summary becomes:

Enable self-service refunds.

The product document captures the happy path but leaves the risk threshold unresolved.

The work item asks for a refund button.

The coding agent implements the button and endpoint correctly.

The tests confirm that a standard refund succeeds.

The pull request is clean.

The feature ships.

Every artifact may look plausible in isolation.

The system can still be wrong.

The original intent included a business outcome, an exception model, a risk boundary, and a human review condition. Those elements disappeared gradually as the work moved from one representation to another.

This is intent decay.

It appears through several recurring failure modes:

• Compression loss: a nuanced decision becomes a short ticket.
• Fragmentation: requirements and constraints are distributed across documents with no authoritative relationship.
• Version conflict: different teams act on different versions of the same decision.
• Hidden constraints: security, architecture, data, or compliance rules never reach execution.
• Orphaned work: a task or pull request cannot be traced to an approved requirement.
• Evidence gaps: the organization knows that something shipped but cannot reconstruct why it was accepted.

AI increases the importance of this problem because agents can transform ambiguity into output at extraordinary speed.

A human developer may pause when a ticket is incomplete.

An agent may infer the missing pieces, choose a reasonable interpretation, and continue.

That can look like productivity.

It may actually be accelerated intent decay.

The baseline is a decision, not a transcript

The first responsibility of the midfield is to receive the ball cleanly.

In delivery, that means establishing an approved baseline before downstream execution begins.

At Celerik, one common path starts with PMing, our AI-assisted discovery companion for turning project conversations and source material into a human-reviewable baseline.

It can work with client conversations, transcripts, existing documents, constraints, and discovery material to help structure a draft project charter, functional and non-functional requirements, risks, assumptions, and initial estimates.

But the AI-generated draft is not yet the baseline.

A responsible human reviews it, corrects it, resolves ambiguity, and approves the version that can guide the work.

Once approved, it becomes the first authoritative expression of intent.

QMing does not require PMing to begin this process.

Many organizations already have an approved product requirements document, or PRD, supported by existing business, product, compliance, or architecture artifacts. In that case, the PRD can become the starting point for the same spec-driven flow after it has been validated as sufficiently complete and authoritative.

There are therefore two legitimate entry paths:

1. PMing-assisted discovery → human-approved baseline
2. Existing PRD → validation → approved baseline

The necessary condition is not the use of PMing.

The necessary condition is a baseline that someone is authorized to approve and the organization is prepared to treat as the current source of intent.

No agent should be forced to guess what the organization has not yet decided.

From an approved baseline to executable specifications

An approved baseline is necessary.

It is not sufficient.

The organization still has to translate business intent into a structure that humans and AI agents can execute, inspect, and evolve.

This is where spec-driven development becomes operational.

GitHub’s open-source Spec Kit organizes development around a constitution, a specification, an implementation plan, tasks, and execution. Its central idea is that the specification should become a primary artifact for building and validating the system, not documentation written after the code already exists.

At Celerik, QMing integrates that foundation into a broader traceable delivery flow.

The current operating model can be represented as:

Approved Baseline
(PMing output or validated PRD)
        ↓
Layered Constitution
        ↓
Feature Specification
        ↓
Technical Plan
        ↓
Small, Reviewable Tasks
        ↓
Work-Management Mapping
        ↓
Human and AI-Assisted Execution
        ↓
Verification and Human Decision
        ↓
Release Evidence

The sequence matters because each artifact performs a different function.

The baseline states the approved need.

The constitution states the rules that must shape execution.

The specification defines the expected behavior and success criteria.

The plan explains the technical strategy.

The tasks create bounded units that can be delegated and reviewed.

The work-management layer coordinates real delivery.

The evidence layer shows what happened and why the result was accepted.

This is not a longer prompt.

It is a chain of transformations with accountability at each step.

Constitutions preserve the rules that must survive every pass

A PRD tells the team what outcome the product should create.

It does not contain every rule the organization must apply while creating it.

Those rules may live at several levels:

• company-wide engineering and security principles,
• area-specific standards for data, AI, architecture, accessibility, or operations,
• project-specific constraints, risks, and non-functional requirements,
• reusable technical patterns and approved implementation templates.

QMing’s spec-driven flow can compose those layers into a unified, versioned constitution for the project.

The purpose is not to create another policy document that nobody reads.

The constitution must shape the generation of the specification, plan, tasks, tests, and review expectations.

It should answer questions such as:

• Which security practices are mandatory?
• What data may the system process?
• Which architectural boundaries cannot be crossed?
• What testing evidence is required?
• Which changes need formal human approval?
• Which patterns are approved, discouraged, or prohibited?

The baseline says:

What are we trying to achieve?

The constitution says:

What rules must remain true while we achieve it?

A team that rewrites those rules in every prompt is not creating context architecture.

It is recreating institutional memory one request at a time.

A specification must be testable, not merely eloquent

A good specification is not valuable because it sounds complete.

It is valuable because it creates a shared, testable definition of what the system should do.

For AI-assisted delivery, a useful feature specification should make explicit:

• the intended user or actor,
• the desired outcome,
• the primary and alternative journeys,
• acceptance criteria,
• non-functional requirements,
• constraints and exclusions,
• known edge cases,
• risk classification,
• expected tests and release evidence,
• links to the approved baseline and applicable constitution.

QMing uses the approved baseline and governing constitution to help structure this specification through the Spec Kit flow.

A human still has to validate it.

That is important because a model can create a well-formed document while misunderstanding the business.

The specification should then produce a technical plan and a set of small, reviewable tasks.

Those tasks may be assigned to a human developer, an AI coding agent, or a hybrid workflow. The delegation decision should depend on complexity, risk, reversibility, and the quality of the available context—not on an assumption that every task should be automated.

The spec is therefore not simply a prompt.

It is a governed contract for execution.

Composable tooling, not a new walled garden

A traceable delivery system should not require every organization to abandon the tools it already uses.

At Celerik, one implementation of this model uses Azure DevOps for work management and pipeline orchestration.

That is an implementation choice, not a product boundary.

Another organization may use Jira for work management and Confluence for knowledge. Others may use different combinations of repositories, CI/CD platforms, documentation systems, and approval tools.

QMing is designed around the relationships among artifacts and events, not around one vendor’s interface.

The mapping can adapt to the taxonomy of the destination system.

For example:

Feature Specification → Feature or Epic
User Journey / Acceptance Criteria → Story
Implementation Unit → Task or Sub-task
Architecture or Policy Decision → Linked Knowledge Artifact
Code Change → Commit / Branch / Pull Request
Verification Result → Check / Finding / Approval
Release Decision → Evidence Bundle

The names can change.

The traceability contract should not.

A work item must still link back to the specification that authorized it.

A pull request must still identify the work it implements.

A test result must still connect to the acceptance criterion it supports.

A release decision must still preserve the evidence and human accountability required by the project’s risk profile.

Tool neutrality does not mean reducing every system to the lowest common denominator.

A real integration must respect local fields, statuses, permissions, approval rules, and reporting needs.

But it should allow an organization to change tools without losing the meaning of the delivery chain.

The architecture should be coupled to intent, not to a vendor.

What QMing adds to the flow

Article 5 introduced one visible side of QMing: its quality and governance controls.

The broader role of the software is to connect the operating chain that makes those controls meaningful.

QMing brings together six functions.

1. Baseline normalization

It can begin with structured artifacts produced through PMing or with an existing validated PRD. The source may differ, but the approved baseline and its version must remain identifiable.

2. Constitution composition

It combines persistent organizational rules with domain and project constraints so agents do not reinvent the operating boundaries for every task.

3. Spec-driven orchestration

Its spec-driven module works with the GitHub Spec Kit flow to create and evolve specifications, plans, tasks, checklists, and related execution artifacts.

4. Delivery-system mapping

It maps those artifacts into the organization’s existing work-management and knowledge systems, preserving the relationships between intent, scope, ownership, and execution.

5. Traceability and change propagation

It maintains the thread across requirements, work items, code changes, tests, findings, approvals, and release evidence, while making the impact of approved changes visible downstream.

6. Quality, governance, and evidence

It applies the preventive, assisted-review, and intent-alignment controls introduced in The AI VAR and captures the evidence required for human decisions and release reporting.

This distinction matters.

QMing is not simply a final quality gate.

QMing is the software that carries the spec-driven, traceability, governance, and evidence flow.

PMing can be its discovery companion.

A validated PRD can also be its starting point.

Azure DevOps can be one execution environment.

Jira and Confluence can be another.

The product remains the same because its responsibility is to preserve the delivery logic across those variations.

The pass must work in both directions

Real projects change.

A client clarifies a rule.

A regulator introduces a new requirement.

A technical dependency becomes unavailable.

A security review identifies a new constraint.

A user test reveals that the original journey is incomplete.

A traceability chain that only moves forward will become obsolete as soon as reality changes.

The midfield must be able to reset the play.

In a mature spec-driven flow, an approved change should trigger a controlled loop:

Change Trigger
      ↓
Impact Assessment
      ↓
Human Decision and Baseline Update
      ↓
Spec / Plan / Task Regeneration
      ↓
Synchronization with Delivery Systems
      ↓
Re-alignment of Tests, Controls, and Evidence

The important word is approved.

An AI assistant can identify likely impact, propose updates, and regenerate dependent artifacts.

But the organization still needs a decision owner who can approve the new baseline and accept the consequences of the change.

This is where many attractive spec-driven demonstrations stop too early.

They show how to generate a plan from a prompt.

Real delivery must also show how the system responds when the plan changes.

A concrete play: from PRD to release

Consider a company building delegated invoice approvals for business customers.

The PRD states that a manager may authorize another employee to approve invoices below a configurable threshold.

That sentence is not enough to build safely.

The approved baseline must clarify the business objective, eligible roles, audit expectations, country-specific restrictions, and the owner of the threshold policy.

The constitution may require role-based access control, immutable audit events, encryption of sensitive fields, defined test coverage, and formal review for authorization changes.

The feature specification translates the baseline into user journeys and acceptance criteria:

• an authorized manager can delegate approval rights,
• the delegate cannot exceed the approved threshold,
• the delegation has a start and expiration date,
• every approval records the acting user and the delegating manager,
• revoked delegation takes effect immediately,
• unauthorized attempts are rejected and logged.

The technical plan defines the data model, API changes, authorization checks, interface behavior, migration approach, and test strategy.

The tasks are small enough to review independently.

QMing maps them into the team’s work system. In one organization, that may create an Epic, Stories, and Tasks in Jira. In another, it may create a Feature, User Stories, and Tasks in Azure DevOps.

The relationship to the same specification remains intact.

A human or AI agent implements a bounded task.

The pull request links to the work item and specification.

Tests produce evidence against the acceptance criteria.

QMing’s quality layers inspect deterministic hygiene, technical quality, and alignment between declared intent and actual change.

A qualified human makes the decision that the evidence supports the merge or release.

Now imagine that the client changes the rule: the threshold must vary by country and invoice category.

The change should not survive as a comment in a meeting transcript.

It should trigger impact assessment, a new approved baseline version, updates to the specification and plan, regeneration or revision of affected tasks, and re-alignment of tests and evidence.

That is context architecture in motion.

The midfield test for leaders

Leaders do not need to read every specification or inspect every pull request.

But they should be able to ask the system a small set of questions and receive credible answers:

• Which approved source authorized this work?
• Which version of that source was used?
• How was the decision translated into the specification and tasks?
• Which code changes and tests implement each acceptance criterion?
• What changed after the original approval, and where was that change propagated?
• Which controls ran, which findings were resolved, and which were accepted as residual risk?
• Who made the final human decision?
• What evidence supports the release?

If the organization cannot answer those questions without reconstructing the project manually, it does not yet have an intent-continuity system.

It has a collection of tools.

What should become observable

The goal is not to measure people more aggressively.

It is to make the health of the delivery chain visible.

A few useful operational signals include:

• Baseline-to-spec cycle time: how long it takes to translate an approved need into an executable specification.
• Spec coverage: the percentage of active work items connected to a current specification.
• Orphaned work rate: work items or pull requests with no valid link to approved intent.
• Intent-drift rate: implementations that fail alignment with the specification or acceptance criteria.
• Change-propagation latency: the time required to synchronize an approved change across affected artifacts.
• Evidence completeness: the proportion of required tests, findings, approvals, and release records available at decision time.

These metrics do not replace the broader AI Scoreboard introduced in Article 4.

They reveal whether the midfield is doing its job.

The sixth principle of The Human-AI Playbook

Context architecture is not a larger prompt window.

It is not a knowledge base with more documents.

It is not a ticket with a link pasted into the description.

It is a living, versioned, tool-adaptable chain that connects an approved decision to specification, execution, verification, human accountability, and evidence.

The more capable AI agents become, the more important this chain becomes.

Powerful attackers do not solve a disconnected midfield.

Powerful coding agents do not solve fragmented intent.

They accelerate whatever system gives them the ball.

At Celerik, QMing is how we are turning this principle into software: beginning with PMing or an existing PRD, structuring the work through a Spec Kit-based flow, adapting to the organization’s delivery stack, and preserving traceability from intent to evidence.

The goal is not to force every team into the same tool.

The goal is to help every team keep its shape while humans and AI move faster together.

Work with us

Celerik helps organizations design and implement traceable AI-assisted software delivery through:

• QMing discovery and architecture assessments,
• PMing-to-QMing and PRD-to-QMing pilots,
• spec-driven delivery design using GitHub Spec Kit foundations,
• adaptation to existing work-management and knowledge platforms,
• constitution and policy integration,
• traceability, verification, and evidence design,
• and Human-AI Work Design for the teams operating the system.

A pilot can begin with the tools your organization already uses.

The first task is not replacing the stack.

It is establishing the unbroken thread that the stack must preserve.

Follow the series

This article is part of The Human-AI Playbook, a Celerik series about moving from AI tool adoption to Human-AI Work Design.

Published so far:

1. 11 Agents Are Not a Team
2. The First Bad Match Is Not Failure
3. The Same Playbook Won’t Work for Every Team
4. The AI Scoreboard
5. The AI VAR
6. The Midfield Problem

Sources and further reading

• GitHub Spec Kit — open-source toolkit for spec-driven development.
• Google Cloud / DORA — The ROI of AI-assisted Software Development (2026).