Somewhere in your stack, a retrieval pipeline is reading the same PDF for the ten-thousandth time. Same chunks, same embeddings, same answer assembled from scratch, and it still fumbles the edge case. RAG never learns anything. It re-derives.

Andrej Karpathy put the alternative in a gist this spring, and it hit five thousand stars in a few days. Stop retrieving. Compile. Let the model maintain a wiki of what it knows, in plain markdown, and query that instead. The idea is not new. What is new is how many people arrived at it at once, and what happens when you try to run it inside a bank.

Because the interesting artifact here is not a tool. It is a contract. And you already own the infrastructure to honor it.

The idea everyone reinvented

I made this case once already. In Markdown Is the Knowledge Layer I argued that Karpathy’s gist and Google’s Open Knowledge Format were the same idea at two scales: plain text in git, running from a personal second brain all the way up to a company knowledge layer. This is the follow-up. A third project has entered, the field has exploded, and the question has moved. It is no longer “is markdown the knowledge layer.” It is “how do you deploy it where a regulator is watching.”

Karpathy’s version, in a paragraph. Raw sources stay immutable. A set of markdown files becomes the wiki the model writes and rewrites, cross-linked into a graph. A schema file tells the model the conventions. The whole point is the bookkeeping. Every personal wiki and every team Confluence dies the same death, because the upkeep cost grows faster than the value and a human eventually stops paying it. A model pays it for free.

The tell is that nobody needed convincing. Within days the gist had a wave of implementations behind it: compiler plugins for coding agents that claim to cut context cost by ninety percent (see llm-wiki-compiler), a desktop app, a hosted service, a bundled agent skill. Same three directories every time. Sources in, wiki out, a schema to keep it honest.

Here is the part that matters for everything after. The shape did not start with Karpathy, and it will not end with him. Weeks before the gist went viral, two researchers had already formalized a version of it and put it on arXiv. Google’s format landed later and credited him by name. When the same structure shows up independently from a solo developer, an academic paper, and a hyperscaler inside a single quarter, it is not a trend. It is an equilibrium. You build on an equilibrium. You do not marry the tool that happens to be trending this week.

Two children, one shape

Most of those implementations are point tools. They run the compile step and stop. Useful, disposable, and not something you would put a compliance program on top of. Two projects went further and wrote down a contract, and those two are the ones worth a regulated shop’s time. They disagree about what the contract is for, which is exactly why you read both.

ICM: the folder is the workflow

Jake Van Clief and David McDermott formalized their version as Interpretable Context Methodology, built on what they call the Model Workspace Protocol. The claim is blunt. Most agent orchestration is code that shuffles context between steps, handles errors, and coordinates memory. For a sequential workflow where a human reviews each step, that code is overhead the problem never needed. Replace it with folders. Numbered directories are stages. Markdown files carry the prompt and the context for each step. Local scripts do the mechanical work no model should touch. One agent, reading the right files at the right moment, does the work a multi-agent framework would.

The reference implementation ships as a skill (see icm-architect): describe the work, and it picks one of five patterns (pipeline, umbrella, record library, knowledge bundle, context map) and scaffolds a workspace. The lineage it cites is Unix pipelines, literate programming, and multi-pass compilers. The load-bearing property, for our purposes, is a different one. Open any folder and you can see the entire state of the system. The structure is the audit trail.

OKF: the frontmatter is the trust

Google’s Open Knowledge Format starts from the same primitive, markdown files with YAML frontmatter in a directory, and spends its design budget somewhere else entirely. Where ICM structures the process, OKF structures belief. The frontmatter is not decoration. It is a set of queryable fields about whether you should trust the file. Where the concept came from, with per-source credibility signals. Who produced it and who confirmed it, in generated and verified. When it goes stale, in stale_after. From those signals it derives a trust tier.

That is the move a bank cannot look away from. OKF treats provenance and freshness as first-class, machine-readable metadata. It is lineage and a freshness SLA, written in a format you can grep. And it is deliberately a format and not a platform. Vendor-neutral, with no proprietary account required to read, write, or serve it.

So the two are not rivals. ICM is the workflow spine, how an agent acts. OKF is the trust spine, what an agent knows and whether to believe it. Karpathy’s gist is the seed both grew from. Stack them and you have most of what a regulated knowledge base needs: a visible process and a defensible belief state, both in plain text.

Why a bank should care about the shape, not the tool

When a model-risk reviewer or an examiner looks at an AI system, they do not ask which vector database you picked. They ask a smaller and harder set of questions. Where did this answer come from. Who approved that source. When was it last confirmed. Who could have changed it, and is there a record. Can you reproduce the exact state the model saw on the day it made a decision.

Read that list again and notice that every question is about metadata the contract already carries.

• Lineage. OKF’s source fields say where a concept came from. ICM’s folder path says which stage produced it. Both are readable without running anything.
• Freshness. stale_after turns “is this still true” into a date a job can check, not a judgment call a human forgets to make.
• Human sign-off. The verified field records who confirmed a file. ICM’s per-stage review records that a human looked before the workflow moved on.
• Access and change control. Git history plus the repository permissions you already run decide who can read and write which part of the corpus.
• Reproducibility. A git commit is the exact state of the knowledge on a given day. You can check it out and see what the model saw.

None of this requires a new product. A vector store gives you retrieval and a similarity score. It does not give you a diff, a blame log, or a reviewer’s name. Plain text in git gives you all three for nothing, because that is what git was built to do. The knowledge base becomes reviewable by the same tools and the same people who already review your code. I walked through why capture-and-retrieval systems keep failing this test in Context Engineering Is Infrastructure, Not a Skill. The short version is that the fix was never a richer schema. It was a poorer one, kept somewhere you already have controls.

The contract, written down

Strip both projects to what they agree on and you get something you could hand to an architecture review board. Six clauses.

• The source of record is versioned text. Not a row in a managed service you cannot diff. A file, in a repo, with a history.
• Provenance is a field, not a footnote. Where a fact came from travels with the fact, in the frontmatter, queryable.
• Freshness is an SLA, not a vibe. Every concept carries an expiry. Past it, the system flags or quarantines rather than quietly serving a stale answer.
• Trust is derived, not asserted. The trust tier is computed from provenance and verification signals, not a green checkmark somebody clicked once and forgot.
• The path is the audit trail. Where a file lives and how it changed tells the whole story, with no separate logging layer to keep in sync.
• Every change compiles. An ingest or an edit runs through a step that re-links, re-summarizes, and re-stamps the metadata. That step is where your controls live.

Read the six again and notice what is missing. Not one of them names a vendor. That is the feature, not an omission.

Building it on infrastructure you already govern

Here is the reference deployment, and the whole point of it is how little is new. Everything below maps to a service a regulated engineering org already runs on Azure or AWS.

• Source of record: a git repo you already operate. GitHub Enterprise, Azure DevOps, whatever your org standardized on. Raw sources, the wiki, and the schema all live there. Branch protection and pull requests are your change control, unchanged.
• Immutable sources: object storage with a retention lock. S3 Object Lock, or Azure Blob immutability. The originals cannot be quietly rewritten, which is the entire reason you get to call them ground truth.
• The compile step: your existing CI. A commit triggers a job that re-links the wiki, regenerates summaries, and stamps generated, verified, and stale_after. That job is also where DLP, PII scanning, and data classification run on the way in. The compile gate is your control plane, and you already know how to reason about a CI pipeline.
• Access: the IAM you already run. Repository permissions and object-storage policies decide who reads and writes which part of the corpus. No new identity system, no fresh set of grants to model from scratch.
• Audit: the logs you already keep. Who changed what, when, and who approved the merge is captured by git and cloud activity logging your auditors already trust.
• Freshness: a scheduled job. It reads stale_after and flags or quarantines anything past its date, the same way a certificate-expiry monitor works today.

Nothing in that list is a managed knowledge catalog. Nothing hands your knowledge to a third party’s control plane, and nothing leaves the tenant. For a bank, that last sentence is worth more than any feature a vendor could bolt on. You are not buying a knowledge platform. You are pointing tools you already govern at a folder.

The part I won’t pretend away

This is a semantic layer, not a database. Markdown in git is where meaning, context, and decisions belong. It is not where a billion transaction rows belong, and pretending otherwise is how you end up with a repository nobody can clone. OKF itself is built to sit next to a data catalog, not to replace one. Keep the warehouse. This is the layer that explains the warehouse to an agent.

The maintenance promise has a catch, and it is the one a regulator will push on hardest. “The model does the bookkeeping” is true, and a model that rewrites fifteen files in one pass can also propagate a single wrong inference into fifteen files just as fast. In a regulated context the human in the loop is not politeness. It is the control. ICM’s per-stage review and OKF’s verified field are not friction to optimize away. They are the reason the thing is auditable at all.

And it can rot in new ways. Graphs drift, links go stale, two people model the same concept twice, and the schema grows until no one reads it. The failure mode moves from “nobody updates the wiki” to “the wiki updates faster than anyone reviews it.” That is a better problem to have. It is still a problem, and the discipline it demands, a small schema, tight review, ruthless pruning, is exactly the discipline most teams are worst at.

The knowledge base is a folder

The knowledge base you have been told to buy is a folder. That has been true since the gist, and the wave of the last few months only confirmed it. The projects will keep coming, and most of them will be point tools that solve the compile step and little else.

The ones worth reading are the ones that wrote down a contract: a visible process and a defensible belief state, both in text you control. Steal the contract. Skip the catalog. Then implement it with the boring, governed, already-audited infrastructure sitting in your cloud account right now, because in a regulated shop the boring infrastructure is the whole advantage.

The team that wins the agent era is not the one with the best vector database. It is the one whose knowledge a regulator can read.

---

The companion read is Markdown Is the Knowledge Layer, where I argued this pattern was inevitable before the field caught up. For the longer history of why capture-and-retrieval systems keep failing, see Context Engineering Is Infrastructure, Not a Skill.

I write about AI-assisted development, enterprise architecture, and building in regulated environments. If you are standing up a knowledge layer under real compliance pressure, I would like to compare notes. Find me on X @orestesgarcia or LinkedIn /in/setsero.