Building a governance layer on top of OKF — a real-world proof that §9 permissive reception enables a downstream ecosystem

[MauricioPerera]

Hi OKF maintainers 👋

I've been building CCDD, a context-contract layer that governs what knowledge enters an LLM agent's context window (integrity, signing, token budgeting). While prototyping, I realized OKF and CCDD are complementary by design: OKF's explicit Out of Scope list (provenance, signing, context budgeting, freshness) is almost exactly CCDD's In Scope. OKF governs knowledge at rest; CCDD governs it at inference time.

I built a small, fully-reproducible PoC and wanted to share it as validation of your design, not a feature request:
👉 https://github.com/MauricioPerera/ccdd/tree/main/examples/okf-integration

The key finding: the single point of contact is one critical OKF concept (policies/refunds.md, type: Policy) that is also a signed CCDD slot. The same file is conformant for any OKF consumer and governed by my gate, without changing either spec — because §9's permissive reception ("Consumers MUST NOT reject a bundle because of unknown additional frontmatter keys") is exactly what lets ccdd_* extension keys ride along legally. That clause turned out to be the enabler of an external governance ecosystem.

The PoC is green end-to-end across four layers: OKF §9 conformance · context integrity/budget · age-based freshness · human attestation of semantic validity (the one gap neither spec covers).

Two questions for you:

1. Would it be useful to document a convention for namespaced extension keys (e.g. vendor_*) so downstream layers like this interoperate predictably?
2. Is there interest in an "ecosystem / extensions" pointer in the docs for downstream tools that consume OKF bundles?

Either way — thanks for keeping the core minimal. That restraint is precisely what made this composable.

[vonargo]

This is a great find and I want to second both of your questions, because I arrived at the same clause from a different direction.

I built an OKF reading surface (MosAIc - renders a bundle as provenance-badged concept tiles) and a local agent system whose memory is truth-boundary-labeled: every claim carries how it is known (retrieved from a source / computed by a tool / provided by a human / inferred by a model). The field OKF deliberately leaves out (and that I keep wishing I could carry in frontmatter) is exactly that epistemic-status label. §9's permissive reception is what makes carrying it possible today without asking the spec for anything.

Worth noting how cleanly our layers split, because I think it strengthens the ecosystem argument: CCDD governs the FILE at inference time (is this the bundle we signed, unmodified, fresh, within budget); a truth-boundary layer governs the CLAIMS inside it (is this sentence a sourced fact or a model's guess). A bundle can pass integrity perfectly while every claim in it is an unlabeled inference (and vice versa). Same §9 mechanism, non-overlapping concerns. OKF at rest, CCDD at the gate, epistemic labels on the content.

One consumer-side data point for the maintainers: my renderer treats foreign trust claims conservatively - frontmatter keys it doesn't recognize are preserved but never elevated (an unknown key can't light a "trusted" badge). That's the consumer-side complement to §9: accept unknown keys, don't honor them as authority. If a vendor_* / namespaced-keys convention gets documented (question 1: strong yes), it might be worth one sentence on that reception posture too - "carry unknown keys, never interpret them as trust signals" - so extension ecosystems can't be used to smuggle authority into consumers that don't understand them.

And +1 on the ecosystem/extensions pointer (question 2) - I'd happily list against it from the viewer side.