A 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. The spec was built for data engineering teams drowning in fragmented metadata. After examining 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, and provided you understand where the format itself is the wrong layer entirely.

This guide synthesizes the complete picture: what OKF is, why life sciences is the better use case, what a GxP-adapted bundle looks like, where the regulatory friction points live, what architecture every analysis converged on, and what to actually do on Monday morning if you’re rolling this out against an existing validated QMS.

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.

The intellectual lineage runs through Andrej Karpathy’s LLM Wiki pattern: treat an LLM-curated, hyperlinked corpus of markdown files as the canonical representation of what an organization knows, and let agents traverse it the same way a researcher navigates Wikipedia — by following links from concept to concept. The core insight is that LLMs don’t get bored, don’t forget to update a cross-reference, and can touch fifteen files in one pass. The drudgery of maintaining a knowledge graph is exactly the work that language models excel at.

Why life sciences is the better fit

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 twenty 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 eight to twelve 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. 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 graph already exists in expert 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 process

Today’s RAG systems — even sophisticated hybrid RAG combining vector search with BM25 — cannot reliably follow that chain. 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_id and version — 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_date and review_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.md

Every object is its own knowledge package. An agent doesn’t have to discover relationships — they already exist as markdown links.

The regulatory friction points

Applying OKF to life sciences runs into five specific objections that don’t exist in the data-engineering context OKF was designed for. Every one of them is serious.

Shadow QMS risk

21 CFR Part 11 and EU Annex 11 exist because life sciences learned — through consent decrees, product recalls, and patient harm — that uncontrolled copies of quality documents are dangerous. If an SOP exists as a signed PDF in Veeva Vault and as an enriched markdown file in a git repo, the markdown file is an uncontrolled copy. Full stop.

The defense — “it’s just a derived layer, the QMS is still the source of truth” — sounds clean in an architecture diagram. It doesn’t survive contact with an agent that’s reading from the markdown because it’s faster, or an operator who acts on a cleaning time from the OKF bundle because the agent cited it confidently. Dual-representation systems always drift. The OKF bundle will be stale. The enrichment pipeline will miss a superseded version. The cross-reference will point to the wrong CAPA. And when it does, the legal defense — “the AI was reading a shadow markdown file, not the actual SOP” — will not hold up in an FDA audit.

Validation burden

Under GAMP 5 and the ISPE GAMP AI Guide (published July 2025, 290 pages), any system that touches GxP data may need validation. The pipeline that extracts documents from Veeva, transforms them to markdown, enriches them with an LLM, and stores them in a git repo is GxP software. It needs Installation Qualification, Operational Qualification, and Performance Qualification; change control for every modification; periodic review; and revalidation when the model changes, the prompt changes, the OKF spec bumps, or the extraction logic updates.

Every prompt change to the enrichment agent is a change to a validated system. Every model upgrade requires revalidation. By the time you’ve built and validated this pipeline, you’ve spent more money than it would cost to hire three quality specialists who can do the work with accountability that a regulator will actually accept.

The ISPE AI Guide makes this concrete: it requires training data provenance, model documentation, performance evidence under defined testing conditions, change-notification commitments, and explainability artifacts. For a custom OKF producer built on an LLM, that’s a massive validation package for a system whose value proposition is “makes it easier for another AI to read things.”

Vendor API solutions already exist

In early 2025, Veeva announced the Direct Data API — included at no additional license cost with the Vault Platform. It delivers Vault data up to 100 times faster than traditional APIs, with transactional consistency across large datasets. It produces full, incremental, and log data files on 15-minute schedules. Open-source accelerators for Snowflake, Databricks, Redshift, Azure SQL, and SQLite are on GitHub.

Veeva’s partnership with Snowflake, specifically targeting agentic AI in life sciences, signals where the industry is going: validated QMS → high-throughput API → data warehouse → AI agents. Not: validated QMS → markdown export → git repo → agents reading files.

The fragmentation problem that OKF was designed to solve is being addressed at the infrastructure layer by the vendors themselves. An agent with access to Snowflake can query the live QMS data model with SQL joins that return mathematically correct relationships — not markdown links that might point to the wrong file.

Knowledge graph maintenance costs

A 2025 survey of enterprise data leaders found that 67% of abandoned knowledge graph projects cited “lack of internal graph expertise” as the primary failure cause. Teams typically abandon implementations within 18 months or continue operating them at costs exceeding simpler alternatives. Knowledge graphs amplify data quality problems rather than solving them: if entity resolution accuracy sits below 85%, the graph confidently connects the wrong documents, making every downstream insight unreliable.

In life sciences, the problem is worse. A single SOP change triggers cascading relationship updates across validation protocols, training matrices, equipment qualifications, regulatory citations, and CAPA linkages. If those links aren’t maintained automatically, they become stale. If they are maintained automatically by an LLM, you’ve built a nontrivial graph maintenance system that itself needs validation — and the LLM will confidently link DEV-2024-1142 to the wrong CAPA because the titles are similar.

Markdown permissiveness vs. enforced structure

OKF’s pitch — “if you can cat a file, you can read OKF” — appeals to developers. Quality professionals think in Word documents with track changes, PDFs with controlled headers, and electronic signature workflows.

Markdown is too permissive for regulated documentation. An SOP must have Purpose, Scope, Responsibilities, Definitions, Procedure, References, Revision History — every time, in that order. Markdown means every author formats headers differently, some skip sections, and agents fail to reliably extract “the root cause” from a CAPA report because the section header is # Root Cause Analysis in one file and ## Determination of Causal Factors in another. And the “human readability” advantage is irrelevant. Quality documents are already human-readable in their current formats inside validated eQMS systems. What you gain in GitHub-renderability, you lose in enforced structure — which is the entire point of a quality system.

Where every side converged

These objections are real. But they don’t kill the underlying insight. When the original pro-OKF case was stress-tested against regulatory reality, validation economics, and what the QMS vendors are actually building, the honest conclusion that emerged was this: OKF solves the easy part of a problem whose hard part remains untouched — and the winning architecture looks nothing like a directory of markdown files.

When ten independent analyses were asked the same question — “should life sciences quality organizations adopt OKF?” — every single one converged on the same architecture:

Layer Role OKF involvement
Validated QMS (Veeva, MasterControl) Source of truth None
Data warehouse / semantic index Structured context layer None
Dynamic knowledge graph Relationship traversal Built from QMS metadata
Agent tools Function calling against live APIs OKF-shaped responses, ephemeral
Human decision Approval and oversight None

Zero out of ten recommend adopting OKF as a replacement for the eQMS. Zero recommend abandoning structured knowledge representation entirely and just using raw RAG over PDFs.

Three points showed up in every single analysis:

  1. The underlying insight is correct. AI agents in life sciences need explicit, linked, structured knowledge with relationships — not just vector similarity search over chunked PDFs. Graph traversal is superior to semantic search for quality investigations. Cross-referencing and traceability matter.

  2. The validated system must remain the source of truth. 21 CFR Part 11, EU Annex 11, and ALCOA+ data integrity principles are not negotiable. Electronic signatures, immutable audit trails, access controls, and change management happen in the eQMS. A markdown file in a git repo is not a controlled document.

  3. A derived knowledge layer is the right pattern. Something needs to sit between the validated systems and the AI agents — a projection that assembles context across silos, preserves relationships, and makes knowledge agent-consumable.

The real disagreement was about two implementation questions. Should the derived layer be persistent or ephemeral? The answer is persistent index, ephemeral content. The metadata and relationships can be maintained as a persistent graph (because they change slowly and are derived deterministically from the QMS schema). The document content should be pulled live or refreshed frequently (because it changes often and staleness is a compliance risk).

Should the format be markdown or structured data? The answer is structured data with markdown as an optional rendering layer. The Veeva Direct Data API exports structured CSV with full schema metadata. MCP serves structured JSON responses. The agent doesn’t need markdown — it needs structured data with explicit relationships. If a human-readable rendering is needed, it can be generated from the structured data, not stored as the primary format.

The architecture

The architecture that every analysis converged on, and that the industry is actually building, looks like this:

Validated QMS (Veeva Vault)
  ↓  Direct Data API / MCP connectors (read-only, 15-min refresh)
Data Integration Layer (Snowflake / semantic index)
  ↓  Dynamic knowledge graph from QMS metadata
  ↓  Vector embeddings from document content
AI Agent Layer (MCP tool-use, function calling)
  ↓  Full retrieval audit trail
Human Decision (with source citations)

No markdown files. No git repos. No parallel document format. The knowledge representation lives in the data warehouse and the MCP tool definitions. The graph is built dynamically from the QMS metadata. The agent calls live APIs for time-sensitive data.

Why PostgreSQL — and why it matters now

For organizations building a QMS from scratch, every analysis named PostgreSQL specifically. Two reasons:

First: JSONB columns for flexible metadata. Quality documents have rigid required fields (document ID, version, status, effective date) but also variable metadata depending on type. A deviation needs severity, root cause category, and impacted batches. A validation protocol needs acceptance criteria, statistical method, and sample size. PostgreSQL’s JSONB lets you enforce the required fields in relational columns while storing type-specific metadata in a validated JSONB field with JSON Schema constraints.

Second: PostgreSQL 19 ships native graph queries. This is the development that changes the architectural calculus. PostgreSQL 19, in beta since June 2026, implements SQL/PGQ — the ISO SQL:2023 Property Graph Queries standard. You define a property graph as a view over your existing relational tables, then query it with MATCH syntax:

SELECT * FROM GRAPH_TABLE (quality_graph
    MATCH (dev IS deviation WHERE dev.id = 'DEV-2026-102')
          -[IS involved_equipment]->(eq IS equipment)
          -[IS governed_by]->(sop IS sop)
          -[IS validated_by]->(vp IS validation_protocol)
    COLUMNS (eq.name, sop.doc_id, vp.doc_id, vp.status)
);

This traverses Deviation → Equipment → SOP → Validation Protocol in a single query. No separate graph database. No Neo4j. No Apache AGE extension. No data migration. The graph runs over the same tables that hold your validated data, using the same indexes.

For a QMS where the knowledge graph is a core feature — “show me everything connected to this deviation across three hops” — this eliminates the biggest architectural objection to building graph capabilities into a greenfield system.

The OKF-shaped API contract

The database holds the validated state. The knowledge graph captures relationships. The API serves OKF-shaped projections to agents — on demand, ephemeral, regenerated every request.

Every quality object exposes an endpoint that returns an OKF-shaped response:

GET /api/v1/okf/concepts/sop/SOP-00123

Returns:

---
type: SOP
doc_id: SOP-00123
title: Equipment Cleaning - Grade C/D Areas
version: 4.2
status: Effective
effective_date: 2026-01-15
review_due: 2027-01-15
owner: Manufacturing QA
site: [Dublin, CA]
product: [Product A, Product B]
regulation_refs: [21 CFR 211.67, EU GMP Annex 1]
resource: /api/v1/qms/documents/SOP-00123/v4.2/pdf
staleness: 2026-07-11T04:00:00Z
training_required: true
risk_level: High
---
# Purpose
Standard cleaning procedure for equipment in Grade C and D areas
at the Dublin facility.

# Related Documents
- [Work Instruction WI-088](/api/v1/okf/concepts/work-instruction/WI-088)
- [Validation Protocol VP-234](/api/v1/okf/concepts/validation/VP-234)
- [Equipment EQ-442](/api/v1/okf/concepts/equipment/EQ-442)
- [21 CFR 211.67](/api/v1/okf/concepts/regulation/21-cfr-211.67)

# AI Guidance
retrieval_priority: high
common_questions:
  - "What cleaning method is required after Product X?"
  - "What is the rinse verification procedure?"
known_risks:
  - "Cleaning validation failures when operators skip rinse verification (Section 3.2.4)"

Three things to notice:

The resource field points to the live QMS. If the agent needs the actual controlled PDF — for citation, for verification, for a decision that requires the approved document — it follows the resource link to the validated system, which enforces training requirements and access controls.

The staleness field is a timestamp, not a guarantee. The agent is expected to check this before relying on time-sensitive fields (approval status, effective version). For anything decision-relevant, the agent calls GET /api/v1/qms/status/SOP-00123 against the live system.

The AI Guidance section is separate from regulatory content. Common questions, known risks, retrieval priority — these are AI-specific enrichment fields that help agents reason more effectively. They’re stored separately from the regulatory content and can be updated without triggering change control on the document itself.

The graph layer

The graph is defined as a property graph over existing relational tables:

CREATE PROPERTY GRAPH quality_graph
  VERTEX TABLES (
    sops LABEL sop
      PROPERTIES (id, doc_id, title, version, status, effective_date),
    deviations LABEL deviation
      PROPERTIES (id, deviation_id, severity, status, discovered_date),
    capas LABEL capa
      PROPERTIES (id, capa_id, status, effectiveness_status),
    equipment LABEL equipment
      PROPERTIES (id, equipment_id, name, location, qualification_status),
    validation_protocols LABEL validation
      PROPERTIES (id, doc_id, title, status),
    regulations LABEL regulation
      PROPERTIES (id, regulation_id, title, framework)
  )
  EDGE TABLES (
    sop_references_equipment
      SOURCE KEY (sop_id) REFERENCES sops (id)
      DESTINATION KEY (equipment_id) REFERENCES equipment (id)
      LABEL references,
    deviation_involves_equipment
      SOURCE KEY (deviation_id) REFERENCES deviations (id)
      DESTINATION KEY (equipment_id) REFERENCES equipment (id)
      LABEL involves,
    capa_closes_deviation
      SOURCE KEY (capa_id) REFERENCES capas (id)
      DESTINATION KEY (deviation_id) REFERENCES deviations (id)
      LABEL closes,
    sop_validated_by
      SOURCE KEY (sop_id) REFERENCES sops (id)
      DESTINATION KEY (protocol_id) REFERENCES validation_protocols (id)
      LABEL validated_by
  );

The graph edges come from the database foreign keys — the same relationships that the QMS already enforces. No hand-maintained markdown links. No LLM-enriched cross-references. The graph is as accurate as the database, because it IS the database, viewed as a graph.

When an agent needs to traverse relationships, it calls:

GET /api/v1/okf/graph/deviation/DEV-2026-102?hops=3

The API runs a SQL/PGQ MATCH query and returns the connected subgraph as a set of OKF concepts with their relationships expressed as markdown links. The agent gets a navigable knowledge graph without ever touching the database directly.

The validation story

This is where the architecture earns the right to exist in a regulated environment.

What gets validated:

  • The PostgreSQL database schema and constraints
  • The API endpoints and their permission enforcement
  • The PDF rendering engine (database → canonical PDF at moment of signature)
  • The OKF serialization logic (database → OKF-shaped response)

What doesn’t get validated:

  • The OKF content itself (it’s a derived projection, regenerated on every request)
  • The agent consuming the OKF responses (it’s reading from a validated API)
  • The AI enrichment fields (they’re advisory, not regulatory content)

This is dramatically cheaper than validating a custom markdown export pipeline. The OKF serialization is a deterministic function: same database state → same OKF output. It can be tested once and trusted. The database is already validated because it’s the QMS.

What the agent workflow looks like

A deviation investigation agent, working within this architecture:

  1. Receives a deviation description from the user
  2. Calls GET /api/v1/okf/concepts/deviation/DEV-2026-102 — gets structured metadata and related links
  3. Calls GET /api/v1/okf/graph/deviation/DEV-2026-102?hops=3 — gets the connected subgraph (equipment, SOPs, prior deviations, CAPAs, validations)
  4. Reads the OKF concepts for each connected entity — gets structured context with AI guidance
  5. Calls GET /api/v1/qms/documents/SOP-00123/v4.2/sections/3.2 — gets the specific procedure section from the live QMS (enforcing training check)
  6. Synthesizes an investigation starting point with full traceability
  7. Presents the draft to a human reviewer, citing every source

Every step is logged. Every document access is auditable. The agent never writes to the QMS. The human approves every decision.

For existing systems — the rollout playbook

Most organizations reading this aren’t building a QMS from scratch. They have Veeva, or MasterControl, or TrackWise, or a custom QMS that’s been validated since 2014. They can’t rip it out. They can’t revalidate it. They need to know what to actually do on Monday morning.

The guiding principle: never make your validated system more AI-friendly. Make your AI understand the validated system.

The three zones

Before picking patterns, understand the compliance landscape. Every piece of knowledge in a regulated organization falls into one of three zones:

Green Zone (Non-GxP): Tribal knowledge, engineering notes, regulatory guidance interpretations, internal runbooks, meeting minutes, project documentation. No 21 CFR Part 11 requirements. No validation burden. OKF can be used aggressively.

Yellow Zone (GxP-Adjacent): Approved SOPs, validation protocols, deviation records, CAPA records. These live in validated systems. OKF can be a read-only derived layer, never the source of truth.

Red Zone (GxP-Controlled): Electronic signatures, audit trails, approval workflows, batch release decisions. OKF has no business here. These stay in the validated system, untouched.

The rollout strategy: start in the Green Zone, prove value, expand into the Yellow Zone with strict controls, never touch the Red Zone.

The ten patterns

When ten independent analyses were asked to design a practical rollout, they converged on these ten patterns:

1. Tribal Knowledge Capture (Green Zone). Every regulated organization has a massive body of knowledge that isn’t in any validated system. Why a process was designed a certain way. What happened the last three times this supplier changed their manufacturing site. The unwritten rules for interpreting an ambiguous analytical result. Build an OKF-structured knowledge base organized by equipment, process, regulatory interpretation. Zero regulatory risk. No validation burden. Immediate value for onboarding and agent context.

2. Regulatory Intelligence Wiki (Green Zone). FDA guidance, ISO standards, ICH guidance, EU Annexes — mostly static, publicly available, perfect candidates for structured OKF representation. Instead of asking AI to repeatedly parse a 400-page guidance document, you provide structured regulatory knowledge with cross-references to your SOPs and practical interpretations.

3. Domain Ontology (Green Zone). Build an enterprise quality dictionary in OKF format. Every regulated entity — Equipment, Product, Batch, Deviation, CAPA, Validation, SOP, Supplier, Risk — gets its own concept file with definition, relationships, synonyms, common questions, and regulatory references. This solves one of the biggest enterprise AI problems: “What does this company actually mean by this term?”

4. Nightly Sidecar Export (Yellow Zone — The Big Win). Build a small service that runs outside your validated boundary. Every night it calls the validated APIs, pulls Effective documents only, and renders an OKF bundle to a separate, non-GxP bucket. What to export first: deviation and CAPA knowledge graph (highest pain, lowest risk), SOP and spec index (purpose, scope, key parameters, equipment list — not full procedures), change control trace. Every generated concept carries mandatory provenance fields:

---
type: Deviation
doc_id: DEV-2026-102
source_system: veeva_vault
source_id: DOC-2024-00847
source_url: https://vault.company.com/DOC-2024-00847
source_last_modified: 2026-07-10T14:30:00Z
bundle_generated_at: 2026-07-11T02:00:00Z
---

Rules for this exporter: filter to Effective and Closed only (no Drafts); render, do not enrich in v1 (no LLM rewriting — deterministic mapping from QMS fields to frontmatter); access filter at render time (if the agent user isn’t trained on SOP-123, don’t include it in their bundle); label everything NON GXP - DECISION SUPPORT - VERIFY IN SYSTEM OF RECORD.

5. Cross-System Stitching (Yellow Zone). The highest-value application isn’t replacing any single system — it’s the place where quality knowledge is scattered across systems that don’t talk to each other. SOP in the eQMS, method validation in the LIMS, deviation history in a separate CAPA tool, equipment logs in a CMMS. Generate OKF concepts from each system with consistent type conventions and let markdown links be the connective tissue. This gives you one browsable, agent-queryable graph without requiring any of the underlying systems to integrate with each other directly. This is the “AI sidecar” pattern emerging across enterprise AI: a decoupled intelligence layer that runs alongside existing applications, intercepting data, applying intelligence, and returning enriched outputs — without touching the core system.

6. Investigation Playbooks (Green/Yellow Zone). Deviation investigations are procedural. Check batch history. Check equipment log. Review environmental monitoring. Review training. Review cleaning. Review maintenance. Review prior CAPAs. Create AI-readable investigation guides in OKF format. Agents become dramatically better investigators when they have structured procedural knowledge to follow, not just vector similarity search over past reports.

7. AI Companion Objects (Yellow Zone). Every controlled document gets a non-controlled companion. The SOP stays in Veeva. Next to it lives an AI companion with summary, common questions, related equipment, typical deviations, and key risks. The companion is regenerated automatically when the SOP changes. The agent reads the companion first, then drills into the original document for evidence. This dramatically reduces token usage while improving grounding.

8. Audit Preparation Bundles (Yellow Zone). Before an FDA inspection, generate an OKF bundle that walks an inspector through: the product specification, the manufacturing process flow, the validation protocol, the batch records, the deviations and CAPAs — all with links back to the controlled records in their native systems. This is a guided tour, not a data migration. Inspectors currently ask you to pull records from five systems and explain the relationships manually. An OKF bundle gives them a readable, traversable narrative while keeping the original records in their validated homes.

9. MCP Tool Integration. Model Context Protocol, created by Anthropic and adopted by OpenAI, Google, Microsoft, and AWS, lets AI agents call tools against live APIs — get_effective_version("SOP-00123"), list_open_capas("Product-A"), search_deviations("Equipment-442", last_n_months=24) — with full audit trails and access controls. USDM is positioning MCP as the regulated AI integration layer. Deepsense.ai is building production MCP servers for healthcare and life sciences. This is the protocol layer that makes the architecture work.

10. Continuous Regeneration Pipeline. The derived layer is never a snapshot — it’s a projection that’s rebuilt from the validated source on a defined schedule (nightly for content, real-time for status). The bundle generation timestamp is in every concept’s frontmatter. An agent or auditor can check mechanically whether the bundle is current.

The rollout timeline

Week Pattern Risk Value
1-2 Tribal Knowledge Capture None High
3-4 Regulatory Intelligence Wiki None Medium
Month 2 Nightly Sidecar Export (deviations/CAPAs) Low Very High
Month 3 Cross-System Stitching (2 systems) Low High
Month 4 AI Companion Objects (top 50 SOPs) Low High
Month 6 Audit Preparation Bundles Low High
Month 9 Investigation Playbooks Low Medium

The anti-patterns

What NOT to do:

  • Don’t store approved SOPs as OKF markdown files as the controlled record
  • Don’t let agents edit OKF files that are synced back to the QMS
  • Don’t use OKF as the primary database for batch records
  • Don’t treat OKF as a lightweight eQMS for a startup
  • Don’t let the enrichment LLM rewrite procedure text — render only
  • Don’t confuse git history with the audit trail — the audit trail stays in the source system

What OKF’s contribution was

OKF’s contribution to this conversation was real, even if the format itself isn’t the answer for regulated environments. Three ideas from OKF are now embedded in the architecture the industry is building:

One concept per file (or per record). The principle that knowledge should be organized around discrete, self-describing entities — not buried in monolithic documents — maps directly to how QMS data models work. A deviation is a record. A CAPA is a record. An SOP version is a record. Each has structured metadata and relationships to other records.

YAML frontmatter as structured metadata. The idea that every knowledge unit should carry queryable metadata (type, status, version, effective date, tags) is now standard in every QMS data model. Veeva’s Direct Data API exports exactly this — structured metadata alongside content.

Cross-links as a graph. The principle that relationships between concepts should be explicit, not implicit, is the foundation of every knowledge graph implementation in life sciences. The difference is that the industry builds these graphs from QMS database relationships, not from markdown links.

OKF formalized these ideas into a spec. The industry is implementing them through APIs, data warehouses, and agent protocols. The spec was a useful thinking tool. The implementation path runs through different infrastructure.

The bottom line

The pattern behind OKF — explicit knowledge, linked concepts, structured metadata, graph traversal — is the right pattern for AI in regulated environments. The format was a useful way to articulate it.

But the implementation the industry needs is already being built, and it runs through APIs, data warehouses, and agent protocols — not through directories of markdown files.

For organizations with existing validated systems: don’t build a markdown knowledge base; the validation burden is real, the drift risk is real, and the vendors are solving the problem at a layer that doesn’t require you to maintain a parallel document format. Don’t just throw PDFs at a vector database; pure RAG over chunked documents loses relationships, misses version control, and can’t distinguish document IDs. Do invest in connectors to your validated systems — Veeva’s Direct Data API is free and fast, MCP is an open protocol with broad vendor support. Do build dynamic knowledge graphs from QMS metadata. Do force agents to call live APIs for time-sensitive data. Do log every retrieval for compliance.

For organizations building from scratch: the database is the truth, the graph is the relationships, and OKF is the agent-facing contract. Build the validated core that speaks OKF to agents, with a knowledge graph that agents can traverse, and an API that enforces compliance at every endpoint. PostgreSQL 19 with SQL/PGQ makes this architecture simpler than it would have been even a year ago.

The next QMS startup that gets built won’t choose between “validated but opaque” and “AI-friendly but uncontrolled.” It will build both from day one.

The pattern is right. The format is wrong for storage. The vendors are building the API layer. The architecture has converged. The remaining question is whether organizations will invest in the connectors and knowledge graph layers that make their validated systems AI-accessible — or keep throwing PDFs at vector databases and hoping the chunks line up.

Sources and further reading: