Saram ConsultingA quality manager asks the system: “What CAPAs were opened from deviations related to Equipment ID-442 in the last two years, and were they effective?”
The system needs to traverse: a deviation report, which links to an equipment qualification, which links to a cleaning validation protocol, which links to an SOP, which was superseded by a newer version after a regulatory finding, which generated a CAPA, which triggered a change control, which updated a risk assessment.
No vector database can do that. No embedding similarity search can follow that chain. That is a graph traversal — and it requires a knowledge representation that most life sciences organizations don’t have.
On June 12, 2026, Google Cloud published the Open Knowledge Format (OKF) v0.1, a specification designed to solve exactly this kind of problem. It was built for data engineering teams drowning in fragmented metadata. But after analyzing the spec, the industry landscape, and the specific architecture of quality management systems, the conclusion is clear: life sciences quality documents are a stronger fit for OKF than the use case it was designed for — provided you adapt the format for the regulatory realities that make this industry different.
What OKF actually is
OKF is deliberately simple. A knowledge bundle is a directory of markdown files. Each file represents one concept — a table, an API, a metric, a playbook. The file path is the concept’s identity. YAML frontmatter at the top provides structured metadata. The body is markdown. Cross-links between files turn the directory into a graph.
---
type: SOP
title: Equipment Cleaning - Grade C/D Areas
description: Cleaning procedures for aseptic manufacturing equipment.
resource: https://veeva-vault.com/doc/00P123456
tags: [cleaning, aseptic, manufacturing]
timestamp: 2026-05-28T14:30:00Z
---
# Procedure
Standard cleaning procedure for equipment in Grade C and D
areas following [SOP-00123](/sops/SOP-00123-equipment-cleaning.md).
# Related Documents
- [Work Instruction WI-088](/work-instructions/WI-088.md)
- [Validation Protocol VP-234](/validation/VP-234.md)
- [21 CFR 211.67](/regulations/21-cfr-211.67.md)The spec requires exactly one field: type. Everything else is optional. The format is “just files” — shippable as a git repo, readable in any text editor, parseable by any agent without an SDK. If you can cat a file, you can read OKF. If you can git clone a repo, you can ship it.
The reference implementation ships an enrichment agent that walks a BigQuery dataset and drafts concept documents for every table and view, plus a static HTML visualizer that renders the graph. Google Cloud’s Knowledge Catalog can now ingest OKF bundles natively.
Why life sciences is the better use case
Google built OKF for data teams. The canonical example is BigQuery tables with join paths and metric definitions. That’s a real problem, but it’s a narrow one.
Life sciences quality documents are everything OKF was designed to handle — and more:
The fragmentation is worse. A data team’s metadata lives in a few systems. Quality knowledge lives in an eQMS (Veeva Vault, MasterControl, TrackWise), a LIMS, an ELN, a validation repository, a regulatory intelligence database, shared drives, and the heads of experienced QA professionals who’ve been doing this for 20 years. An agent trying to answer “what’s the current approved method for cleaning the reactor vessel after a batch of Product X?” has to assemble context from five or more systems that don’t talk to each other.
The cross-references are denser. A data team’s table references a few other tables via foreign keys. A quality SOP references work instructions, equipment qualifications, validation protocols, regulatory citations, deviation histories, CAPA records, training matrices, and supplier documentation. Those references form a graph with 8-12 relationship types, not just parent-child.
The stakes are higher. If an agent retrieves the wrong version of a data table, the dashboard shows bad numbers. If an agent retrieves a superseded SOP during a deviation investigation, the investigation follows an obsolete procedure. In regulated environments, “almost right” is a compliance violation.
The bookkeeping is more painful. Karpathy’s key insight — “LLMs don’t get bored, don’t forget to update a cross-reference, and can touch 15 files in one pass” — maps directly to quality document maintenance. When an SOP is revised, it may require updating five training documents, two forms, three work instructions, and a validation protocol cross-reference list. Quality teams spend thousands of hours on this kind of maintenance. Agents are built for it.
The knowledge graph quality professionals already carry in their heads
Experienced QA professionals think in relationships. When investigating a deviation, they don’t search for semantically similar text. They follow a chain:
Deviation
→ Equipment involved
→ Cleaning SOP for that equipment
→ Validation protocol for that cleaning method
→ Validation report (approved/rejected)
→ Risk assessment for that process
→ Prior deviations on that equipment
→ CAPAs from those deviations
→ Change controls triggered by those CAPAs
→ Regulatory citations governing the processThat chain is a graph traversal. Today’s RAG systems — even sophisticated hybrid RAG combining vector search with BM25 — cannot reliably follow it. Vector embeddings don’t encode document IDs. “CAPA-2024-045” and “CAPA-2024-054” are semantically identical to an embedding model. Only keyword search can distinguish them. And flat vector databases have no concept of the relationships between a deviation and its linked CAPA, SOP, and equipment qualification.
MasterControl’s AI team published results in May 2025 showing that a triplet-based knowledge graph (subject-predicate-object extraction from regulatory documents) produced a graph with average shortest path of 1.33 hops — compared to 2.02 for the citation network alone. Among 5,014 document sections not connected through citations, 5,011 were connected through triplets. The semantic relationships between quality documents are far richer than the explicit references.
OKF’s cross-linking mechanism — standard markdown links between concept files — captures these relationships natively. An agent traversing the graph follows the same path a human investigator would.
What a GxP-adapted OKF bundle looks like
The vanilla OKF spec is minimally opinionated: it requires only a type field. For life sciences, you need more. The spec explicitly allows producer-defined extensions, so the right approach is to keep OKF conformance while adding domain-specific fields.
---
type: SOP
title: Environmental Monitoring of Cleanrooms
doc_id: SOP-ENV-042
version: "3.2"
status: Effective
effective_date: 2026-01-15
review_due: 2027-01-15
owner: Microbiology Department
site: [Dublin, CA]
product: [Product A, Product B]
regulatory_framework: [21 CFR Part 211, EU GMP Annex 1]
resource: https://veeva-vault.com/doc/SOP-ENV-042_v3.2
tags: [cleanroom, microbiology, gmp, iso-5]
timestamp: 2026-05-28T14:30:00Z
---
# Purpose
Define procedures for routine environmental monitoring of ISO 5 and ISO 7 cleanrooms.
# Scope
Applicable to all manufacturing areas at the Dublin facility.
# References
- [SOP-QA-001 Deviation Handling](/sops/SOP-QA-001-deviation-handling.md)
- [Environmental Monitoring Log](/forms/env-log.md)
- [21 CFR 211.42](/regulations/21-cfr-211.42.md)
# Related Deviations
- [DEV-2023-889](/deviations/2023/DEV-2023-889.md) — HVAC failure in Suite B
# Action Limits
| Grade | Alert Limit (CFU) | Action Limit (CFU) |
|-------|-------------------|-------------------|
| ISO 5 | 1 | 3 |
| ISO 7 | 10 | 25 |The key additions beyond vanilla OKF:
doc_idandversion— Quality documents have formal identifiers and version numbers. The timestamp alone isn’t sufficient; you need to know which revision is currently effective.status— Active, Effective, Superseded, Draft, Obsolete. Agents must filter on this to avoid quoting retired procedures.effective_dateandreview_due— Regulatory requirement. Documents have defined periods of validity.regulatory_framework— Links to the governing regulations (21 CFR Part 211, EU GMP Annex 15, ICH Q10, etc.).resource— Points back to the signed, approved PDF in the validated eQMS. This is non-negotiable.
The directory structure organizes around regulated entities, not just document types:
quality-system/
├── index.md
├── sops/
│ ├── index.md
│ ├── SOP-ENV-042-cleanroom-monitoring.md
│ └── SOP-QA-001-deviation-handling.md
├── deviations/
│ ├── index.md
│ └── DEV-2023-889-hvac-failure.md
├── capas/
│ ├── index.md
│ └── CAPA-2023-045.md
├── equipment/
│ ├── index.md
│ └── EQ-BR-99-incubator.md
├── validation/
│ ├── index.md
│ └── VP-234-cleaning-validation.md
├── regulations/
│ └── 21-cfr-211.67.md
└── products/
└── product-a/
└── index.mdEvery object is its own knowledge package. An agent doesn’t have to discover relationships — they already exist as markdown links.
The three non-negotiables for regulated use
1. The bundle is never the source of truth
The OKF bundle is a derived, agent-consumable knowledge layer. The signed PDF in Veeva Vault remains the legal record of control. Every OKF concept file must link back via the resource field to the validated eQMS document with its electronic signature and audit trail.
This is the single most important architectural decision. It means:
- Agents answer questions from the OKF bundle for speed and context assembly
- Agents cite the
resourcelink for verification - The OKF bundle can be regenerated from the eQMS at any time
- No regulatory inspector is ever shown an OKF file as evidence of a controlled document
2. The producer is validated, the consumer is not
The pipeline that extracts data from the eQMS and renders it into OKF markdown must be validated under GAMP 5 / Computer Software Assurance (CSA). It’s pulling from a validated system and producing a representation that agents will rely on. If the producer hallucinates a change in an action limit, and a human acts on it, that’s a critical compliance failure.
The agent consuming the bundle, the HTML visualizer, the vector index built on top — those can iterate fast without revalidation because they’re operating on a derived layer, not the system of record.
3. Version and status are explicit, not just timestamp
OKF’s timestamp field records “last meaningful change.” In quality systems, you need version, effective_date, status, and review_due. The producer should export only Effective and Superseded documents, marking Superseded clearly so agents don’t quote an old cleaning time.
The six-agent architecture this enables
With a GxP-adapted OKF bundle in place, you can deploy agents that would be impossible against raw PDFs in a traditional RAG pipeline:
1. Deviation Investigation Agent. Given a new deviation description, traverse the graph to find similar past deviations, their accepted root causes, whether CAPAs were effective, and what the risk assessment concluded. Output: a structured investigation starting point with full traceability.
2. Change Impact Agent. For a proposed change to a specification or raw material, follow backlinks to identify every SOP, validation protocol, stability study, regulatory filing, and product that references it. Output: an impact assessment table for human review.
3. Audit Readiness Agent. “Show me all open CAPAs related to cleaning for Product A that are past due” becomes a frontmatter query over status, tags, product, review_due — not an LLM guess over vector similarity. Output: a filtered, structured report.
4. Authoring Assistant. Draft new SOP revisions using the structure and approved language from the three most recent effective SOPs in the same family, with correct cross-links already inserted. Output: a draft document ready for QA review.
5. Training Impact Agent. When an SOP changes, identify all training records and personnel requiring retraining by traversing the SOP → training matrix → personnel graph. Output: a retraining assignment list.
6. Regulatory Intelligence Agent. When a new FDA guidance document is published, identify which SOPs, validation protocols, and specifications are potentially impacted by traversing the regulatory framework links. Output: a gap assessment.
What the industry is already doing
This isn’t hypothetical. The building blocks are in production:
MasterControl published their knowledge graph approach in May 2025, using subject-predicate-object triplet extraction to build a graph from regulatory documents. Their multi-agent pipeline (Ingestion → Extraction → Cleaning → Indexing → Retrieval → Story Builder) measured factual accuracy of 4.7/5.0 on ground-truth questions. The triplet network connected document sections that the citation network left disconnected.
USDM reported in January 2026 that AI is now embedded in validated QMS workflows — not as experiments. They define a five-level QMS AI maturity model: Assist (AI surfaces context), Draft (AI proposes language), Correlate (AI links related records across systems), Orchestrate (agentic workflows with human approval gates), and Continuously Assured (AI behavior monitored as part of validated state). Most organizations are at level 2-3.
Google Cloud published OKF alongside an agentic evaluation framework with trajectory-based metrics — exact match, in-order match, any-order match, precision, and recall — aligned to ALCOA+ requirements for auditability and traceability.
The FDA and EMA released joint guiding principles for good AI practice in drug development lifecycles in January 2026, signaling that regulators are preparing for this shift rather than resisting it.
The practical path forward
Don’t try to convert your entire QMS into OKF. Start with a bounded pilot:
Pick one domain. Deviations and CAPAs for one site, one product line, for the last two years. These are high-value, well-structured, and heavily cross-referenced.
Build the producer. A validated exporter that pulls from your eQMS via API, renders markdown, and runs an LLM pass to extract relationship joins (e.g., “SOP-00123 is referenced by DEV-2024-1142” and “CAPA-2024-089 closes DEV-2024-1142”). Validate this under CSA.
Test with golden questions. The bundle must support three kinds of queries before you expand:
- Which version of an SOP is currently effective?
- What CAPA closed a specific deviation, and was it effective?
- What specifications are impacted by a proposed change?
If it nails those three, you have a business case.
Expand to SOPs and specs. Add the core document types with full cross-linking.
Wire your RAG pipeline. Point your existing agent infrastructure at the OKF folder instead of trying to integrate with five vendor APIs. The bundle becomes the single source of context for every agent.
The bigger picture
Google positioned OKF as “a better documentation format.” It’s actually something bigger: an intermediate representation between enterprise knowledge and AI agents. Once your quality knowledge is in this form, every agent — deviation investigation, CAPA recommendation, audit readiness, regulatory Q&A, authoring, training impact, change control analysis — can use the same underlying knowledge layer.
The quality management software vendors (Veeva, MasterControl, TrackWise) built excellent systems for managing controlled documents. They never built the interoperability layer that lets AI agents reason across those documents. OKF is that layer. It’s vendor-neutral, human-readable, version-controllable, and agent-parseable.
The format isn’t the hard part. The hard part is earning trust in a regulated environment, building domain-specific conventions that quality professionals actually find useful, and demonstrating that agents operating over this structured knowledge produce reliably accurate outputs — because in life sciences, “mostly right” isn’t good enough.
But the alternative — building yet another proprietary knowledge graph that locks quality data into a single vendor, or continuing to throw raw PDFs at vector databases and hoping the chunks line up — is clearly worse. The industry needs a better knowledge representation for AI. OKF, adapted for GxP, is the closest thing to a solution that exists today.
The OKF v0.1 specification and reference implementations are available at github.com/GoogleCloudPlatform/knowledge-catalog. Karpathy’s LLM Wiki pattern is at gist.github.com/karpathy/442a6bf555914893e9891c11519de94f.