Why AI-native delivery needs a shared Ground Truth

Agile was a good answer to a problem that no longer exists.

The problem was that building software was slow and expensive, requirements moved faster than teams could build, and the only way to survive was to shorten the loop: build a little, show it, adjust. Sprints, standups, story points, the retro. Every one of those rituals exists to protect a scarce resource called engineering hours from being spent on the wrong thing for three months before anyone noticed.

An agent can now produce a working implementation of a user story in minutes. It can produce five. The cost of building the wrong thing collapsed, and with it went the reason for most of the ceremony around building. What did not collapse is the cost of not knowing what the right thing is. If anything it went up, because the wrong thing now gets built, reviewed, merged, and shipped faster than anyone can catch it.

The bottleneck moved. It used to sit in the build. Now it sits in the truth the build is derived from. Let me show you what that looks like on a real project before I explain how we deal with it.

The moat that lived on one database

We took over a mobile product from its founder this year. Independent professionals use it to front large purchases on a job and get reimbursed against receipts when the job ends. Every receipt, return, rental, and shipment has to reconcile to the cent, because the user is personally liable for the money. The founder had built the first version in an AI app builder, and our mandate was to adopt the code as it was and keep shipping on top of it. Not a rewrite. Not an audit.

We started from what any funded prototype has. A founder walkthrough transcript. A few dozen feature specs. A project-context document, a board of what was broken, and the code, which on a takeover is a primary source. An intake agent ingested all of it, interviewed our engineer for whatever the documents did not say, and drafted a model of the product. Humans then went through it and validated.

On the first day of that intake, the agent found that the product’s stated competitive moat did not exist in the repository.

The founder’s differentiator is a set of curated reference databases. The migrations seed a few dozen rows into one table. The other tables are empty. Roughly a thousand curated records lived only on the hosted database, with no export, no seed, and no recovery path, and their total was quoted four different ways across the documents. No line of code was wrong. Every test passed. A code review would have found nothing, because there was nothing to find in the code. The problem was a fact about the business that nobody had written down in a place where it could be checked.

It was not the only one.

During the kickoff demo the founder had flagged the black-and-white receipt preview as a defect. Months later, seeing it in context, he reversed himself: a receipt on a project brief should look like a document scan, and the color photo has a different job, which is verification. He attached a condition, that the original photo must stay viewable. Two decisions in two different documents, one superseding the other, with a condition hanging off the second one that constrains how the feature has to be built. On most projects that nuance lives in one person’s head and leaves with them.

The founder’s first rule for the product is that every money figure has to be right, because one wrong number destroys trust in every number after it. That rule has corollaries nobody had stated as rules. An AI extraction that fails must return an error, never a success with empty data, because an empty success reads downstream as “no purchases” and corrupts a report while showing a clean screen. A receipt’s total is the grand total the customer paid, never the subtotal, because a receipt image contains several plausible numbers labelled total, and sales tax on a large purchase is real money. None of that appears in a story that says “extract the fields from a receipt.”

And a single word. The founder had reframed the product from a financial tool to a co-worker, and one consequence was that user-facing copy says “open”, never “overdue”. Copy only. What counts as late was deliberately left alone. That instruction existed in a meeting note. The code still said “overdue” in a dozen places, and one unit test asserted that it should.

Now imagine handing that project to an agent with all of the source material loaded into its context. The transcript, the specs, the board, the code. Ask it to build the next story.

What an agent does with a pile of context

It does not stop. It picks.

An agent with contradictory context picks confidently, usually whichever version was more salient in its window, and then writes clean, tested, well-commented code implementing the wrong thing. Given the receipt story, it extracts the number labelled “Total” and passes its tests. Given the preview story, it finds the defect register and restores the color photo, undoing a decision the founder made months later in a different document. Given a Home screen story, it writes “3 days overdue” because the code around it does, and the test agrees. The output looks finished. Nobody notices until the user does.

This is why “give the agent more context” is the wrong answer to the wrong question. Context engineering answers “what does the agent see?” The expensive question is “is what the agent sees true, and who says so?” A Slack thread from March, a Notion page from May that contradicts it, a design file updated after the spec, a README two refactors old, a ticket that cites a decision nobody recorded. Load all of that into a window and the agent has the same contradictory pile a new hire gets on day one, minus the ability to walk over and ask.

Specs are closer, and we write a lot of them. A spec answers “what should this do?” It does not say who is accountable for it being right or when they last confirmed it. It does not carry the business rule that constrains the feature from three folders away, or the decision made for a different capability that forbids the obvious implementation here, or which of its own sentences were validated and which are someone’s best guess written in the confident voice specs are always written in. A spec is a snapshot of intent. Something has to make the spec trustworthy, and tell you which specs are not trustworthy yet.

That something is what we call a Ground Truth.

What a Ground Truth is

At Rootstrap we run delivery on a method we call Rootshift, and its first principle is one sentence: software is downstream of truth. Model the business first, derive the code from the model. The Ground Truth is that model. In practice it is a Git repository of structured markdown artifacts that describes how a product and its business actually work, precisely enough that a person and an agent can both build against it and verify against it. It sits next to the code repository, never inside it, with its own history, its own owners, and its own checks.

Every Ground Truth has the same seven parts, with the same folder names on every project:

1. 01 Project Context. Goals, audiences, stakeholders, constraints, success metrics, non-goals, and the open questions nobody has answered yet.
2. 02 Domain Model. Entities, vocabulary, states, business rules, edge cases.
3. 03 Capability Specs. The capabilities and, under each, its user stories with acceptance criteria written as Given/When/Then scenarios.
4. 04 Engineering Context. Architecture, stack, repository structure, conventions, security, deployment.
5. 05 Integration Contracts. Every external system, what it owns, the source of truth per field, sync direction, and what happens when it fails.
6. 06 Eval Suite. The named checks that prove a capability does what its spec says, one per acceptance criterion.
7. 07 Decision Log. Every material decision as its own artifact: who made it, when, why, what alternatives were rejected, what it changed. Decisions are never rewritten, only superseded.

Nobody on a project says “part three”. Day to day the vocabulary is capabilities, stories, decisions, contracts, and evals, and those five words carry most of the weight.

A capability is a business function, a verb: scan a receipt, track a return, reconcile a statement, invite a collaborator. It has to pass a short test to earn the name. It is something the system does rather than a page or a screen. It is a unit of value you could scope and deliver on its own. It is made of several stories, each with acceptance criteria and evals. Pages, posts, and assets are content, and they live in the domain model as things capabilities operate on. Every capability also carries a class, a tier and a size, so that a capability on one project is comparable to a capability on another. That is what lets us forecast from delivered history instead of estimating in points.

Every artifact opens with a metadata block, and the rule is simple: no metadata, not Ground Truth. The block carries a stable id, an owner who is a named human accountable for the artifact being true, a status that moves through draft, in-review, approved, needs-revalidation, and deprecated, a confidence level, a sources list where every claim traces to a dated interview, document, live page, or piece of code, a last_validated date, and an applies_to scope that says which surfaces the artifact governs.

If it is not structured, owned, versioned, and validated, we do not call it Ground Truth. It is documentation. Documentation is useful, and an agent should not be allowed to build production software from it.

Go back to the takeover with that structure in mind. The moat became an open decision on day one, routed to the founder’s team, and a few weeks later a recorded decision with a refresh-and-backup policy attached. The receipt preview became two decisions, the second superseding the first, with the founder’s condition written into the acceptance criteria the builder is held to. The money rules became named business-rule artifacts, each with the reason it exists and the exact places in the code where it is enforced, linked to every capability they touch. “Open, never overdue” became a vocabulary entry, and the checker now lists where the code still disagrees with it.

Six weeks in, this is what the model held:

On the code side, 370 pull requests had merged since the takeover, and 287 of them name the acceptance criteria they satisfy in a spec-trace section. The open decisions are not a backlog of embarrassment. They are the questions the model is honest about not being able to answer yet, each with an owner, and the readiness gate will not let a build proceed past one that blocks it.

What makes it hold

Three properties separate this from a well-organized wiki, and each is enforced by a check rather than a guideline.

Validation state is explicit and machine-readable. Agents may read anything in the package, and they may only build production code from artifacts marked approved. Approval is an independent judgment: a human approves anything that adds content to the model, and a story that sits under an already approved capability is approved by the independent reviewer that checked it. A builder that needs a draft artifact for a spike has to flag the dependency and route it to a person. A readiness gate reads the statuses before every build and refuses to dispatch a story that depends on unapproved truth.

Contradictions are defects. A story that cites an open decision which has already been resolved is a checker error. Two artifacts that disagree on the same fact are a blocking finding, and no agent is allowed to interpret its way around one. When a source behind an approved artifact changes, the artifact flips to needs-revalidation and is treated as unapproved until a human re-checks it. On the takeover, client feedback arrived on the receipt-scanning capability weeks after it had been approved. The capability flipped back with a note saying what changed, nothing in the approved body was rewritten, and only the operator could approve it again. People read that status as a failure the first time they see it. It is the lifecycle working.

Gaps become routed work. When an agent hits something it must not decide, a product call, a business-rule conflict, an architecture trade-off, it does not fill the hole. It writes a decision artifact marked open, with the options, the affected areas, its recommendation, and its confidence, routes it to the artifact’s owner, and moves on to work that is unblocked. When the human answers, the same artifact becomes the record, with who decided and when. Every dependent story unblocks from that record. Client decision latency is measured, because both dates are on the artifact.

Around those three sit the mechanics. A human validates anything that adds content to the model, always. The capability is the unit of review, so approving a capability approves its stories in the same act, and validation is a few focused sessions rather than a hundred micro-approvals. Sources carry dates, and confidence follows a rubric: high requires a primary source and human validation; low means inferred, stale, or conflicting, and low-confidence truth cannot underwrite a priced capability. A consistency checker runs on every write. Every builder gets a deterministic brief assembled from the model: the story verbatim, its capability, the decisions and rules that touch it, the engineering context, a pointer card to the repository. Same Ground Truth in, byte-identical brief out. An independent reviewer panel checks the result against the same model. When a story ships, the loop records the pull request against it, and anything the build revealed goes back into the model through review.

One more thing we learned about the checks: they have to be calibrated. A rule we shipped treated an unresolved scope field as a global error, and on a live engagement 164 stories used surface names rather than repository names. The delivery loop went down over a naming convention, and the developer’s reaction was the real finding: he read the check as noise and worked around it. We had also written a contradiction into our own templates, so following our instructions produced one error per story. The fix made the rule a warning globally and a blocking hole only for the story being built, with the one-line remedy in the message. A gate that stops everything teaches its operator to wave things through.

Where the discipline goes

I said agile solved a problem that no longer exists, and I want to be precise about what I mean.

The rituals of agile manage the cost of building and the cost of being wrong about what to build, under the assumption that both are expensive and the only way to learn is to ship and look. Story points estimate build effort. Sprints batch it into reviewable windows. Standups synchronize the humans doing the building. When a fresh-context agent can build a story in minutes, a second independent agent can review it, and a third can run the acceptance evals, the build-side machinery has very little left to manage. We stopped estimating in points. We forecast from our own delivered history, because the history is now dense enough to forecast from.

What survives is the insistence that certainty is earned by shipping. A validated model is enough to start. A mistake is cheap, because it is a Ground Truth fix and an agent re-run rather than weeks of rework.

What changes is where the discipline lives. It moves out of the ceremony around the build and into the truth before the build. The scarce resource is no longer engineering hours. It is human judgment: the product call, the business-reality conflict, the “is this actually true?” An hour of that judgment spent chasing status or re-verifying what a gate already proved is wasted. An hour spent validating an artifact is leveraged, because dozens of agent runs will build against it without asking again.

We have not finished figuring this out. Validation tends to concentrate on one or two people, and we are still learning how to spread and batch that load so it does not become the new bottleneck. The model lags reality when the business moves faster than the review cadence, and needs-revalidation is a way of noticing that, not a fix for it. And the discipline of writing a decision down when the answer feels obvious in the moment is one people resist, right up until the third time the same question gets asked.

But the direction is clear enough to commit to. On that takeover, the most valuable thing the agents did in their first week was not writing code. It was finding the thousand records nobody could recover, the condition nobody had written down, and the word nobody had told the codebase about. The model comes first, a named person signs it, the agents build from it and are forbidden to contradict it, and every claim in the software traces back to who said it and when. Everything else in how we deliver follows from that.