Okay so here is a question that keeps coming up in Agentic Engineering: how do you know your product values are actually being enforced in the code?
It is one thing to write “zero fabricated content” in a product document. It is another thing entirely to have a chain of evidence connecting that belief to a specific test case that will fail if the agent fabricates something. I have been building these chains — I call them traceability chains — and they have become one of the most valuable patterns in this entire series.
The Problem: Values Without Enforcement
Here is a scenario. You write a product spec that says: “The system must never fabricate achievements or metrics in generated resumes.” Great principle. Everyone agrees.
But then the agent builds the system, and somewhere in the prompt construction logic, there is nothing stopping the LLM from filling in plausible-sounding numbers. The tests pass because they test that a resume was generated, not that every bullet point traces back to real source material.
The product belief exists. The enforcement does not. There is a gap in the middle.
This gap is especially dangerous in Agentic Engineering because AI agents do not have institutional memory. A human developer who wrote the product spec will naturally write code that aligns with it. An AI agent reads whatever context is provided and makes its best attempt. Without explicit chains, the agent will generate code that looks right but might not enforce the constraints that matter most.
Traceability chains close that gap.
Six Chains That Actually Work
In my system, I maintain six verified chains. Each one connects a high-level requirement to a low-level enforcement mechanism:
Chain 1: Belief → Enforcement
From: PRODUCT_SENSE.md core beliefs (e.g., “No fabrication is the paramount quality attribute”)
To: DESIGN.md traced-to field + specific linter rules and test cases
For every product belief, there must be a measurable enforcement mechanism. If the belief says “no fabrication,” there must be a test that catches fabrication. This chain connects the golden principles in CLAUDE.md (from Part 4) all the way down to specific test assertions.
Chain 2: SLO → Test
From: RELIABILITY.md SLOs (e.g., “Per-job processing time < 10 minutes”)
To: Performance assertions in the test strategy
Every Service Level Objective has a corresponding test assertion. If the SLO says 10 minutes per job, there is a performance test that fails at 10 minutes and 1 second. The SLO is not a wish — it is a test case. This chain also connects to the product guardrails I will cover in Part 9.
Chain 3: Design Doc → Spec (Bidirectional)
From: DD-XXX design documents (generated by the Domain Designer persona from Part 3)
To: product-specs/*.md specifications
Every design decision has a corresponding product spec, and every product spec references its design doc. This bidirectional link means you can start from either end and trace to the other. No orphaned decisions. No specs built on undocumented assumptions.
Chain 4: Spec → Test
From: Acceptance criteria (Given/When/Then format)
To: Test cases
Every acceptance criterion in every product spec has at least one corresponding test case. The Given/When/Then format makes this almost mechanical — the “Given” becomes setup, the “When” becomes action, the “Then” becomes assertion. This is what makes the dual quality gates in Part 7 possible.
Chain 5: Domain → Data Ownership
From: ARCHITECTURE.md domain definitions
To: Product spec data requirements
Each domain owns specific data entities, and that ownership is reflected in both the architecture doc and the product specs. This prevents the classic “two services writing to the same table” problem.
Chain 6: Feature → Flag
From: Product spec features
To: Unique feature flag names
Every feature has a unique flag identifier. This seems minor until you need to disable a feature in production and cannot figure out which flag controls which behavior.
How to Verify Chains Are Not Broken
Having chains is only useful if you can verify they are intact. The forensic verification pass I describe in Part 6 checks all six chains by:
- Scanning every product belief and confirming a traced-to enforcement exists
- Walking every SLO and confirming a corresponding performance test exists
- Cross-referencing design docs and specs to ensure no orphans in either direction
- Matching acceptance criteria to test case identifiers
- Verifying domain ownership declarations against data requirements
- Checking feature flag uniqueness across all specs
The most recent verification found: 0 broken chains across all 6 types. Every belief has enforcement. Every SLO has a test. Every decision has a spec.
Why This Is an Agentic Engineering Pattern
Traceability is not new — it has existed in safety-critical systems engineering for decades. What makes it an Agentic Engineering pattern is the reason it is necessary.
In traditional development, traceability is a compliance exercise — you do it because regulators or auditors require it. In agent-driven development, traceability is a correctness mechanism — you do it because without it, the agent has no way to verify that its output aligns with your intent.
The “No Fabrication” chain is the perfect example. In a resume tailoring system, fabricating an achievement is not a bug — it is a career risk for the user. The traceability chain ensures that this product belief is not just a nice sentence in a document. It is a test that fails, a validation that catches, an agent instruction that constrains.
Getting Started
If you want to implement traceability chains in your own Agentic Engineering process, start with just one: Belief → Enforcement. Take your three most important product values and ask: “If the code violated this value, which test would fail?” If the answer is “no test would fail,” you have found your first gap to close.
The six-chain model might be overkill for smaller projects, but even one or two chains fundamentally change how confident you are that your system does what it claims to do.
What traceability practices are you using in your projects? I am curious whether others have found different chain types that work well.