Context Graphs for Regulatory Decision Traceability: Why Pharma Needs This Now

The Shape of the Problem: What a Regulator Actually Asks

Sit through an FDA or EMA inspection where AI has touched a regulatory workflow and the questions cluster around a small number of themes. Which model produced this output? Which version of the model? What data did it see? Was any of that data restricted or out of context of use? Which reviewer touched it, when, and what did they change? If a hallucination or a bias led to a patient safety event, could you retrace the chain?

Those questions are not new. They are the same questions inspectors have asked about spreadsheets, LIMS, and manual calculations for thirty years. What is new is the volume and the opacity of the underlying decisions. A generative model producing a first draft of a clinical study report can consult dozens of source documents, apply a chain of prompt steps, and produce output where the reasoning is not stored anywhere by default. The McKinsey-Merck collaboration on AI-assisted clinical study report authoring cut first-draft time from 180 hours to 80 hours and reduced errors by roughly 50 percent.⁵ Efficiency gains at that scale mean the volume of AI-touched regulatory content is climbing quickly, and every unit of that content will eventually need to defend itself.

The default technical answer today is to log everything. Store the prompts, the responses, the model version, the user, the timestamps. In practice that means dumping structured events into a Splunk-style log system, or storing rows in a Part 11 audit-trail table, and reviewing them episodically. It works, up to a point. It falls apart when the question shifts from “did anything change in record X between date A and date B” to “walk me through the reasoning behind labeling decision Y, including which prior label discussions, which safety signals, and which internal debates fed into it, and prove that the reviewer saw the disconfirming evidence.” That last question is what the context graph thesis is designed to answer, and it is the shape of the question that pharma regulatory reviewers are increasingly going to ask.

Context Graphs Explained: From VC Thesis to Pharma Application

Foundation Capital’s Ashu Garg and Jaya Gupta argued in December 2025 that context graphs are the missing memory layer for enterprise AI. Their frame: enterprise software has captured forty years of what happened but almost none of the reasoning that produced those outcomes. A context graph is a living, queryable record of decision traces, stitched across entities and time, that makes institutional reasoning searchable in the same way that ERP made transactions searchable.¹

The technical anatomy has three parts. First, entities: people, documents, models, systems, decisions, products. Second, relationships: who reviewed what, which input informed which output, which model version produced which draft. Third, decision traces: the ordered sequence of steps that led from a triggering event to a resolved action, with the context that was in scope at each step.⁶ Where a knowledge graph tells you what is true about the enterprise, a context graph tells you why the enterprise decided what it decided, with citations attached.⁷

Since the December 2025 paper, other analysts have refined the picture. Elixir Data describes context graphs as “decision-grade infrastructure” that provides reliable context with freshness, provenance, and confidence scoring, plus a traceable reasoning layer with an immutable record of inputs and decisions.⁸ Neo4j’s engineering team has framed knowledge graphs as “the accountability layer for high-stakes AI,” a subtly different formulation of the same idea.⁹ Linked Data Orchestration has argued that context graphs need a formal knowledge-architecture backbone to prevent the decision-trace layer from becoming another silo.¹⁰ Read together, the field is converging on a consensus that a real context graph combines four things: a domain ontology, an entity graph, a decision-trace layer, and a provenance model that says where every piece of context came from and when.

Two things are worth naming about the term itself. The concept of a graph-based knowledge structure is not new. Enterprise architecture has maintained entity graphs for four decades and pharma has invested in knowledge graphs for drug discovery for at least a decade, most visibly at AstraZeneca whose Biological Insights Knowledge Graph connects nearly 11 million nodes and 118 million edges, and at Merck through its Synaptix platform.¹¹ What is genuinely new in the Foundation Capital framing is the emphasis on decision traces as first-class objects. It is one thing to model drug-target relationships. It is another to model the reasoning your regulatory team applied when it drafted a specific label amendment, and to make that reasoning queryable years later when a competitor challenges the label or a post-market safety signal arrives.

Traditional Audit Logging Versus Context Graphs

Pharma has spent decades building audit trails. 21 CFR Part 11 and EU Annex 11 codified the ALCOA and later ALCOA+ principles: data should be Attributable, Legible, Contemporaneous, Original, Accurate, Complete, Consistent, Enduring, and Available.¹² Almost every regulated system in the industry has an audit-trail table that records who did what and when, and quality teams review those trails on a risk-based cadence. The question is whether those structures are still fit for purpose when the “who” is a stochastic model and the “what” is a chain of reasoning across dozens of documents.

Traditional audit logs and context graphs are not opposites; they answer different questions. An audit log is optimized for event-level accountability: proving that a specific record was created, modified, or deleted by a specific actor at a specific time. A context graph is optimized for decision-level accountability: reconstructing the reasoning that led from a set of inputs, through a sequence of intermediate states, to a final output. The former is a table. The latter is a directed graph. Most regulatory questions about AI-assisted decisions are decision-level questions being answered with event-level infrastructure, which is why the answers tend to be laborious and incomplete.

The point is not that audit logs are obsolete. Part 11 audit trails will remain the record of who touched a specific database row, and they need to keep meeting ALCOA+ standards. The point is that a context graph sits above those logs and turns them into a coherent narrative that a regulator can consume. In practice, the context graph reads events from underlying audit trails, workflow systems, and model telemetry, and stitches them into decision traces that are the actual unit of inspection interest.

The Regulatory Drivers Forcing This Conversation

The context graph conversation would be an interesting architectural debate in pharma even without regulatory pressure. What makes it a governance-committee agenda item is that four separate regulatory currents are converging on the same expectation, each with a different framing but the same substantive requirement: a queryable, permanent record of AI-assisted decisions with inputs, reasoning, and human oversight visible on demand.

EMA Annex 22 (Draft, July 2025; Final Expected End of 2026)

EMA’s draft Annex 22 introduces a dedicated GxP framework for AI and machine learning systems used in the manufacture of active substances and medicinal products. Among its core requirements: training and test data must meet GxP standards for accuracy, integrity, and traceability; validation must use independent test data with documented acceptance criteria; qualified human review is required for decisions in critical process steps; and AI model updates must follow formal change control including versioning and impact assessment.³ Continuously learning models and generative AI are restricted to non-critical applications with documented human oversight.¹³ Every one of those requirements produces artifacts that a context graph is well suited to store as first-class nodes.

EU AI Act Article 12 (Enforceable August 2026)

Article 12 mandates that high-risk AI systems technically allow for automatic recording of events over the lifetime of the system, with logs retained at least six months (24 months for biometric or law enforcement contexts). The logs must enable identification of risks, support post-market monitoring, and record system operation. Logs must be tamper-evident. Automatic means the system generates logs on its own; manual documentation does not satisfy the requirement.² A recent Help Net Security analysis of AI agent logging concluded that Article 12 pushes organizations toward architectures where the log is the source of truth for what an agent did, why, and with what oversight.¹⁴ Non-compliance penalties reach 15 million euros or 3 percent of worldwide turnover, whichever is higher.

FDA-EMA Joint AI Principles (January 14, 2026)

The ten principles jointly published by FDA and EMA in January 2026 emphasize a human-centric, risk-based approach to AI adoption, with proportional validation, clear definition of context of use, adherence to applicable standards, multidisciplinary expertise, transparent model development practices, lifecycle performance monitoring, and clear communication of AI limitations and outputs to users and patients.⁴ RAPS’ coverage of the release noted that although the ten principles are not binding guidance, they lay the foundation for future AI-specific regulatory guidance in both the U.S. and EU and signal a shared expectation of traceable, context-aware validation.¹⁵

FDA Good Machine Learning Practice (GMLP) and 21 CFR Part 11

The 2021 joint FDA, Health Canada, and MHRA guiding principles for GMLP, updated through 2025-2026, call for traceability of training datasets and algorithm changes, treating algorithm development activities with the same rigor as medical device design, including audit trails for data, code changes, and traceability matrices.¹⁶ Where 21 CFR Part 11 applies, every submitted prompt, generated response, and cited source document should be logged, time-stamped, and associated with an identified user.¹⁷ IntuitionLabs’ recent analysis of ALCOA+ applied to AI concludes that the framework fits, but only if the audit-trail layer captures model inputs, model version, and human review as first-class fields, not free-text comments.¹⁸

Three Regulatory Use Cases Where Context Graphs Change the Math

The abstract argument for context graphs is easier to see through three regulatory workflows where AI is now widely deployed and where the audit-log-only approach breaks first.

Use Case 1: Regulatory Submissions

An AI copilot drafts sections of a Common Technical Document or an NDA/BLA response to an information request. It pulls from prior submissions, published literature, internal clinical study reports, and safety databases. A medical writer reviews and edits. A regulatory affairs lead approves. Six months later, FDA sends a follow-up question that touches the same claim.

With traditional logging, reconstructing the reasoning requires opening the writer’s email, the document management system, the model logs, and the review comments, and hoping the intermediate drafts were preserved. With a context graph, the decision node for that submission section links to every source document the model consulted, every prompt used, every draft version, every review comment, every source the model considered and rejected, and the final approved text. The follow-up FDA question is answered by a graph query, not by an archaeology project. The IntuitionLabs analysis of AI in regulatory affairs describes this shift as moving from “AI-assisted drafting with manual audit reconstruction” to “AI-assisted drafting with automatic decision provenance.”¹⁹

Use Case 2: Labeling Decisions

Labeling is where regulatory, medical, safety, and legal decisions collide, and where AI assistance is expanding rapidly. Every label change is the outcome of a chain of judgment calls: which safety signals warrant an update, which studies to cite, which wording thread to prefer, which precedents from analogous products to apply. A recent published analysis of pharma-regulator synchrony on safety labeling updates argues that the underlying friction is not the wording but the traceability of the reasoning trail across the two sides.²⁰

A context graph makes that trail auditable in both directions. Internally, the label change decision node links to the pharmacovigilance signals that triggered the review, the AI-generated draft language, the human edits, the review committee decisions, and the final regulator-approved wording. Externally, the same graph structure produces the artifacts that a regulator would ask for during an inspection or a post-market safety review. It also makes it possible to detect drift, that is, when subsequent label changes are inconsistent with the precedent set by earlier decisions, which is exactly the kind of question a knowledge graph structure is designed to answer.²¹

Use Case 3: Pharmacovigilance Case Processing and Signal Detection

Pharmacovigilance is arguably the pharma workflow furthest along in AI adoption. Agentic AI systems now handle up to 40 percent of PV workflow capacity, including duplicate case detection, triage prioritization, and causality assessment suggestions.²² The regulatory expectation, articulated in the joint FDA-EMA principles and detailed in industry analysis, is that every automated conclusion has a traceable line from input case data through model reasoning to human review to the final case assessment.²³

A context graph structure is a natural fit. Each case becomes a decision graph: the source E2B or ICSR document, the model’s extraction and coding decisions with confidence scores, the duplicate-detection reasoning with the specific matched cases, the causality assessment logic, the medical reviewer’s edits, and the final signed case. Signal detection at the aggregate level then queries across those decision graphs, and the answer to the inspector’s question “walk me through how you decided this signal was real” becomes a graph traversal, not an interview series.

A Context Graph Data Model for Regulatory Decisions

The data model below is intentionally minimal. Real implementations will elaborate node and edge types considerably; the goal here is to name the primitives that any pharma context graph for regulatory decisions needs.

Node Types

• Decision. The unit of inspection interest. Attributes: decision type (submission section, label change, PV case, batch release), status, owner, created and closed timestamps, regulatory context (product, indication, jurisdiction).
• Source. Any document, dataset, or system that fed a decision. Attributes: type (CSR, IB, ICSR, literature, prior label, guidance), version, retrieval timestamp, checksum.
• Model Invocation. A specific call to a specific AI model. Attributes: model identifier and version, prompt text, response text, confidence, token counts, temperature, timestamp, upstream retrieval calls.
• Human Review. A discrete human touchpoint. Attributes: reviewer identity and role, review time, what was shown, what was changed, comments, sign-off status, digital signature reference.
• Artifact. A concrete output. Attributes: type (submission section text, label wording, PV case assessment, batch disposition), version, storage location, checksum.
• Rejected Source. A source that was considered and not used. This is the disconfirming-evidence node that traditional audit trails typically omit.

Edge Types

• informed_by. Decision to Source, with retrieval-time context. Multiple edges per decision.
• invoked. Decision to Model Invocation. Ordered when a chain of prompts was used.
• reviewed_by. Decision or Artifact to Human Review. Ordered by review sequence.
• produced. Decision to Artifact. The final outputs of the decision.
• considered_rejected. Decision to Rejected Source. Named explicitly to force capture.
• supersedes. Decision to prior Decision. Used for label amendments, submission updates, and case reassessments.
• triggered_by. Decision to prior event (safety signal, regulator request, scheduled review).

Provenance and Governance Attributes

Every node and edge should carry a small set of governance attributes: source system, ALCOA+ compliance flag, retention class (aligned to Part 11, Annex 22, and Article 12 categories), access control tags, and a tamper-evident checksum or hash. The graph itself should be append-only with cryptographic versioning; edits produce a new version node that supersedes rather than overwriting the prior state. This is what makes it audit-defensible in the same way an ALCOA+ audit trail is defensible.

Integration Architecture: Where a Context Graph Sits in the Pharma Stack

The context graph is not a replacement for the systems that already run pharma; it is a layer that sits above them and reads from them. The architecture pattern below reflects what the emerging enterprise-AI-infrastructure literature converges on and what pragmatically fits the pharma stack.

Ingestion Layer

The context graph reads from operational systems rather than replacing them. Document management systems (Veeva Vault, Documentum), regulatory information management systems, LIMS, ELN, MES, safety databases (Argus, ArisGlobal LifeSphere), and any AI model gateway need to emit structured events into the graph. This is where existing Part 11 audit trails become inputs, not competitors. Neo4j and similar graph platforms provide the substrate; the integration work is what makes the graph fit for pharma inspection.²⁴

Graph Layer

The graph itself. In pharma the choice will typically be between a purpose-built regulatory graph platform (a small but growing category) and a general-purpose graph database (Neo4j, TigerGraph, Amazon Neptune) with pharma-specific ontologies overlaid. The important architectural constraint is that the graph must be tamper-evident and versioned, and it must support access controls at node and edge level so that data segmentation across products, jurisdictions, and roles is enforced technically rather than only by convention.

Reasoning and Retrieval Layer

AI applications query the graph before acting and write back to it after acting. This is the hook that makes the graph a decision-provenance system rather than a passive log. A regulatory drafting copilot retrieves relevant precedent decisions before producing a draft, and writes the model invocation, sources consulted, and outputs back into the graph. The same pattern applies to PV agents, labeling copilots, and quality event triage systems.

Inspection and Reporting Layer

The interface that regulators, auditors, quality, and regulatory affairs use to interrogate the graph. Views include decision timeline visualizations, source-to-output traceability, human review reconstruction, model version impact analysis, and cross-product precedent search. This is the layer that turns the graph into inspection-ready evidence rather than raw data.

Governance Layer

Access controls, retention policies, model registry integration, change control integration, and periodic review workflows. This is where the graph earns its ALCOA+ credentials and where the organization’s operating rhythms (change control boards, quality event review, model performance monitoring) touch the graph substrate.

A Maturity Model for Pharma Adoption

Very few pharma organizations are at maturity Stage 4 or 5 today. Most are at Stage 1 or 2, and the calendar between now and end of 2026 is going to compress the middle stages. The model below is intentionally coarse; it is meant to give a governance committee a shared language for where they are and where the next investment should go.

What to Do in the Next Ninety Days

Assuming a mid-cap pharma organization currently at Stage 1 or 2, with generative AI already in use for at least one regulatory workflow, a defensible ninety-day plan looks like this.

Days 1-30: Inventory and Diagnose

Catalog every AI-assisted regulatory workflow in use today. For each, identify: which model is used, what data it consumes, what artifacts it produces, which human reviews are in scope, and how long it would take to reconstruct a specific decision on inspector demand. This is not a technical exercise; it is a quality and regulatory exercise supported by IT. The output is a heat map of workflows by regulatory exposure and traceability gap.

Days 31-60: Pick One Workflow and Design the Graph

Select the workflow with the highest regulatory exposure and the largest traceability gap (typically submissions or PV). Design the node and edge types specific to that workflow, using the primitives in the data model section as a starting point. Do this with regulatory affairs, quality, and IT in the same room. Do not select a graph platform yet; the ontology decisions matter more than the platform decisions.

Days 61-90: Build the Pilot

Stand up a graph store (Neo4j, TigerGraph, or Neptune are all defensible starting points for a pilot) and instrument the pilot workflow to write into it. Instrument backwards from inspection questions: pick five real inspection questions your team has fielded in the last two years and prove the graph answers them by query in under an hour. If it does, you have a Stage 3 workflow. If it does not, iterate on the node types before expanding.

Conclusion

Context graphs are, at their most abstract, a bet that enterprise AI needs a new memory layer optimized for decision traces rather than transactions. In most industries that bet is a productivity argument. In pharma it is first a compliance argument, because the calendar of regulatory expectations between August 2026 and end of 2026 is going to require every AI-assisted decision touching a submission, a label, a case, or a batch to be reconstructable on demand. The current default architecture (per-system audit trails plus centralized model logs) will not satisfy that expectation. It was not built to.

The right way to read the Foundation Capital thesis is not as a call to buy a new platform, but as a naming exercise: it gives the pharma industry a vocabulary for a shift that regulatory currents have already made necessary. Whether an organization ends up on a purpose-built regulatory graph platform, an enterprise knowledge graph extended for decision traces, or a bespoke architecture built on Neo4j or similar, the underlying pattern is the same. Decisions become first-class objects. Reasoning becomes queryable. Human review becomes structured data. And the answer to an inspector’s next hard AI question stops being an archaeology project.

Sakara Digital works with pharma and biotech organizations building the data quality, governance, and traceability foundations that AI-assisted regulatory workflows require. If you are evaluating whether a context graph pattern fits your submissions, labeling, or pharmacovigilance workflows, and you want an independent perspective on where the highest-value starting point is for your specific regulatory portfolio, we are happy to have that conversation.