# The curated context layer > [!NOTE] > This page is for anyone comparing Knowledge Trust Ladder (KTL) with other context layers. 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 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](https://noelmcloughlin.github.io/knowledge-trust-ladder/docs/architecture/#prose-structure-meaning-context) says how it reads OKF's trust goal. ## 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](https://noelmcloughlin.github.io/knowledge-trust-ladder/docs/for-the-curious/#who-writes-the-bundle-and-what-checks-it)) | 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](https://noelmcloughlin.github.io/knowledge-trust-ladder/docs/for-the-curious/#how-readers-and-verdicts-steer-the-next-run)) | 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](https://noelmcloughlin.github.io/knowledge-trust-ladder/docs/federation/#decisions-an-adopter-must-make)) | | 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](https://noelmcloughlin.github.io/knowledge-trust-ladder/docs/architecture/#trust-stays-visible), [four levels of checking](https://noelmcloughlin.github.io/knowledge-trust-ladder/docs/for-the-curious/#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](https://noelmcloughlin.github.io/knowledge-trust-ladder/docs/for-the-curious/#when-the-vocabulary-stops-fitting) | 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 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: - a bundle-local registry for external references ([knowledge-catalog #175](https://github.com/GoogleCloudPlatform/knowledge-catalog/issues/175)); - discovery across a set of bundles ([#302](https://github.com/GoogleCloudPlatform/knowledge-catalog/issues/302)); - collection-scoped metadata ([#214](https://github.com/GoogleCloudPlatform/knowledge-catalog/issues/214)); - an `imported` marker that does not inherit trust ([open-knowledge-format #15](https://github.com/GoogleCloudPlatform/open-knowledge-format/issues/15)); - partial visibility across a trust boundary ([#32](https://github.com/GoogleCloudPlatform/open-knowledge-format/issues/32)). 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](https://noelmcloughlin.github.io/knowledge-trust-ladder/docs/federation/) says how a federation is built and run, and [What a KTL context layer integrates with](https://noelmcloughlin.github.io/knowledge-trust-ladder/docs/context-layer-technology/) 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.

***As a flow diagram, drawn with Archify: [light](https://noelmcloughlin.github.io/knowledge-trust-ladder/assets/companions/ktl-federated-context-layer.svg), [dark](https://noelmcloughlin.github.io/knowledge-trust-ladder/assets/companions/ktl-federated-context-layer-dark.svg).*** ## Sources - Atlan (2026). Context layer. Atlan Documentation. - Dehghani, Z. (2020). Data Mesh Principles and Logical Architecture. - Google Cloud (2026). Open Knowledge Format, specification version 0.2. - McVeety, S. and Hormati, A. (2026). Introducing the Open Knowledge Format. Google Cloud. - Nashawaty, P. and Weston, S. (2026). Enterprise AI Governance: The Operating Model AI Agents Need. Efficiently Connected. - Nichols, N. (2026). LOKF specification, version 0.2, section 11: Federation, registries of bundles. . The toolkit as released at 0.9.0: - Pilarinos, D. (2026). The Context Layer: What It Is and Why Every AI Agent Needs One. Unblocked.