Bidirectional Traceability

Ensuring integrity when ground-truth discoveries reshape executive intent.

Most traceability models run one way: objective to intent to build to proof. When the thread holds, you can justify any line of code by walking it back to an approved intent.

That model is useful. It's also incomplete. Discovery doesn't only happen at the top. A test reveals a requirement was ambiguous. Code exposes a platform constraint nobody wrote down. A production incident reveals an operational requirement that was never spec'd. A user session shows a feature meets the letter of the spec while missing the actual need.

AI makes building cheap. The hard parts become: a) Keeping code aligned with intent, and b) Ensuring ground-level discoveries update the shared understanding of the system.

If truth is only allowed to flow downward, these discoveries become awkward. Teams patch around them, or let the system quietly drift: the paperwork says one thing, the code says another, and everyone knows which one is real.

The fix is a pattern every engineering team already has: the pull request. Applied upward.

If code reveals the spec is incomplete, open a request against the spec. If a test shows an acceptance criterion is ambiguous, point the request at the ambiguity. If production behavior shows that the stated intent itself is wrong, ask to change it, don't just patch the code around it.

Call it a pull request for intent: evidence from below, a decision from above, then the thread reconciles forward again.

In practice:

Fits the current intent? Update the build and tests.
Clarifies the intent? Update the spec and its tests too.
Changes product behavior? Get the intent changed before you ship, not after.
Reveals an operational gap? Update the runbook.
Reveals delivery risk? Update the task plan or the gate.

Update, August 2026: when this note was written, "a pull request for intent" was a proposal. It has since shipped as mechanism, in SpecAssay. The registry of intent is a file in the repo, so changing intent literally travels as a pull request, reviewable like any other diff. New intent can enter from below through anointed backlog: mint the ID, carry it on one open TODO, and it rides visibly until a spec claims it. And the reconcile-forward step is no longer manners; the Gate's exact-set check fails the build when the registry, specs, and tasks disagree. Evidence from below, a decision from above, enforced on every push.

Not top-down control. Not bottom-up chaos. A thread that stays connected while the system learns.

"Self-healing documentation" isn't quite right; it gives the tool too much credit. People and tools maintain a system, it doesn't maintain itself. The better aim is trace-preserving change: when something changes, can you quickly answer what requirement it touches, what proves it, what's now stale, and whether it needs a decision from someone above.

This is already showing up as capital, not just conviction. 8090.ai, where Chamath Palihapitiya took over as CEO on a $135M round, is building "Software Factories" around exactly this idea: a knowledge graph meant to run in both directions between requirements and code. Tessl, founded by Snyk's former CEO, and Factory.ai, backed by Sequoia, are placing similar bets from different angles. And it isn't only the venture-backed: Thorsten Schlathölter has been working the same seam from the open-source, inner-loop side — his Code-Anchored Spec-Driven Development makes traceability a structural property of the codebase, the trace derived from the work rather than running beside it, with an open tool, clew, that makes the links compiler-checked rather than curated by hand. More of this is coming, from more corners than the funding announcements suggest.

None of them invented the pattern. Neither did I. Avionics and medical device standards have required traceability to run in both directions for decades. What's new is that a build can check it. All of them are betting the market will pay for the discipline.

Not a command chain. Not a free-for-all. A thread that talks back, and gets stronger every time it does.

Want to see this enforced in CI instead of described in a slide? Here's the repo. Or let's talk it through.