Requirements Traceability in Practice: A Week Back per Trace

I spend most of my weeks inside customer engineering orgs, and the traceability graph is the use case where I watch the room change temperature. Let me give you a real one — anonymized, but the shape and the numbers are honest. A Tier-1 automotive supplier building an electronic braking control unit, roughly 140 engineers across firmware, systems, and verification, shipping under ISO 26262. This is the day-in-the-life, before and after.

Before: the Thursday that ate a week

Priya is a verification lead. On a Thursday she gets a change request: a control-loop coefficient in the brake-pressure module needs to move. Simple on the surface. But before anyone touches it, she has to answer the question every safety org has to answer — what does this line trace to? Which safety requirement justified this value, which hazard analysis it descends from, who signed off on it, and which tests protect it.

So Priya starts the archaeology. The requirement lives in Polarion. The commit history is in three Git repos because the module got split in a refactor two years ago. The tests are half in the vendor's test management tool and half as raw HIL scripts in a fourth repo. The approval is an email thread and a signed PDF in a document management system. She pings the original author — who left in March. She pings his manager. She reconstructs, by hand, a chain that used to exist in a traceability matrix that was last regenerated for the previous milestone and is now four sprints stale.

It takes her the better part of four days, spread across a week, pulling in two other engineers for pieces only they remember. Total, call it five engineer-days for one change's provenance. And the quiet danger: because the linked test had been renamed in the refactor, its link had silently rotted. If she'd trusted the stale matrix instead of digging, she'd have changed the coefficient believing a test protected it when the linkage was dead. That's exactly how a field escape is born.

After: the same Thursday, ninety seconds

Now the same team runs the traceability graph as a StudioX Mission. Priya opens the module in the portal, clicks the line with the coefficient, and asks: "Trace this both directions — up to the requirement and its approval, down to the tests and the release."

She watches it happen on the Explain rail. The Code Agent resolves the line to its current commit and the PR that introduced it. The Requirements Agent follows the PR's reference to the safety requirement in Polarion, and to the hazard analysis and the signed approval behind it. The Test Agent searches — and here's the moment — reports that the requirement's expected test, by ID, has no current link to any active test case, and flags it. The Release Agent maps the commit to the two production builds carrying it. Ninety seconds, and the full chain is on screen, with every link showing why it was drawn.

The dead test link — the thing that would have taken a field incident to discover — is surfaced before she makes the change. That's the escape that didn't happen.

The numbers that got the room quiet

We ran a structured pilot over one release cycle before rolling it out — trace the same set of change requests both ways, the old way and the mission, and measure. Across 60-odd traceability requests in the cycle:

• Per-trace time fell from an average of roughly a day-and-a-half of blended effort (the easy ones were an hour; the archaeology ones were the five-day monsters) to under three minutes.
• The verification team estimated it reclaimed on the order of three engineer-weeks per release cycle previously spent on evidence-gathering and matrix reconstruction — time that went straight back into actual test design.
• The formal audit prep for the cycle, historically a multi-week scramble with a dedicated analyst, became a live demo: the auditor picked lines at random and watched the chain assemble with its provenance trace. Prep collapsed from weeks to a briefing.
• Most important and hardest to price: two broken requirement-to-test links were surfaced during ordinary tracing that cycle — orphaned safety requirements whose protecting tests had rotted in refactors. Each one is a plausible field escape avoided. In a braking ECU, you do not need me to explain what one avoided escape is worth.

What made it land in the field

Three things, from the practitioner's chair. First, it's always current because there's no artifact — the chain is reassembled from the live systems on every click, so "the matrix is stale" simply stops being a sentence anyone says. Second, the observable trace is what won over the quality and audit people, not the engineers. They didn't want a faster black box; they wanted to see the provenance, and watching each link get drawn with a plain-language reason is more convincing than any exported PDF. Third, it's honest about scope: tracing is read-only, it changes nothing in their systems, and that was the precondition for even piloting it in a safety-critical program. When a trace did warrant an action — filing a task to repair a dead link — that went through the decision queue for a human to approve, not silently.

Getting there took days, not a quarter, because their tools wired in over MCP — Polarion, GitHub, the test manager, the release system each behind an instant MCP server the agents discovered at runtime. No integration project.

If you want the leadership case for why the stale-matrix model is broken, read Ajay's why it matters. If you want the architecture — the agents, the reasoning core, the trace — read Trevor's how it works. And if you're carrying a verification or audit burden right now, this is what AI Missions grounded in your own enterprise knowledge looks like on a real Thursday: the week Priya used to lose, handed back.