The question that stopped the room was not a difficult one. Halfway through a routine inspection, the regulator pointed to a single figure in a phase three submission and asked, reasonably enough, where it had come from. Which instrument had measured it, what had happened to it on the way into the dossier, whose sign-off sat behind each step. Everyone around the table knew the number was right, and knew the system that produced it had done its job. What they could not do, with the inspector waiting, was pull that figure back through every hop and show, on the spot, that someone else could arrive at it the same way. The company had the answer, but producing the proof was another matter entirely.
This is a lineage gap, and it is not only a pharma problem. It is the visible symptom of a long-standing assumption that has finally stopped being true: that speed and evidence are separable, that an organisation can move fast now and assemble the regulatory evidence later when someone asks. That assumption held for a long time, through generations of audit regimes, because someone rarely asked, and when they did, reconstructing the proof by hand was tedious but possible. Both halves of that are now false.
This post works backwards from the symptom, through how evidence used to be produced and what regulators are now asking for, to the architecture that closes the gap and the reason closing it makes an organisation faster rather than slower. Earlier posts in this series argued that sovereignty and load are engineering questions before they are anything else (see Part 1). Evidence is the same kind of question.
The lineage gap
Start with what the inspector was actually asking for. Data lineage, sometimes called data provenance, is the traceable history of a data point: the origin it came from, every transformation applied to it, and the identity and authority behind each step. The pharma company had all of the underlying events somewhere. The instrument wrote to a log. The transformation ran in a pipeline that emitted its own log. The approval sat in a workflow tool. What it did not have was those events linked to each other, fixed against later alteration, and addressable by the one thing the inspector cared about, the data point itself.
That is the anatomy of the gap. The system was built to produce outputs, and it recorded its outputs well. It was not built to record the provenance of those outputs as a connected, verifiable object. Reconstruction was therefore a human task: an analyst stitching timestamps across three systems, inferring the links, and producing a narrative that was plausible rather than proven. Plausible is no longer the bar.
The same gap appears wherever a consequential decision has to be defended after the fact. A bank asked to show why a specific credit decision was made can usually show the decision but not the full lineage of the inputs that drove it. A government department asked who accessed a citizen record, under what authority, and whether that authority was still valid at the moment of access, often finds the access logged but the authority unlinked. In every case the events exist and the connective tissue does not. The gap is not a missing log. It is a missing architecture for turning logs into evidence.
What evidence used to look like
Work backwards, and the reason the gap exists is historical. For most of the compliance era, evidence meant artefacts assembled for a point in time. A team knew an audit or an inspection was coming, and it spent the weeks before assembling the binder: printed logs, screenshots of configuration, signed PDFs, a spreadsheet of controls mapped to a framework, a sample of records pulled and annotated. The evidence was manufactured for the occasion and then set aside until the next one.
This worked for two reasons, and both have expired. The first was cadence. Audits were periodic, so producing evidence a few times a year was survivable, even if each round consumed a quarter of somebody’s life. The second was the cost of verification. Checking that the binder matched reality was expensive and slow, so verifiers sampled lightly and trusted the description. The controlling assumption underneath both was that the document was the artefact and reality was something you checked rarely.
Regulated industries did build genuine data-integrity discipline in this period. The FDA’s electronic-records rules established that records had to be attributable, legible, contemporaneous, original, and accurate, backed by secure, computer-generated, time-stamped audit trails (U.S. Food and Drug Administration, n.d.). That was real and it mattered. But it was still framed around records as things you keep and produce, not around evidence as a property the running system emits continuously. The binder got thicker and better governed. It remained a binder.
What regulators are actually asking for now
The bar has moved, and it has moved in the same direction across every regulated sector at once: from “can you describe your controls” to “can you produce verifiable evidence, for this specific item, on demand.” In clinical research, the revised good clinical practice guideline reached final adoption in January 2025, went live across the major regulators in mid-2025, and gains its second annex during 2026. It expands the old integrity principles to ALCOA++, adding complete, consistent, enduring, and available, and reframes data governance as a lifecycle property rather than a filing obligation (ICH, 2025). The expectation is no longer a well-kept archive. It is the ability to trace a data point through its whole life at inspection speed.
The audit profession is rewriting its own foundations around the same shift, and the pace has picked up through 2026. Having issued a catalog of the specific issues that automated tools and machine-generated evidence create for its standards (IAASB, 2025), the international standard-setter is now redrafting the core audit-evidence standard itself: the first full draft of the revised ISA 500 was considered in March 2026 and is moving into public consultation, explicitly to clarify how evidence obtained through automated tools should be treated (IAASB, 2026). In parallel, the internal-control guidance issued in February 2026 for organisations running generative systems in financially material processes is blunt that set-and-forget assurance is inadequate for probabilistic models, and that any output affecting a material figure must be supported by appropriate, traceable evidence (COSO, 2026).
Regulation of AI systems codifies the same expectation directly. The EU AI Act requires high-risk systems to keep automatic logs over their lifetime, obliges deployers to retain those logs for at least six months, and sustains post-market monitoring, which is to say it requires evidence to be a running output of the system rather than a retrospective reconstruction (European Parliament and Council, 2024, Articles 12, 26 and 72). The 2026 Digital Omnibus package rescheduled when the high-risk obligations begin to bite, but not their shape: the logging and monitoring duties are intact, and the direction is settled (European Commission, 2026). Read together, these are not separate compliance projects. They are one signal. The reconstructable, machine-verifiable chain is now the deliverable, and the binder is a record of a world that no longer sets the terms.
The architecture of audit-readiness
Move forward from the diagnosis and the resolution is an audit-ready architecture, not a procedural fix. This compliance architecture becomes achievable when evidence is engineered into two layers of the system rather than assembled on top of it.
The first is the data layer. Lineage has to be captured at write time as first-class metadata, not reconstructed at audit time from scattered logs. Every dataset and every transformation records, as it runs, the inputs it consumed, the version of the code that touched them, the identity that authorised the step, and the time it happened, all linked by shared identifiers. When that is in place, the inspector’s question stops being an archaeology project and becomes a query: give me the lineage of this data point, and the system returns it. Building the data layer so that provenance travels with the data, rather than being inferred afterwards, is the core of the work Sakura’s Data & AI practice does under a regulated architecture.
The second is the execution layer. Every consequential action, a tool call, a policy decision, an access to a protected record, emits an immutable, tamper-evident record as an ordinary byproduct of running. Hash-linking those records means any later alteration is detectable, which is the difference between a log you keep and evidence someone else can trust. Policy decisions are themselves recorded as decision objects: what was requested, what rule applied, what was permitted or denied, and why. An evidence pipeline then makes all of it addressable, so a request for a given control, data point, or period resolves against a real chain rather than a narrative. The defining property is simple to state and demanding to build: evidence is produced as a side effect of operating the system, whether or not anyone ever asks for it. That property, engineered once, is what turns audit readiness from a recurring scramble into a standing capability. It is engineered compliance in the literal sense, and it is the outcome Sakura’s GRC service is organised around.
The speed dividend
The counterintuitive part is that this makes regulated organisations faster, not slower. When evidence is emitted continuously, the audit cycle stops being a project and becomes a machine-speed audit: a query against a live chain rather than a quarter of reconstruction. There is no change freeze while the binder is assembled, no team pulled off delivery to reconstruct history, and regulated workloads carry their own proof as they run. The proof travels with the work, so a release does not have to pause to prove itself.
The organisations that bolt evidence on afterwards pay for it twice. They pay once in the reconstruction, the analyst-weeks spent stitching logs into a defensible story. They pay again in the drag on everything else while that reconstruction is under way, because a system whose evidence cannot be produced on demand cannot safely change quickly. Every deployment carries the unpriced risk that it breaks a chain nobody can currently see. Evidence-first operations remove that risk by making the chain explicit and continuous, which is precisely what lets a regulated business move at close to the speed of an unregulated one without surrendering its right to operate.
This is the resolution of the tension the post opened with. Evidence and speed look opposed only while evidence is a thing you produce on request. Engineer it into the data and execution layers and the opposition dissolves, because the same architecture that makes the system fast to change is the one that makes it ready to prove. The pharma company at the start did not have a speed problem or an evidence problem. It had an architecture that treated the two as separate, and paid for both.
The organisations turning a regulator’s request into a query rather than a quarter are the ones engineering evidence into the layer beneath the strategy, and building that capability as a running property of the platform is what Sakura’s Praxis compliance solution exists to do.
References
COSO, 2026. Achieving Effective Internal Control Over Generative AI. Committee of Sponsoring Organizations of the Treadway Commission. Available at: https://www.coso.org/ [Accessed 7 July 2026].
European Commission, 2026. Timeline for the implementation of the EU AI Act. AI Act Service Desk, European Commission. Available at: https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act [Accessed 7 July 2026].
European Parliament and Council, 2024. Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, L 2024/1689, 12 July. Available at: https://eur-lex.europa.eu/eli/reg/2024/1689/oj [Accessed 7 July 2026].
ICH, 2025. ICH E6(R3) Guideline for Good Clinical Practice, Step 4. International Council for Harmonisation of Technical Requirements for Pharmaceuticals for Human Use. Available at: https://www.ich.org/page/efficacy-guidelines [Accessed 7 July 2026].
International Auditing and Assurance Standards Board (IAASB), 2025. Technology Position: Catalog of Issues and Possible Actions. International Federation of Accountants. Available at: https://ifacweb.blob.core.windows.net/publicfiles/2025-11/IAASB-Technology-Catalog-of-Issues-Proposed-Actions.pdf [Accessed 7 July 2026].
International Auditing and Assurance Standards Board (IAASB), 2026. Proposed International Standard on Auditing 500 (Revised), Audit Evidence. International Federation of Accountants. Available at: https://www.iaasb.org/consultations-projects/isa-500-series [Accessed 7 July 2026].
U.S. Food and Drug Administration, n.d. 21 CFR Part 11: Electronic Records; Electronic Signatures. Code of Federal Regulations, Title 21, Chapter I, Subchapter A, Part 11. Available at: https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11 [Accessed 7 July 2026].