A week ago, I argued that Google’s Open Knowledge Format could be the missing foundation for AI agents in life sciences quality. The thesis was clean: fragmented quality knowledge needs a portable, structured, agent-readable representation, and OKF — markdown files with YAML frontmatter and cross-links — maps naturally onto the relationship graph that quality professionals carry in their heads.

The thesis is directionally correct. The implementation is wrong.

After stress-testing the idea against regulatory reality, validation economics, and what the QMS vendors are actually building, the honest conclusion is that 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.

The strongest counterarguments, taken seriously

1. You’re building a shadow QMS that violates data integrity

This is the argument that kills the proposal in any QA review meeting.

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.

2. The validation burden eats the ROI alive

This is the argument that kills the proposal in a budget meeting.

Under GAMP 5 and the ISPE GAMP AI Guide (published July 2025, 290 pages, the document inspectors will quietly assume you’ve read), 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, Performance Qualification
  • Change control for every modification
  • Periodic review
  • 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 (GPT-4 to GPT-5) 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.”

3. The vendors are already solving the API problem

This is the argument that makes the proposal unnecessary.

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 — “knowledge is trapped in siloed systems with no portable format” — is being addressed at the infrastructure layer by the vendors themselves. Veeva’s Direct Data API makes the entire Vault data model available as structured CSV files with full schema metadata, every 15 minutes, with no additional license cost. 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.

4. Knowledge graphs fail at scale in most organizations

The promise of a richly interconnected knowledge graph — Equipment → Cleaning SOP → Validation → Prior Deviations → CAPAs — sounds elegant. Maintaining it is not.

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.

5. The real bottleneck is judgment, not context assembly

The framing — “agents can’t assemble context across siloed systems” — is true but overstated. The actual bottleneck in quality work is a human deciding whether a deviation is a real risk to patient safety, whether a CAPA is effective, whether a process change requires a new validation study.

That judgment requires understanding analytical chemistry, process capability, regulatory precedent, and patient risk. It requires the pattern recognition that a senior quality professional builds over 20 years — knowledge that isn’t captured in any document, structured or otherwise. A senior QA lead who knows that this particular deviation pattern on this particular equipment is a harbinger of a process capability issue is drawing on experience that no markdown file with good cross-references can approximate.

Giving an agent more context in a cleaner format doesn’t fix the reasoning gap. It gives the agent more material to be confidently wrong about — and a well-contextualized agent producing authoritative-sounding output actively discourages the critical thinking that quality work requires.

6. “Just markdown” is a liability, not a feature

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.

7. You’re solving the wrong bottleneck with the wrong tool

The Karpathy observation — “LLMs don’t get bored, don’t forget to update a cross-reference, and can touch 15 files in one pass” — maps beautifully to software documentation. It maps dangerously to quality documents.

Every change to a GxP document requires a formal change control workflow: impact assessment, review, approval, electronic signature. An agent that “touches 15 files in one pass” has triggered 15 unapproved changes. The drudgery of change control is not accidental bureaucracy. It is risk management. Automating it away with an LLM is how you get FDA 483 observations and product recalls.

What the winning architecture actually looks like

The right architecture for AI agents in life sciences quality doesn’t introduce a new document format. It makes the existing validated systems more accessible:

Validated QMS (Veeva Vault, MasterControl)
  ↓  Direct Data API / REST API / VQL
Data Warehouse (Snowflake, Databricks)
  ↓  Structured metadata + full schema
Semantic Index (vector embeddings from authoritative content)
  ↓  Dynamic knowledge graph built from QMS relationships
Agent Tools (function calling against live APIs)
  ↓  get_effective_version(doc_id), list_open_capas(product)
Human Decision (with retrieval audit trail and source citations)

In this architecture:

  • The QMS remains the single source of truth. No dual representation.
  • Relationships are queried dynamically from the database, not duplicated in markdown files. A SQL JOIN between the deviation table and the CAPA table returns mathematically correct linkages. A markdown link might point to the wrong file.
  • The agent calls get_effective_version("SOP-00123") against the live API and gets the current approved version with its full audit trail — not a cached markdown file that might be stale.
  • Every retrieval is logged for compliance. The system knows exactly which documents the agent accessed, which chunks it used, and what it cited.
  • No custom validated pipeline to maintain beyond the connectors. The validation burden stays with the vendor (Veeva’s Direct Data API is part of the validated Vault platform).
  • The knowledge graph is built dynamically from the QMS metadata at query time. When a SOP changes, the graph changes instantly because it’s reading from the source, not from a synchronized copy.

Where OKF’s insight is still right

The core insight behind OKF isn’t wrong. Agents do benefit from structured knowledge with explicit relationships. Graph traversal is superior to pure vector search for quality investigations. Cross-referencing and traceability matter.

But the insight should be applied at the metadata and query layer, not the document layer:

Build the knowledge graph from the QMS database, not from markdown files. Veeva’s data model already contains the relationships — documents link to change controls, which link to deviations, which link to CAPAs. Extract that graph into a graph database or a semantic index. Let agents traverse it via API calls.

Use the ontology that already exists. The QMS schema defines document types, statuses, approval states, and relationship types. Don’t reinvent that in YAML frontmatter. Query it.

Invest in better connectors, not better formats. The bottleneck for AI in life sciences isn’t “the format isn’t agent-friendly enough.” It’s “the APIs are hard to work with, the data is messy, and the validation requirements are heavy.” Veeva’s Direct Data API is a major step toward solving the first problem. The second and third are organizational, not technical.

The honest verdict

OKF is an elegant format designed for a context — software engineering, data teams, fast-moving AI ecosystems — where the cost of error is a broken dashboard, flexibility beats rigor, and “just files” is a feature. Life sciences quality is the opposite context: the cost of error is patient safety, rigor beats flexibility, and “just files” is a compliance risk.

The pattern’s underlying insight — explicit, linked, structured knowledge makes AI agents dramatically more capable — is correct and important. But the implementation needs to live at the query and metadata layer, validated against the live QMS, not in a parallel document format that creates a second, unofficial system of record.

The vendors are solving the API problem. The validation economics don’t support a custom format layer. The winning architecture puts intelligence in the agent’s tool-use against live systems, not in a static cache of enriched markdown files.

If you’re building AI agents for life sciences quality today, invest in connectors to your validated QMS, dynamic knowledge graph construction from the metadata layer, and agent tool-use patterns with full retrieval audit trails. Don’t invest in a new document format. The format was never the problem.

The ISPE GAMP Guide: Artificial Intelligence (July 2025) is available at ispe.org. Veeva Direct Data API documentation is at developer.veevavault.com/directdata. Open-source accelerators for Snowflake/Databricks integration are at github.com/veeva/Vault-Direct-Data-API-Accelerators.