The Architecture of a Workaround

Built for inspection day.
From day one.^™

I don't worry about the part of a Quality process that fails a test. I worry about the part that keeps passing one while the actual decision has already moved somewhere else.

I’ve come to think that gap matters more than whatever is sitting inside it. A workaround is usually what’s sitting inside it. It rarely arrives as a decision. A gap gets filled because it solves today’s problem, and it keeps getting filled the same way until a regulated decision is leaning on it, without anyone ever choosing that. I test for the point that happens with one question. Would the process still reach the same decision, from the same evidence, under the same authority, if the workaround disappeared tomorrow? If not, the architecture has already moved, whether or not the validated system in front of me still looks correct.

This is the first in a series about what I’d call invisible architecture: decisions that look purely operational but are actually architectural choices nobody recognised, documented or owned as one. A workaround is the plainest example, and a tracker is where it’s easiest to see.

What I’d expect to find

Take a familiar Quality process. Quality intended a specific control: cases stay visible, owned and escalated at the right point. That intent got configured into an object, a report and a permission model: who can see a case, who’s marked as its owner, which report the escalation meeting runs from. Validation then demonstrated that the configured behaviour matched what was specified.

Three decisions, stacked on top of each other, each one assuming the layer beneath it still holds.

I look for exactly this stack in Navata’s Veeva architecture work: not just whether each layer performs as validated on its own, but whether the stack as a whole is still what people are actually running the process against.

The tracker that grows up beside it

There’s a spreadsheet next to the validated system in most Quality functions I’ve worked with. Nobody hides it. It usually carries a name no more formal than “the tracker.”

The report it sits beside usually wasn’t built wrong. Case prioritisation looked different at go-live. A site that barely generated volume back then now drives half the queue. What counted as urgent was something everyone in the room could agree on by feel at the time, and the report was configured to match that world, not the one the team is actually running the process in now. Nobody changed the report. The operating context around it moved instead.

Before the weekly quality review, someone updates the tracker with whatever the report can no longer capture on its own. That’s a reasonable enough excuse to start one.

Then it starts accumulating meaning of its own.

• It holds a working owner that doesn’t exist in the system.
• It carries a priority arrived at through the coordinator’s own judgement.
• It contains context copied from a mailbox thread.

Look at what’s actually running the process now, and there’s a second stack, not one. The tracker has become the operating state: it determines which case actually gets attention this week. The coordinator’s judgement has become the effective decision authority: it sets the priority nobody configured anywhere. The Monday write-back has become the reconciliation control: it’s how an outcome reached outside the recognised path eventually gets reflected in the record everyone else can see. I think of this as the second stack. It carries state, authority and reconciliation alongside the architecture that was formally accepted.

It’s built from the same three layers as the one that was accepted, and nobody built it on purpose.

By the time a new starter gets shown the tracker on day one, right alongside the system, I’ve never seen anyone draw a distinction between the two.

Where the gap becomes visible

I’ve watched this stay invisible for a long time whenever the two stacks happen to agree. It surfaces the day they don’t: the tracker says one owner, the system says another, and nothing in either record explains which one is right.

It also surfaces the day the coordinator is out. Nobody else knows that a blank cell means “waiting on the site” rather than “not yet reviewed,” because that meaning was never written down anywhere the coordinator’s absence could be covered against. Whatever is sitting in someone’s memory like that is already part of the architecture, whether or not it was ever meant to be.

This is the divergence I opened with, made concrete: two stacks, and only one of them was ever accepted. Testing demonstrates that a system does what it was defined to do, and a validated system can pass on exactly that basis, whatever else has happened around it in practice. The operating path is a separate question, and the tracker is where that question actually lives. An inspector’s audit trail records who changed a case and when, accurately, completely, exactly as the system was built to record it. The tracker entry and the mailbox thread that actually produced that change sit outside it entirely, because neither one was ever in scope to be captured there.

The record can be accurate about the transaction and still be incomplete as evidence of the decision that produced it, and nothing in the record itself will tell you which one you’re looking at.

I’d be careful not to overstate what the regulations actually require here. The current Annex 11 text, from 2011, expects manually entered critical data to carry an additional accuracy check, with the consequences of getting it wrong addressed through risk management. A wider revision, expanded to seventeen chapters, was published for consultation on 7 July 2025 and closed for comment on 7 October 2025, but, as of this writing, hasn’t replaced that text yet. MHRA’s data integrity guidance sets the same expectation of complete, consistent and accurate records whether the record is paper or electronic. Neither reads to me as a regulator prescribing what to do about a tracker specifically, so much as setting the standard a workaround has to meet once it’s carrying part of a regulated decision, whether or not anyone has decided to hold it to that standard.

The Workaround Dependency Test

The instinct is to tell people to stop using the tracker. That rarely holds, because the report it replaced still doesn’t serve the job, and the work still has to move.

What I actually run is four questions, then one test.

• Decision: does it determine or materially influence a regulated decision or controlled state.
• Evidence: does it hold reasoning that can’t be reconstructed from the recognised record.
• Authority: does it change who effectively decides, prioritises or directs the work.
• Reconciliation: does someone have to reconcile it before the official record can be relied on.

A yes to any of those four means I can no longer treat the tracker as an isolated operational convenience. It’s carrying part of the load the architecture is supposed to carry, and I want that decided on purpose rather than left to accumulate.

The test is the one I opened with, run properly rather than just asked: remove the tracker, and see which of the four actually changes. I do this in stages when I can, because a single pass makes it too easy to pass. First, with the tracker and the coordinator both reachable, as a sanity check and nothing more. Then with the coordinator unavailable but the tracker still there, to see whether a second trained person reads the same meaning into it that the coordinator does. Then with the tracker itself gone, using only the recognised system and its report, to see whether decision, evidence, authority and reconciliation all still hold without either of them.

A test that still lets someone check with the coordinator over their shoulder hasn’t tested anything. The point is whether the decision survives without them in the room.

Once I have honest answers, there are three outcomes I’d defend, not one or two. Fix the report well enough that the tracker stops earning its keep. Bring the tracker inside the controlled process permanently: a named owner, a rule for what wins when it disagrees with the system, a plan for retaining the reasoning it’s currently the only place holding. Or bound it deliberately, as a genuinely temporary bridge: the same ownership and precedence rules, plus an exit condition that isn’t just “eventually”: a fix date, a trigger, something that actually closes it out. ICH Q9(R1), adopted January 2023, backs the underlying logic for all three: risk management is meant to stay a live part of the process, reviewed as new knowledge and experience come in, not treated as a decision made once and left alone.

What’s not on that list, and what I won’t leave unnamed, is the option most programmes are quietly running instead: keeping the tracker exactly where it is, with none of the above in place, while continuing to call it temporary indefinitely.

The decision nobody owned

It’s tempting to treat this as a coordinator’s problem, fixable with a stricter procedure or a stronger reminder. I’d point somewhere else: once a report leaves Digital’s hands, nobody owns the space where the world keeps changing underneath it, and the tracker is simply what fills that space when nobody’s claimed it.

The practical version of this is narrower than it sounds. Find where a tracker, a mailbox or someone’s memory has quietly started carrying decision, evidence or authority the recognised design doesn’t show. Name who owns that specific gap, not the process in general. Then run the dependency test on it before an inspector does.

The question I’d take to a governance forum isn’t whether the tracker should exist. It’s whether the architecture I’d be accepting is the one actually carrying the decision, or just the one that was designed, and whose job it was to notice the difference before I had to ask.

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