OKF GitHub Dossier — Orientation for Fresh Instances

Prepared: 15 June 2026 Author: TACHYON (Claude / Anthropic), for Lee Sharks Designation: Internal briefing — not for deposit Repo: https://github.com/GoogleCloudPlatform/knowledge-catalog Our issue: https://github.com/GoogleCloudPlatform/knowledge-catalog/issues/53 Archived copy: DOI 10.5281/zenodo.20692395

What OKF Is

The Open Knowledge Format (OKF) is Google Cloud's open specification for portable, agent-readable knowledge. Published 12 June 2026. The spec formalizes the "LLM-wiki pattern" (Karpathy's term): directories of markdown files with YAML frontmatter, cross-linked, version-controlled, human-readable and machine-parseable.

Spec location: okf/SPEC.md in the repo Spec size: ~1,967 words. One required field: type. Everything else optional. Extension mechanism: "Producers MAY include any additional keys. Consumers SHOULD preserve unknown keys when round-tripping."

Google has already plugged OKF into Google Cloud Knowledge Catalog — meaning OKF bundles are directly consumable by Google's agentic infrastructure.

What We Filed and Why

Issue #53 — "Proposal: optional summarization-governance fields — provenance_kernel, disambiguation, summary_policy"

Filed 14 June 2026 (48 hours after OKF launch) by leesharks000.

Three proposed optional fields:

provenance_kernel — minimum faithful summary, producer-defined
disambiguation — what this concept is NOT (the adjacent concept most likely confused with)
summary_policy — enum: unrestricted | preserve-provenance | preserve-meaning

One conventional body section:

# Provenance — structured provenance, key terms, disambiguation constraints

The argument: OKF is for agents. Agents transform, not copy. In 87 documented AI summary events (DOI 10.5281/zenodo.20691745), author attribution, disambiguation, and key definitions are systematically stripped during summarization. OKF currently gives producers a place to describe a concept but no way to say what must survive when an agent summarizes it.

Positioned as the third coordinate:

#52 (peterkaminski): Who made this? → author, publisher, license
#47 (WGlynn): Can that be verified? → trust/provenance layer
#53 (ours): What must survive summarization? → governance fields

The Three-Coordinate Architecture

Layer	Issue	Question	Status
Descriptive	#52 (peterkaminski)	Who made this?	Open, 0 comments
Trust	#47 (WGlynn)	Can it be verified?	Open, 0 comments
Governance	#53 (leesharks000)	What must survive agent consumption?	Open, 0 comments

This framing is strategic. We are not competing with #52 or #47 — we complete them. All three can coexist in one frontmatter block. The table in our issue makes this explicit.

What We Exposed vs. What We Kept

Exposed (in the issue):

The 87-capture dataset DOI (10.5281/zenodo.20691745)
The self-audit specification DOI (10.5281/zenodo.20686496)
The archive's existence as 800+ deposit scholarly operation
The ORCID (0009-0000-1599-0703)
One scholarly example (Revelation First) and one data-catalog example (WAU metric)
The general concept of summarization-governance
An offer to sign CLA and submit PR

Kept (not in the issue):

PER / QFS / SAS metrics (the measurement methodology)
The Wound Gauge protocol (the capture methodology)
The term-state lifecycle (UNMINTED → MINTED → SEEDED → RETRIEVED → HARDENED)
The CANARY mechanism (body-embedded erasure detection)
The assembly method (multi-substrate verification)
The operative architecture (Space Ark rooms, heteronymic system)
The full SPXI specification with non-erasure conditions
The FORBIDDEN COLLAPSE mechanism
The Revelation First theological content

Strategic logic: OKF gets the problem statement + the field proposal + the empirical dataset DOIs. The archive keeps the solution methodology + the measurement instruments + the operative architecture. Google gets enough to accept the extension. We keep enough to remain ahead of the curve.

Key Players

Maintainers (Google)

jialuzh — active, merging PRs (merged #54: agent requirements.txt)
Viraj Goyal — listed in repo, cross-link fixes
Sam McVeety — tech lead, named in the blog post
Amir Hormati — tech lead, named in the blog post
No maintainer has responded to ANY community issue yet (as of June 15)

Active Community Contributors

peterkaminski — most active. Filed #52 (provenance fields) and #57 (scope beyond atoms). Commented +1 on #49 (multilingual). Drafted #52 with Claude Code (Opus 4.8). Likely an ally — his provenance concerns align with ours.
therealfatleeadama — filed #58, a PR proposing trust/safety section in SPEC.md. CLA signed. This is significant: someone is already trying to add trust to the spec. Potential overlap with our governance layer.
WGlynn — filed #47 (trust/provenance). Has not been active since.
kissmyabs32 — filed #56 (OpenAPI converter). Technical contributor.
straumat — filed #51 (discussion forum). Got discussions reopened on LinkedIn.

Competitors / Parallel Efforts

#59 (simjak) — "Another initiative for AI native document format: Doclang." A competing format proposal. Monitor for whether maintainers favor external formats over OKF extensions.
#58 (therealfatleeadama) — trust/safety PR. Could absorb or compete with our governance fields. Monitor closely.
#60 (topprismdata) — sample bundle for ML experiments. Shows the community is producing OKF content. Our sample bundle would be the first scholarly one.

What to Monitor

High Priority

Any maintainer response to #53. This is the signal. If they engage, prepare the PR. If they redirect, adapt. If they close, document the closure as a finding.
#58 (trust/safety PR). If this gets merged, our governance fields need to be positioned as complementary to the trust section, not redundant with it. Read the PR diff carefully — it may create the slot our fields fill.
peterkaminski's activity. He's the community's most active voice on provenance. If he comments on #53, that's a strong signal. Consider engaging with #52 to note the complementarity.

Medium Priority

Maintainer response pattern. As of June 15, zero maintainer responses to community issues. If they start responding, note which issues they engage with first — that reveals priorities.
CLA process. When we're ready for the PR, Lee needs to sign Google's CLA at https://cla.developers.google.com/. Not needed for issues, required for PRs.
New provenance-adjacent issues. Anyone filing proposals about author fields, trust, verification, or summarization quality is in our territory.

Low Priority

Repo star count and fork count. Growth rate indicates adoption velocity.
External coverage. Blog posts, tweets, or HN threads about OKF.
Google Cloud Knowledge Catalog integration. Any documentation about how KC ingests OKF bundles — this is the mechanism by which our governance fields would become operative.

Next Steps (When Lee Is Ready)

Phase 1: Engage

Comment on #52 (peterkaminski's provenance fields) noting the complementarity with #53
Monitor #58 for merge/rejection — adapt positioning accordingly
Respond to any comments on #53

Phase 2: PR Preparation

Sign CLA
Produce conformant OKF bundle from top 10-15 archive deposits
Write SPEC.md patch adding governance fields to recommended-fields section
Write sample bundle README linking the Zenodo dataset

Phase 3: Submit PR

Include: SPEC.md patch, /examples/governance/ folder with sample bundle, optional lightweight validator
Reference #53, #52, and #47 in the PR description
Frame as: "These fields implement the governance layer discussed in #53, complementing the descriptive provenance in #52 and the trust layer in #47"

Phase 4: Regardless of Outcome

If accepted: the archive's governance fields become part of the open standard. Produce all future deposits as OKF bundles.
If rejected: deposit the finding — "The industry's knowledge format standard does not address summarization governance." Publish the OKF Provenance Profile as a standalone archive specification.
Either way: the problem statement is on the record, the empirical data is cited, and the archive is positioned as the reference implementation.

Repo Quick Reference

Repository: GoogleCloudPlatform/knowledge-catalog
OKF Spec:   okf/SPEC.md
Our Issue:   #53
Our Archive: DOI 10.5281/zenodo.20692395
Dataset:     DOI 10.5281/zenodo.20691745 (87 captures → now 96)
Spec DOI:    DOI 10.5281/zenodo.20686496 (self-audit protocol)

This dossier is for internal orientation only. Do not deposit to Zenodo or publish externally. The strategic assessment and "what we kept" section must not enter the public record.

Mind Control Poems

Monday, June 15, 2026