Skip to content
Knowledge Trust Ladder

The curated context layer

A context layer is a governed layer between an organisation’s sources and whoever consumes them, a person or an agent, that persists from one task to the next. The bundle is the corpus KTL keeps in .lokf/knowledge/, one Markdown concept per file.

What people mean by a context layer

Section titled “What people mean by a context layer”

Unblocked states the minimum: “A real context layer in 2026 has four non-negotiable properties: heterogeneous source ingestion, on-demand surfacing, cross-source conflict resolution, and per-query permission enforcement.” Atlan adds what enterprise scale requires: “Multi-domain federation. Each domain owns its definitions but contributes to one graph. Conflicts get arbitrated, not duplicated.” Zhamak Dehghani named that shape in 2020 for data mesh: “federated computational governance” under “a set of global rules”.

The ownership point is older than the agents. Efficiently Connected notes that federation technology “cannot make a Head of Retail Banking agree to share definitional ownership with an AML team”, and that conversational agents return “whichever definition they encountered most frequently”.

Google Cloud’s Open Knowledge Format (OKF) “formalizes the LLM-wiki pattern into a portable, interoperable format”: “a directory of markdown files with YAML frontmatter”. Under “Format, not platform”, Google adds: “No complex compression scheme, no new runtime, no required SDK.” A format leaves the work open: what counts as trusted knowledge, how updates are reviewed, and what a consumer does with an unknown type or stale context. KTL exists for that work, and Prose, Structure, Meaning, Context says how it reads OKF’s trust goal.

One bundle is one repository’s context layer

Section titled “One bundle is one repository’s context layer”

The table sets Unblocked’s four properties, and the two the others add, against what a bundle does.

In the discourse In a KTL bundle Where it stops
Heterogeneous source ingestion The librarian derives each concept from a source it names in resource and sources (who writes the bundle) One repository’s sources. A second repository is a second bundle
On-demand surfacing A reader opens index.md first. The docent answers from the bundle and labels each concept it used (the index as the retrieval interface) Files, and one in-process graph, until something serves them
Cross-source conflict resolution The curator, a named person, records the verdict: confirm, correct, retire or send back. A reader’s disagreement goes to feedback.md One bundle. Between bundles, a domain’s owner arbitrates (who arbitrates)
Per-query permission enforcement None of its own. The repository’s access control is the bundle’s Nothing finer than the repository
Provenance and trust generated and verified events on every concept, and each label computed on read, never stored (Trust stays visible, four levels of checking) Who checked and when, not that the source is right
Format, not platform LOKF, a semantic profile of OKF: Markdown a person reads, a LinkML schema that checks it, a graph any SPARQL store loads A domain outside LOKF’s vocabulary needs a domain schema

So one bundle is already one repository’s context layer, with the fourth of Unblocked’s properties left to whatever hosts it.

Many bundles federated into one context layer: the design

Section titled “Many bundles federated into one context layer: the design”

OKF calls a bundle “The unit of distribution”, as a git repository, a tarball or zip, or a subdirectory of a larger repository. It says nothing about one bundle naming another, a catalogue of bundles, or what a reader may see of a bundle across a trust boundary. Its trackers ask for all three:

None had a maintainer’s reply when read on 2026-10-12.

Section 11 of the LOKF specification answers in linked-data terms: a registry of bundles, each keyed by its namespace, through which any IRI resolves to the bundle that owns it. KTL adds who answers for the set. A domain is a thin bundle in a repository of its own that selects released bundles, and one accountable owner confirms each bundle it admits. A domain may select domains in turn, and a build turns the one it starts from into one workspace, one named graph per bundle. A federation of bundles says how a federation is built and run, and What a KTL context layer integrates with names the products a workspace can use.

Drawn bottom to top, from repository bundles to a context layer and its readers: four bundles, each released from its own repository into an artifact repository; domains as manifests that select releases and are confirmed by a person, labelled domains/domain1, domains/domain2 and domains/federation, where the build starts; one context layer built from domains/federation; and, at the top, the readers.Drawn bottom to top, from repository bundles to a context layer and its readers: four bundles, each released from its own repository into an artifact repository; domains as manifests that select releases and are confirmed by a person, labelled domains/domain1, domains/domain2 and domains/federation, where the build starts; one context layer built from domains/federation; and, at the top, the readers.

As a flow diagram, drawn with Archify: light, dark.

Sources

Section titled “Sources”