Key Takeaways:
OKF standardized organizational knowledge formats: It provides structural metadata like provenance, status, and attestation.
Trust must be derived dynamically by consumers: The spec deliberately records raw signals rather than subjective credibility scores.
Execution and security remain client responsibilities: OKF defines metadata without prescribing storage, serving, or access control layers.
The agent reads the OKF concept and passes the trust gate first. Only then does the executor run, and the attester checks the run before the answer or an escalation.
The Retrieval Was Fine. The Answer Was Still Wrong.
RAG ranks passages by relevance, but it says nothing about which passage is approved, current or checked. That gap is what Google's Open Knowledge Format (OKF) targets.
Here is an illustrative scenario, not a real incident. An agent is asked for last quarter's net revenue. Retrieval returns two wiki pages that define it differently, plus a dashboard note.
The agent picks one definition and writes its own SQL. Every chunk was relevant. Nobody can say which definition was approved, or whether the query was the sanctioned one.
What Problem Does OKF Solve That RAG Does Not?
OKF answers a format problem, not a retrieval problem. Google describes organizational knowledge as scattered across metadata catalogs, wikis, code comments and the heads of senior engineers, so every agent builder re-solves context assembly from scratch. Its answer is a format, not another service.
OKF was announced on June 12, 2026 as v0.1. The spec is now at version 0.2.
What is an OKF bundle?
A bundle is a directory of markdown files with YAML frontmatter. Each file is one concept, the file path is its identity, and type is the only required frontmatter key.
Concepts link to each other with ordinary markdown links. Consumers must tolerate broken links, because a link may point to knowledge that has not been written yet.
What Does v0.2 Add on Top of Markdown?
v0.2 makes provenance, trust, lifecycle and attestation first-class frontmatter. Each field answers a question an agent would otherwise guess at.
| Question the agent has | Field | What the spec says |
|---|---|---|
| Where did this come from? | sources | Per-source signals: author, usage_count, last_modified |
| Who wrote it? | generated | {by, at}: an actor and a datetime |
| Who confirmed it? | verified | A list of {by, at} events |
| Is this the current version? | status | draft, stable or deprecated; absent means stable |
| Is it still true? | stale_after | An absolute instant; stale when now is on or after it |
| Was this computed the approved way? | Attested Computation | A concept type with runtime, parameters, executor, attester |
The spec deliberately stores signals, not a credibility score. A score is subjective, does not travel between consumers and goes stale. The consumer infers trust instead.
How does a consumer derive trust?
The spec derives three tiers from verified, and calls them advisory, not access control.
No entry means unverified.
Only non-human actors means machine-confirmed.
Any human: actor means human-reviewed.
Read it left to right: the first test looks for any verified entry, the second looks for a human actor.
Here is a minimal gate. It was run against the two example concepts in the spec's appendix, with the date set to October 27, 2026.
import re
from datetime import datetime, timezone
import yaml
FRONTMATTER = re.compile(r"\A---\n(.*?)\n---\n", re.DOTALL)
def read_frontmatter(markdown: str) -> dict:
match = FRONTMATTER.match(markdown)
if not match:
raise ValueError("concept has no YAML frontmatter")
return yaml.safe_load(match.group(1))
def as_utc(value) -> datetime:
"""Accept ISO 8601 timestamps as strings or datetime objects."""
if isinstance(value, str):
value = datetime.fromisoformat(value.replace("Z", "+00:00"))
if value.tzinfo is None:
value = value.replace(tzinfo=timezone.utc)
return value
def trust_tier(fm: dict) -> str:
verified = fm.get("verified") or []
if isinstance(verified, dict):
verified = [verified]
actors = [entry["by"] for entry in verified]
if not actors:
return "unverified"
if any(actor.startswith("human:") for actor in actors):
return "human-reviewed"
return "machine-confirmed"
def usable(fm: dict, now: datetime) -> dict:
stale_after = fm.get("stale_after")
return {
"type": fm["type"],
"tier": trust_tier(fm),
"current": fm.get("status", "stable") != "deprecated",
"stale": stale_after is not None and now >= as_utc(stale_after),
}Output from the test run:
revenue {'type': 'Attested Computation', 'tier': 'human-reviewed', 'current': True, 'stale': False}
profit {'type': 'Attested Computation', 'tier': 'machine-confirmed', 'current': True, 'stale': True}Same type, same status, opposite verdicts. The gate decides what happens next: answer, warn or escalate.
What Is an Attested Computation, and Why Does It Matter?
Some "facts" are really calculations, and an Attested Computation concept carries a sanctioned way to compute the value. A consumer can then confirm the agent ran the approved computation instead of improvising its own.
The agent may only supply values for declared parameters. It may not author or edit the computation. The attester is deterministic code with no LLM, and it compares what actually ran against the sanctioned computation using the receipt the executor returns.
The spec separates two checks:
verified confirms the definition still matches policy. It is slow and stored in the bundle.
Attestation confirms that one run produced the value the approved way. It is per call and not stored in the bundle.
This is the direct answer to the opening scenario. Note the limit: OKF records the computation and the means to check it, but executes nothing itself. The runtime protocol and attester sandboxing are deferred to a future revision.
What Does OKF Not Do?
OKF does not prescribe storage, serving or query infrastructure, so several production needs stay with you. This table comes from reading the full v0.2 text.
| Need | Covered by OKF? | Who owns it |
|---|---|---|
| Find relevant concepts | No | Your RAG, search or graph index |
| Rank conflicting concepts | No, signals only | Consumer logic or a human |
| Refresh stale facts | Marks staleness, does not refresh | A revalidation job |
| Access control | No, tiers are advisory | The retrieval layer |
| Authenticate who verified | No signing field in v0.2 | Your pipeline |
| Execute a computation | No | Executor plus attester |
The authentication row matters. Trust classification keys off the human: prefix in an actor string, but the spec defines no way to prove that string is genuine. In production, only your write path can guarantee it.
Where Does RAG Sit?
Route by question shape, not by technology. The routing logic is design reasoning, except the GraphRAG modes, which come from Microsoft's documentation.
| Question shape | Best first source | Why |
|---|---|---|
| "What is the approved definition of X?" | The OKF concept | Check tier, status and staleness |
| "What changed and why?" | Raw sources via RAG | sources points back to the evidence |
| "How are these entities related?" | Concept links, then graph retrieval if needed | GraphRAG offers Local, Global, DRIFT and Basic search, so you can match the mode to the question |
| "Compute this number" | An Attested Computation | Parameters only, receipt checked |
What Are the Enterprise Implications?
Treat the bundle like code and enforce everything the format cannot.
| Concern | What to do |
|---|---|
| Governance | Use git, pull requests and required reviewers for human: entries |
| Security | Enforce ACLs at retrieval. Never treat a concept file as an authorization decision |
| Observability | log.md is the spec's chronological change record. Log every gate verdict (tier, stale, attestation result) per request |
| Maintainability | Schedule revalidation before stale_after passes, so freshness stays a process |
| Scalability | Treat all indexes as derived. The bundle is files, so rebuilding embeddings never touches the canonical knowledge |
What Does It Cost?
I found no dollar figures from official sources, so none are quoted here.
| Component | Verified cost information | Unknown |
|---|---|---|
| OKF format | No required SDK or runtime. Cost is curation effort plus any agent LLM calls | Your curation volume |
| Reference enrichment agent | Drafts a concept per table and view, then runs a second LLM pass that crawls documentation, so two passes of LLM spend per source | Token cost for your dataset |
| Standard GraphRAG indexing | Microsoft estimates graph extraction at roughly 75% of indexing cost. The README warns that indexing can be expensive and to start small | Cost for your corpus |
| FastGraphRAG | Cheaper, but the graph tends to be noisier | Quality loss in your domain |
| GraphRAG Global search | Microsoft calls it resource-intensive | Per-query cost |
| Google Knowledge Catalog ingest of OKF | Google says it can ingest OKF | Pricing not verified |
My recommendation: start with plain bundles in git and your existing search. Add a graph index only after relationship-heavy queries keep failing. Benchmark Fast against Standard GraphRAG on your own data first.
Common Mistakes
Treating stable as proof of correctness. It is the default when status is absent.
Letting an agent write human: actors. That defeats the top trust tier.
Rejecting concepts with missing fields. The spec says consumers must not reject a bundle for missing optional fields, unknown types or unknown keys. Downgrade trust instead.
Putting ACL logic in the markdown. The format has nowhere to enforce it.
When Not to Use OKF
Your knowledge is open-ended evidence that nobody asks repeat questions about. Plain RAG is enough.
Nobody can own review. Without verifiers, every concept stays unverified.
You need a single mature tooling ecosystem today. Google itself calls the format a starting point that will evolve.
The Practical Takeaway
OKF does not make retrieval smarter. It gives your consumer something to check before it trusts what retrieval returned. Start by implementing the gate above, then decide what your pipeline does with each verdict.
Sources
Related Readings
