Rootshift. Let’s talk ↗︎
GUIDE / COMPARISONUPDATED OCTOBER 2026

Ground Truth vs spec-driven development and context engineering

Three ideas are converging on the same insight: AI agents build better from something written down than from a chat. They differ in what they treat as the hard part.

Three answers to one problem

ApproachThe question it answersWhat the agent gets
Context engineeringWhat does the agent see?The right files, docs, and examples in its window.
Spec-driven developmentWhat should the agent build?A structured specification, written before the code.
Ground TruthIs what the agent sees true, and who says so?Approved artifacts with owners, sources, and a decision log.

Each step keeps the previous one. A Ground Truth is still context, and its capability specs are still specs. What it adds is the state around them.

What a spec leaves out

A spec is a snapshot of intent, usually for one feature. On a real product, the reasons a feature must be built a certain way often live somewhere else:

A Ground Truth keeps all of this in one versioned model, and the builder brief for a story pulls in every decision and rule that touches it.

Three properties that are enforced

Where the difference costs the most

On products with years of decisions, several sources that disagree, money or compliance on the line, and more than one person who can say what is true. That is where an agent’s confident guess is most expensive, and where a spec without owners, approval state, and a decision log leaves the agent to guess.

Where this fits in Rootshift

In Rootshift, the Ground Truth comes first. Approved artifacts assemble into a deterministic builder brief: same Ground Truth in, byte-identical brief out. A fresh-context builder implements it, independent reviewers verify it, and the outcome goes back into the record. What a Ground Truth is, part by part.

Questions people ask

Is Ground Truth the same as spec-driven development?
It shares the starting point, that agents should build from a written specification, and goes further. A spec is a snapshot of intent. A Ground Truth carries ownership, provenance, approval state, integration contracts, business rules from other parts of the model, and the decisions that forbid the obvious implementation.
How is Ground Truth different from context engineering?
Context engineering answers what the agent sees. Ground Truth answers whether what the agent sees is true, and who says so.
Can I use spec-driven development tools with a Ground Truth?
Yes. A Ground Truth is plain markdown in a Git repository. In Rootshift, approved artifacts assemble into a deterministic builder brief, which is the spec a builder agent receives.