The Architecture of an Approval

Built for inspection day.
From day one.^™

A system can show that someone approved something without proving the approval meant very much.

Part 1 traced a workaround: a spreadsheet tracker running alongside a validated system, passing every scheduled check while the actual operating decision had already moved somewhere the validated system couldn’t see. Two architectures were running in parallel, and only one of them had ever been formally accepted. Part 2 stays inside the architecture that was accepted, and asks what each approval in it actually establishes.

Four signatures, one outcome

A validated platform release usually needs several separate approvals before it reaches production: Digital confirms the technical impact assessment, the process owners confirm that user acceptance testing covered their processes, Validation confirms the evidence package, Quality confirms the release is ready to proceed. Each of those approvals exists to establish something specific, and none of them is meant to repeat the others’ work.

That’s deliberate specialisation, not a shortcut: asking every approver to independently reconstruct the whole case would make separate roles pointless. So each approver reasonably assesses their own slice and relies on the rest having been settled by somebody else. The architecture question is what happens when nobody can say exactly what each approval established for itself and what it simply took on trust.

What each approval actually establishes

Every approval in that sequence does two things: it establishes some claims itself, and it inherits others from whichever approval came before it. The process owner approving user acceptance testing establishes that the process performed acceptably under the scenarios actually reviewed, but inherits the separate, untested claim that the right process impacts were identified in the first place. Validation approving the evidence package establishes that the defined test scope was executed with adequate evidence, but inherits the claim that the defined scope represents the material impact of the change. Quality approving release readiness establishes that the available evidence supports release, and inherits both of the claims above, along with everything upstream of them.

None of that inheritance is a flaw on its own. A quality approver shouldn’t repeat the technical impact assessment, and a process owner shouldn’t reproduce the validation review. The flaw appears only when a claim the whole chain depends on was never actually established by anyone, only inferred from the fact that the chain completed.

Consider a pattern I keep seeing in exactly this position. A technical change to an integration doesn’t register as a change to the business requirement it supports, because nothing about the requirement’s wording changed. Four things happen in sequence: the technical change gets correctly recorded, the business requirement gets correctly judged unaffected, the impacted scope gets correctly tested, and the release proceeds on the conclusion that intended use still holds. The first three steps can each be true. The fourth was never independently established by any of them. It was assumed to follow from the first three being individually correct.

I don’t think naming clearer owners fixes this. A RACI can say Digital is responsible for the impact assessment and Quality is accountable for the release decision. It can’t say what proposition each activity actually proves for the person relying on it next. That’s the missing piece, and no amount of clearer ownership supplies it.

Where the claim disappears into the checkboxes

None of this shows up in the system carrying it. The workflow records four approvals, each with a name, a role, a timestamp and a signature. It has no field for what a given approval assumed was already true, and no mechanism for checking whether that assumption was ever independently established rather than inherited from another approval in the same chain.

The regulatory expectations sitting around this protect a narrower thing. EudraLex Annex 11 expects close cooperation between the relevant personnel, naming the process owner, system owner, qualified persons and IT, each with defined responsibilities for their own duties. Part 11 requires an electronic signature to be unique to one individual, to record who signed and when, and to state the meaning attached to it, whether review, approval, responsibility or authorship, linked to the record so it can’t be excised or transferred to falsify it later. These are real, specific controls. Whether every claim that signature depends on was ever independently established by the person responsible for it is a separate question, one the controls were never written to answer.

I look at exactly this layer before a platform release goes near production, whether the claims connecting four separate approvals were ever established by someone, or only inherited from the fact that the chain completed. That’s the review I run with clients at Navata. More on how it works: navata.ai/veeva

The Entitlement Test

The Entitlement Test traces a claim backward from the decision that needs it to the approval that was supposed to establish it, and stops only when it reaches something independently established, or loops back on itself.

OQ and PQ, and the release checklist alongside them, test the workflow that got built: did the impact assessment get documented, did UAT execute against the listed impacts, did the evidence package get compiled and reviewed, did the final signature land before the release moved to production. Every one of those checks is real, and every one of them passes for a release built on an orphaned or circular claim exactly as cleanly as it passes for one where every claim was independently established. The checklist tests whether the steps ran. It was never built to test what each step actually proved to the step after it.

I use a narrower method for that, and it starts from the final decision rather than the first approval. Take the claim behind release readiness itself, the release is acceptable to deploy, and ask what has to already be true for that decision to be made without reproducing somebody else’s work. Write those claims down: the impact assessment is complete, the test scope is adequate, open issues are understood and accepted, operating controls are ready. Then go to whichever approval is supposed to establish each of those claims, and ask the same question of it: what does this approval establish itself, and what does it take on trust from somewhere else. Keep tracing until each claim terminates in something independently established, a document, a test result, a decision somebody can point to, or the trace stops making progress.

Three outcomes are worth naming.

• An orphaned claim is one the final decision depends on that no approval in the chain was ever designed to establish.
• A circular claim is one where two approvals each depend on the other having already settled the same question.
• An overloaded approval is a signature being read, further down the chain, as proof of something broader than what the approver actually reviewed or was responsible for.

I run the test against the record itself, decision logs, impact assessments, evidence packages, defined approval purpose, not against what the people who designed the process say they normally assume. If the answer only exists in someone’s memory of how the process is meant to work, the claim hasn’t been established. It’s been informally agreed.

There’s a second version of the same test worth running against a live process rather than paper. Break one upstream claim on purpose: leave an impact unresolved, introduce an exception, remove the owner from a residual condition. Then watch what happens downstream. Does the chain notice the missing claim and stop, or go conditional, or does every remaining approval complete anyway because each one only checks its own local task. A release architecture that lets the rest of the chain complete around a broken upstream claim has just shown you exactly how much its downstream signatures actually depend on the ones before them.

Nobody owns the chain

ICH Q10 expects senior management to define individual and collective roles, responsibilities and authorities, and to review the quality system’s continuing suitability through management review. That review is real, and it covers real ground, objectives, performance indicators, the state of the quality system as a whole. In my experience, it rarely traces one specific chain of claims from a technical scope through to a final release signature. Each of the four roles owns its own approval. None of them owns the chain connecting all four, because the chain was never assigned to anyone as a thing to own.

That gap runs quietly for as long as the people in each role are careful enough to catch what the workflow doesn’t. It can remain invisible through an inspection too, when review stops at the authorised approval record rather than tracing the claims underneath it. It survives release after release, because the same four roles run the same chain every cycle and a clean release never forces anyone to trace it.

Once you’ve found an orphaned, circular or overloaded claim, there’s a small set of honest responses. Name it and route it to whoever can actually establish it. Document the reliance explicitly, with the evidence stated in the record, so the next reviewer doesn’t have to re-derive it from four people’s confidence in each other. Or reorder the sequence so the fact genuinely gets established before anything downstream leans on it. What most release cycles are actually running is none of these: leaving the claim implicit and trusting the chain because it has held up so far, which is a description of luck, not of architecture.

The question worth asking of your own next release isn’t how many approvals it carries. It’s which claims your final approval depends on that the final approver never established, and where, specifically, each of those claims was actually established. Put a name and a document against every answer before your next release does it for you.

About the author

Rohith Karanam Sreedhar

Founder & Principal

Rohith founded Navata after eighteen years building, validating and operating Veeva and quality systems inside global pharma, including leading Vault QMS architecture at Pfizer. He now helps regulated life-sciences teams find and own the architecture decisions already running inside their platforms.

More from Navata Insights → Explore all insights