Knowledge Systems · Tech Auditor Goes Deep

Google Released a Standard for AI Knowledge Bases.
I Adopted It Then Extended It.

June 2026 · Scott Curtner CIA® CISA® AAIA™ — In Progress ITIL® 4

It happened on a Sunday. I was mid-session with Claude — not looking for anything in particular, just following a thread — when the system did something I hadn't asked it to do.

I had been running an AI-assisted knowledge base for months. Pages and pages of personal reference material: professional context, project state, domain notes, running logs. The system knew my work, my properties, my open tasks. It loaded the right context at the right moment without me having to explain anything. By any measure, it was working.

What happened that Sunday wasn't a failure. It was something subtler. I watched the system synthesize an answer from two documents I recognized — and one of the underlying facts, something I had written down months earlier and never revisited, was no longer accurate. The system had no way to know that. It answered with complete confidence from a document that was technically still there, still formatted correctly, still loading as expected.

The document wasn't broken. It was stale.

I sat with that for a moment. I had built a system to give an AI agent accurate, synthesized context on demand. I had optimized for capture and retrieval. I had not built anything that could tell me — or the agent — which parts of that context were still true.

The audit instinct kicks in at moments like this. I've spent enough time in technology audit to know what the difference between a control and a hope looks like in practice. A knowledge base that grows faithfully but has no mechanism for detecting staleness is not a controlled system. It's a very organized hope.

The records are clean. The retrieval works. But nobody has checked whether the underlying facts are still facts.

I've written about the executor/validator pattern before — the idea that you don't let the system that runs a process also certify that the process ran correctly.¹ The same principle applies here, one level up. An AI agent reading a knowledge base cannot audit its own source material. It can only work with what it finds. If what it finds is wrong, the answer will be wrong, delivered with the same confidence as if it were right.

That's the failure mode. Not a dramatic crash. Not an obvious error. Just a well-structured system answering fluently from outdated material, at the exact moment someone needs to rely on it.

I started thinking through what a freshness layer would actually require. Not a philosophical commitment to keeping things current — I already had that, which is how I noticed the problem in the first place. A mechanism. Something structural that makes staleness detectable, reviewable, and recorded.

The first thing I needed was a better relationship with time.

A knowledge base typically tracks one date per document: when the content last changed. That timestamp is useful, but it answers the wrong question. Age tells you when something was touched. It doesn't tell you whether anyone has verified it is still accurate.

Those are two different facts, and collapsing them into one field creates a problem. An old document that has been reviewed and confirmed is fundamentally different from an old document that nobody has looked at in eight months. With a single timestamp, you can't tell them apart. You end up either treating all old documents as suspect (which trains you to ignore the signal, since most old documents are fine) or routinely bumping the date without genuine review (which quietly converts "verified current" into "someone touched this recently," draining the signal of meaning).

The fix is a second date field. Not a replacement — an addition. One field for when the content last changed. A second for when a human last confirmed that content is still accurate. The gap between them becomes the signal that matters.

I was still working through what this layer should look like when a format dropped into my awareness that gave it a name and a structure.

On June 12, 2026, Google Cloud released the Open Knowledge Format — OKF.² The specification is deliberately minimal: a directory of Markdown files, each carrying a YAML frontmatter block, readable by any AI agent without proprietary tooling or a database layer. A root-level file acts as the behavioral contract for any agent reading the directory. The only strictly required field is a document type. Everything else is optional or extensible.

OKF had emerged from a real pattern. Andrej Karpathy's "LLM wiki" convention had been circulating since April — the idea of keeping a plain-text document that told an AI assistant who you were and what context it needed.³ The AGENTS.md and CLAUDE.md patterns had spread across open-source repositories. Practitioners building personal knowledge systems had converged independently on the same shape: Markdown, frontmatter, Git, a root instruction file. OKF looked at that convergence and wrote down the common denominator.

What it does not specify is the knowledge lifecycle. OKF includes an optional updated timestamp field — one date, content modification only. There is no native field for human verification. No protocol for scheduled review. No per-document instruction about how to evaluate whether content has gone stale.

This is the correct design choice. A standard that ships a clean, small core is more useful than one that waits for consensus on every possible extension. And the silence on lifecycle is exactly where practitioners should extend. OKF's own architecture invites it — frontmatter extensions that a conformant reader ignores gracefully are precisely how the format was designed to grow.

What I had been working out on paper was OKF's missing layer.

The freshness layer, in three pieces

The two-date model is the foundation. Two fields in every document's frontmatter: updated for content modification, verified for last human confirmation. The gap between them is the primary freshness signal. A document where verified sits far behind updated has been changed but never checked — one risk profile. A document that is old but has been regularly confirmed is a different thing entirely.

There is one invariant riding on top of this: verified should never be older than updated. The act of verifying is itself an event that moves the clock forward. This invariant is treated as a checked condition, not an assumed one — which is the entire point. The difference between "we assume this holds" and "we verify it holds" is the difference between a control and a hope.

The second piece is scheduled review. A weekly pass, triggered by a simple phrase, surfaces documents in order of oldest verified date first. For each one: confirm it's still accurate and update the field, correct the content if something has changed, consciously defer with a reason and a new target date, or flag for archival. The cadence is weekly rather than threshold-based because threshold-based staleness creates reactive behavior — nothing happens until the flag trips. A weekly habit keeps the queue short and matches the rhythm of how most practitioners track what's changed in their domains.

The third piece is the one that took the most thought: per-document review contracts. Not all documents should be reviewed the same way. A factual reference needs "is this still accurate?" A status document needs "does this reflect current state?" A process document needs "do these instructions match how the process actually runs?" A journal or memoir-style document doesn't rot in the same way — its failure mode isn't becoming wrong, it's becoming incomplete. That calls for a generative approach: read what's there, identify threads, ask a question designed to elicit addition.

The review contract lives in a dedicated frontmatter block and encodes the per-document logic directly — how often to review, what mode of review applies, and what to focus on. The document itself stays clean prose. The intelligence about how to evaluate it stays in the contract.

The Sunday discovery wasn't a crisis. It was a calibration. A system that had been working well surfaced the next problem it needed to solve, at the moment I was present enough to see it.

I've been thinking about that pattern in other contexts. The systems worth building aren't the ones that never surface problems. They're the ones that surface problems early, when fixing them is still inexpensive. A knowledge base that flags its own staleness before an agent relies on outdated material is doing exactly that.

What I'm working toward — and haven't fully closed — is the question of what good governance infrastructure looks like when AI agents are reading and acting on knowledge at a cadence no human can match. The freshness layer described here is a start. It keeps the human in the loop where judgment belongs. It makes the knowledge base auditable. It treats "is this still true?" as a real question with a real answer, not a background assumption that something is handling somewhere.⁴

I don't think that's a solved problem yet. I think it's where the interesting work is.