The Configuration Still Passes. Does the Rationale?

Where the evidence stays green and the decision underneath it quietly stops being one the organisation can defend.

A design decision can carry a documented rationale, complete traceability and a passing test, and still stop being valid, without anyone touching the system that carries it. That happens when the decision depended on something outside the configured application — an authoritative data source, a role's independence, a process boundary — staying true, and that something changes while the configuration never does. I call the thing that has to stay true a decision validity condition.

The test is simple: if this condition changed while the configuration stayed exactly as it is, would the organisation need to reconsider whether the design was still right? If yes, it's carrying part of the architecture decision, whether or not it lives inside Vault. A requirement can still be approved, the configuration can still match it, the test can still pass, the traceability matrix can still be completely green, and the decision underneath all four can still have quietly stopped being defensible, because none of that evidence was ever checking the one thing that actually moved.

Nothing in that situation looks like a failure. There's no defect to investigate, no unauthorised change, no missing test result, no orphaned requirement. The evidence set stays internally consistent while something outside it has moved. The system still does exactly what it was built to do. What's no longer clear is whether the organisation is still entitled to rely on the decision behind it.

I've written before about two adjacent problems: what happens when an implementation partner leaves and nobody can reconstruct why a decision was made, and, in Inspection Debt, what happens when a system keeps changing in small increments faster than its evidence can keep up. This is neither. Assume the decision history is good and the system hasn't moved at all: the requirement is documented, real alternatives were weighed, the configuration was verified against a stated rationale, and nothing about it has changed since it was built. Then one of the things the decision depended on changes anyway, somewhere the validated system was never watching, because that condition was never inside the system's own change surface to begin with.

I explored a version of this mechanism from the AI side in Time to Capability, through what I called the Legacy Precedent Trap: an agent classifies a closed case correctly, by the rules it was given, and still lands on a conclusion Quality no longer accepts, because what counted as acceptable precedent moved on without it. Nothing in the agent had broken. It executed a decision rule that used to be right.

The same failure shows up earlier in the architecture, with no agent anywhere near it.

A green matrix proves the design was implemented

Take a requirement stating that a regulated record can't progress until an independent Quality decision has been made. That describes an outcome. It doesn't tell an architect whether independence should be enforced through a workflow participant rule, an application role, lifecycle security, Dynamic Access Control, some combination of the four, or a narrower technical control backed by procedure. Several designs would satisfy the same requirement equally well. Choosing between them is the actual architecture work, and it depends on context: how decision authority is organised today, which attributes reliably identify the right approver, whether people work across sites, what the platform can enforce directly and what has to be owned procedurally instead.

Once a design is picked, ordinary traceability gets strong fast:

Requirement → design specification → configuration → test → approved result

That chain is good at confirming we implemented and verified the design we approved. Whether the conditions that made this design a reasonable interpretation of the requirement are still true is a separate claim entirely, one the chain was never built to check, and I'd be careful about letting a green answer to the first quietly stand in for the second.

The dependency can live entirely outside the system

Here's a version I keep coming back to. A workflow route depends on a value supplied by another enterprise system, the one everyone currently treats as the authoritative source for a piece of master data. At the time the design was chosen, that's a reasonable call: ownership is clear, the interface is controlled, the definition is stable, and routing a consequential decision off that value is a defensible use of it. The requirement traces. The interface is tested. The workflow behaves.

Two years on, the enterprise data model changes underneath it. A new platform becomes authoritative for part of the organisation. An acquisition brings in records governed through a different hierarchy. Ownership of one attribute quietly moves to another function. The original system keeps supplying a value regardless, and from where the regulated platform sits, nothing looks broken. The interface still runs. The field still populates. The workflow still routes on the rule it was given. Re-run the original test and it passes again, because the test was never checking the thing that actually changed.

The design decision was never really "route on this field." It was closer to routing on this field because the field is a complete and authoritative representation of the boundary the decision needs to enforce. The first version is configuration. The second is the architecture rationale, and it has a condition buried inside it whose truth gets established somewhere the configured application has no visibility into.

It's the kind of gap I built Navata Vault ProofSpan™ to hold open through delivery, checking at design freeze and again at acceptance not just whether a configuration matches what was approved, but whether the conditions attached to that approval are still the ones the organisation is relying on.

A decision is often a conditional claim

Architecture Decision Records exist because mature practice treats a decision as more than a final answer. A good one captures context, the alternatives that were weighed, the trade-offs and the reasoning, and current ADR guidance, including Microsoft's own Well-Architected Framework, increasingly recommends recording what would need to change for the decision to be worth reconsidering, not only what was decided. That's exactly the discipline a decision validity condition needs: spelling out explicitly, for a consequential decision inside a regulated platform, what has to stay true rather than leaving it implicit. A few examples: this system remains the authoritative source for the attribute; this role still represents genuinely independent decision authority; this process is still harmonised the way it was when the control was designed; volume stays inside the range the control was sized for; a manual reconciliation is still actually happening at the frequency someone assumed it would; a supplier limitation that justified a compensating control hasn't quietly been resolved.

Not every assumption earns this treatment, which is exactly where the test from the opening does its work: run it against a candidate condition and most fall out immediately. A vendor's support hours changing rarely sends anyone back to reconsider a design. An acquisition changing who owns the master-data source usually does. The difference is whether the configuration's continued correctness actually depends on the assumption holding, not just whether the assumption happens to be true today.

Why change control never sees it coming

Change control is triggered by a proposed change to the system. A decision validity condition failing doesn't produce one, by definition. Nobody opens a change request when a data-governance team approves a new ownership model, when Quality redistributes decision authority, when an acquisition introduces a second operating model, or when a platform release quietly removes the limitation that justified a compensating control in the first place. Each of those is properly governed somewhere. None of them necessarily opens a change record against the regulated application that was relying on the old version being true.

Periodic review gets closer, where a programme runs one properly, but most periodic review is scoped to ask whether a system still performs as validated: does it still do what the test scripts say. That's a functional question, and the routing example above would sail through it, because the workflow still does exactly what it's configured to do. A decision record that says "revisit if the source-of-truth model changes" is only useful if something actually connects that event back to the decision it's capable of invalidating, and most of the time nothing does. The missing control here is usually not the rationale. It's the trigger path.

A trigger path can take a few different shapes, and which one fits depends on how often the condition is likely to move and how expensive it would be to miss. An event-triggered review ties directly to a specific kind of change, an acquisition, a new authoritative system, a supplier renegotiation. A periodic assertion has a named owner confirm on a schedule that the condition still holds, without waiting for an event to prompt it. A self-checking dependency goes further and has the platform verify the condition automatically where that's technically possible, rather than relying on anyone remembering to look. None of these need to exist for every decision. They need to exist for the ones where a wrong assumption would actually matter.

What the current regulation actually asks for

The Annex 11 that's actually in force is still the January 2011 version. It requires quality risk management across the lifecycle, expects user requirements to trace to a documented risk assessment, requires controlled changes to computerised systems including configuration, and calls for periodic evaluation to confirm systems remain in a validated state. A revised Annex 11 has been in draft since July 2025, expanded considerably and running to seventeen chapters, with the consultation closed since October 2025 and final publication still pending as I'm writing this. The draft pushes further in the same direction, with documented traceability from requirement through design to qualification, and periodic review that more explicitly considers what's changed in the operating context, not only in the system.

Neither version, current or draft, answers the question that matters here on its own. Excellent requirement-to-design-to-test traceability still can't tell you whether something has changed that makes an accepted design worth reconsidering. That stays an architecture question before it becomes a validation one. ICH Q9(R1) comes closer, in spirit if not in these exact words: periodic review sits as its own distinct quality risk management activity in the guideline, separate from change management, and that's the right frame for reassessing a risk-based decision as new knowledge or experience emerges, even where nothing has triggered change control. It's rarely applied down at the level individual Vault configuration decisions actually live at.

Where Control Rationale and Structural Traceability meet

Two ideas I keep separate on purpose. Control Rationale asks why a control exists and what boundary it's actually protecting. Structural Traceability asks whether a consequential decision can be followed through process, data, configuration and evidence without a gap. Neither is a documentation exercise by itself.

For a decision that matters, I want the organisation able to answer four things. What did we decide, stated plainly as the current position. Why was that reasonable, with the alternatives and trade-offs reconstructible rather than assumed. What had to stay true for the reasoning to hold, meaning the validity conditions are actually written down somewhere. And how would we know if one of them stopped being true: an owner, a review point, or an external event capable of pulling the decision back into view.

That fourth one is the piece most often missing, and the gap is usually about ownership: a reconsideration trigger written into a decision record does very little if the event that satisfies it happens in a process nobody has ever connected back to that record.

What configuration stability was always going to miss

A validated system can go on proving yesterday's decision long after the organisation has stopped operating under the assumptions that made it defensible. I'd check whatever periodic review or ongoing verification programme already exists for precisely this gap: whether it tests that configurations still behave as built, or whether any part of it tests that the reasoning behind them is still true. Most of what I've reviewed only does the first. The routing decision that quietly stopped meaning what it was built to mean was never going to be caught by a test designed to confirm it still worked exactly as configured.

The practical version of this is narrower than another documentation exercise: find the decisions in your own environment whose rationale depends materially on a condition outside the system, write that condition down against the decision rather than leaving it implicit, and give it somewhere to go when it changes. That closes a lifecycle gap ordinary requirement-to-test traceability was never going to expose on its own.

Independent, in-flight assurance for decisions like this, held at design freeze, UAT entry and acceptance: Navata Vault ProofSpan™.

For more on naming an owner who can defend a Veeva decision years after it's made: Your Veeva Programme Has a Project Plan. Does It Have an Architecture?

The full series

Where the Evidence Breaks looks at the gap between evidence that stays green and a decision that's quietly stopped being defensible. This piece names the mechanism and asks why ordinary change control and periodic review both miss it. Further parts will look at where else in a regulated programme that same gap opens up.

More from Navata Insights → Explore all insights