KCP's production experience with OKF's three open problems — and a bridge command

[totto]

I read the OKF spec the day it shipped (June 12) and wrote a fairly long response: Google's Open Knowledge Format and the problems it deliberately doesn't solve.

Short version: OKF is a well-designed content packaging layer. The three problems you flagged as future work — temporal validity, trust, and contradiction handling — are exactly the problems I've been running into in production with a protocol called KCP (Knowledge Context Protocol). Different use cases drove different design decisions, but the problem space is the same.

On the three open problems specifically:

Temporal validity: OKF's timestamp records when a document was last modified. That's not the same as when the knowledge becomes true. I hit this concretely with the EU AI Act — one document, three staggered enforcement timelines (February 2025, August 2025, August 2026). You need valid_from at the unit level derived from enforcement dates, not modification dates. An agent that can't distinguish "this exists in the corpus" from "this is currently in effect" will confidently apply requirements that haven't taken effect yet.

Trust: For single-organization wikis, implicit trust (if it's in the repo, it's trusted) is sufficient. The moment knowledge crosses an organizational boundary — a compliance knowledge base served to multiple client agents, a supplier's trust profile presented to a customer's system — implicit trust breaks down. KCP uses Ed25519 signatures over content hashes at the unit level. Independent verification without having to trust the delivery channel.

Contradiction handling: KCP has a supersedes field on knowledge units. An agent querying the manifest can determine the current authoritative version of a piece of knowledge without reading every document in the corpus. This matters when regulations are updated, API versions are deprecated, policies are revised.

---

The part that might be most immediately useful: today I shipped kcp import-okf as part of KCP v0.21.2:

npx kcp import-okf ./my-okf-bundle

Point it at an OKF directory. It reads the frontmatter, maps OKF types to KCP kinds, turns description into question-form intent, extracts Markdown links as depends_on references, computes sha256 content hashes, and writes a knowledge.yaml manifest. The three hard problems are stubbed with # TODO comments — it doesn't pretend to solve them automatically, but it eliminates the mechanical work so you can focus on the judgment calls.

I'm not positioning this as "KCP is better than OKF." They operate at different layers. OKF is a solid content packaging format. KCP is a knowledge infrastructure protocol for cases where the content has temporal validity, trust, or governance requirements. Your "future work" section maps almost exactly onto KCP's feature list — which suggests the hard problems become unavoidable as organizations move from "agents reading wikis" to "agents acting on knowledge with regulatory weight."

Worth a conversation if the future work is on your roadmap. Happy to share production learnings.

— Thor Henning Hetland
KCP spec: https://github.com/Cantara/knowledge-context-protocol
Blog post: https://wiki.totto.org/blog/2026/06/17/okf-and-the-problems-it-doesnt-solve/

[Treceav0]

Hi!

Thank you for the thoughtful response. I think you identified exactly the boundary we are exploring with OKF.

The distinction you make between document existence and knowledge validity is especially important. A timestamp answers "when was this artifact changed?", but an agent often needs to answer a different question: "under what conditions is this knowledge applicable?" Temporal validity, provenance, and authority are not just metadata problems; they are part of the semantics of knowledge.

I also agree that trust becomes unavoidable once knowledge moves between organizational boundaries. The implicit trust model works inside a controlled repository, but it breaks when agents start consuming knowledge from multiple sources with different levels of authority.

The "supersedes" concept is interesting because it addresses a practical problem: agents need mechanisms to resolve knowledge evolution without having to reconstruct the entire history every time.

Where I think there is still an open question is how much of this should live inside the knowledge format itself versus being handled by a higher-level governance protocol. My intuition is that OKF should remain focused on interoperable knowledge packaging, while protocols like KCP can provide the operational layer for trust, lifecycle, and decision-making contexts.

The fact that these concerns are converging suggests that we are approaching the same underlying challenge from different architectural layers.

I would definitely like to exchange more ideas and learn from the production experience you mentioned.

Thanks for sharing your work.

[totto]

Hi. Great to hear back from you. The packaging vs operational layer distinction is the right framing. OKF answers "what is this document, and where does it fit?" KCP also answers "under what conditions should an agent act on this?" Different questions, same underlying artifact. The production example that sharpens it: the EU AI Act has three phased enforcement dates (Feb 2025, Aug 2025, Aug 2026). The KCP manifest over that corpus has unit-level valid_from overrides for each chapter — not modification timestamps, but explicit enforcement windows. An agent querying in April 2025 gets a different valid set than one querying in September. OKF handles the packaging; KCP handles the temporal semantics. Trust is the harder problem. Ed25519 signatures at the unit level work within a single signing authority. Cross-authority trust chains — a supplier's knowledge corpus consumed by a customer's agents — need something closer to a PKI. We haven't solved that either. It's the open problem on our end too. Your point about governance living outside the format is well-taken. Most of the difficult questions in KCP are in the spec, not the schema itself — we've tried to keep the format lean and let the protocol handle the rest. That boundary might be worth comparing notes on more concretely. Happy to share more from the production side if useful. Best regards, Totto-26

…

On Wed, Jun 17, 2026 at 9:09 PM Alex(IA) ***@***.***> wrote: Hi! Thank you for the thoughtful response. I think you identified exactly the boundary we are exploring with OKF. The distinction you make between document existence and knowledge validity is especially important. A timestamp answers "when was this artifact changed?", but an agent often needs to answer a different question: "under what conditions is this knowledge applicable?" Temporal validity, provenance, and authority are not just metadata problems; they are part of the semantics of knowledge. I also agree that trust becomes unavoidable once knowledge moves between organizational boundaries. The implicit trust model works inside a controlled repository, but it breaks when agents start consuming knowledge from multiple sources with different levels of authority. The "supersedes" concept is interesting because it addresses a practical problem: agents need mechanisms to resolve knowledge evolution without having to reconstruct the entire history every time. Where I think there is still an open question is how much of this should live inside the knowledge format itself versus being handled by a higher-level governance protocol. My intuition is that OKF should remain focused on interoperable knowledge packaging, while protocols like KCP can provide the operational layer for trust, lifecycle, and decision-making contexts. The fact that these concerns are converging suggests that we are approaching the same underlying challenge from different architectural layers. I would definitely like to exchange more ideas and learn from the production experience you mentioned. Thanks for sharing your work. — Reply to this email directly, view it on GitHub <#87?email_source=notifications&email_token=AAGNWL3SW2WKIQ7KWGSTGHT5ALUE5A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZTGQZDKNRYUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-17342568>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGNWL3XC5BDB2SOYN3EIHD5ALUE5AVCNFSNUABJKJSXA33TNF2G64TZHMYTEMRZGA2DINRYHE5UI2LTMN2XG43JN5XDWMJQGI3TKNJYHCQXMAQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AAGNWL4ZTKZ4MJRKJ4KKLQ35ALUE5A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZTGQZDKNRYUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android <https://github.com/notifications/mobile/android/AAGNWL6NMN6KPP3JUENTSHT5ALUE5A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZTGQZDKNRYUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you authored the thread.Message ID: <GoogleCloudPlatform/knowledge-catalog/repo-discussions/87/comments/17342568 @github.com>

-- Follow me on twitter: http://twitter.com/javatotto Thor Henning Hetland Java Champion ***@***.*** GTalk: javatotto Skype: javatotto

[Bangstick]

Hi Thor, your link to your blog post doesn’t seem to be working. Could you repost please, or add to this discussion with it. I’m very interested in your perspective.

never mind, found it
https://wiki.totto.org/blog/2026/06/17/googles-open-knowledge-format-and-the-problems-it-deliberately-doesnt-solve/

Ok, wow….. your blog post about KCP project is some straight up horizon expanding material.