Field note 02

Bidirectional Traceability

Ensuring integrity when ground-truth discoveries reshape executive intent.

Most traceability models run one way: objective to requirement to spec to tasks to code to tests. 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 the requirement itself is wrong, ask to change the requirement, 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 requirement? *Update the implementation and tests.*
• Clarifies the requirement? *Update the spec and its tests too.*
• Changes product behavior? *Get the requirement changed before you ship, not after.*
• Reveals an operational gap? *Update the runbook.*
• Reveals delivery risk? *Update the task plan or the gate.*

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

This matters more with AI in the loop, not less. AI makes plausible implementation cheap. When AI makes implementation cheap, the harder questions are: Does the code still serve the intent? And did what you learned building it, make it back into the team's shared understanding?

"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 intent 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.

None of them invented the pattern. 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.