Architecture
Knowledge Trust Ladder (KTL) is an architecture inspired by LOKF, by LinkML and by this poem:
“We lasso the world with networks of silver-coloured Italian hemp,
We bind down the world into some sort of order;
We balance the earth in a pair of scales of our own devising.”
— Amy Lowell, The Congressional Library (1922)
KTL keeps any repository’s scattered knowledge as a collection: catalogued, authenticated and explained, with the trust in every claim left visible. Four Agent Skills build and keep it. Registrar automation checks every record and guards every confirmation, in continuous integration (CI) on each pull request, as a museum’s registrar keeps its collection’s records. A toolkit underneath supplies schema and tooling. Two Obsidian plugins are optional, for a vault with no CI.
An agent derives it. Deterministic tools check it. A named person vouches for it. The bundle records which of the three happened to every claim.
Why libraries have catalogues
Section titled “Why libraries have catalogues”Knowledge already exists: in code, documents, diagrams, policies, operational records. What’s missing is a context layer: a governed layer between those sources and whoever consumes them, that persists from one task to the next. Without it every task starts the same way: find the material, connect it, judge what’s still true. The next person or assistant does that work again.
A knowledge bundle is the catalogue: a plain folder of Markdown concept files that keeps the work instead of discarding it. It is useful only when a reader can tell which entries are sound, and that depends on one question: who is responsible for the quality of this context? The trust ladder is the answer, written into each entry: where the entry came from and how far it has been checked, in plain words. One bundle is one repository’s context layer, and context-layer.md says how several bundles become one catalogue.
Prose, Structure, Meaning, Context
Section titled “Prose, Structure, Meaning, Context”A bundle is prose a person reads, structure a schema checks, meaning a graph can query, and context the next task can start from. It is written in LOKF (Linked Open Knowledge Format), a semantic profile of OKF whose specification is a single LinkML schema. People, agents and any tool that speaks OKF, JSON Schema, JSON-LD, SHACL or another supported format can read it.
KTL is an OKF runtime. OKF sets out to “standardize the small set of frontmatter fields that make an agent-maintained corpus trustable, without prescribing any runtime”. In KTL those fields are the rungs a claim climbs and the gate that refuses a human: confirmation no person can be tied to. LOKF supplies “a fixed taxonomy of concept types”, which OKF leaves to the producer. A domain whose concepts stop fitting it extends the schema, so its own types are checked rather than tolerated. Whoever uses a claim as context, person or agent, also reads how far it has been checked, whether from one bundle or from many federated into one layer.
Four skills, three lines of the poem
Section titled “Four skills, three lines of the poem”| Skill | Role | Runs |
|---|---|---|
ktl-sidecar |
Sidecar, lays the network. Installs the sidecar from bundled templates: .lokf/, a dot-folder beside the code like .git/, kept out of the project’s build. It holds tooling, docs, a dummy skeleton at .lokf/knowledge/, and a knowledge_bundle link for folder pickers that hide dot-folders. Repairs a broken sidecar file. Its portability page covers Windows, macOS, other forges, no git and synced folders. |
once |
ktl-librarian |
Librarian, binds it into order. Scrapes the repository, derives concepts with their sources, classifies them, links them with typed relationships, audits, and hands off for review. Like a real librarian it catalogues without vouching: facts about the repository, never verdicts about truth. | often, including on a schedule |
ktl-curator |
Curator, holds the scales. A person’s assistant. It shows what needs a look, puts the source next to the claim, and records the verdict (confirm, correct, retire, send back) in the bundle’s own frontmatter. Judgements a person made, never facts it derived. | a little, regularly |
ktl-docent (examples) |
Docent, guides the visitors, the role the poem leaves implicit, because the collection exists for them. Answers from the bundle and labels how far each concept has been trusted. Checks exact values at the source. When the bundle has no answer it explores the repository and records the miss, which becomes the librarian’s next task. Like a real docent it explains the exhibition without moving anything on the shelves: read-only on the bundle. | whenever anyone asks |
Curator is the museum sense, the one who authenticates, weighs provenance and decides what goes on exhibit. It is not the data-management sense, which is the librarian’s job. The curator is always a person, and the skill and the plugin that carry the name reach no verdict of their own.
On a fresh repository they run in order: sidecar, then librarian filling the bundle with drafts, then curator, where a person turns drafts into confirmed knowledge. After that it is a loop: the librarian refreshes on a schedule, readers report what the bundle missed, and the curator reviews what is new or changed.
The fifth role, which is not a skill
Section titled “The fifth role, which is not a skill”The registrar keeps the records in order: each accession (an item added to the collection) documented, its provenance filed, nothing entered in a form the catalogue can’t read. No human has to do this: the lokf toolkit checks every change, and CI’s knowledge-registrar.yaml checks every pull request that touches the bundle. It also ties each confirmation that is added or removed to the confirming person’s approval or signed commit.
At the librarian’s desk the registrar is knowledge-apply.sh, the pen, the only way the librarian writes the bundle, and it refuses a change that would fake or remove a confirmation (who writes the bundle). At the reader’s desk and the curator’s it is knowledge-report.sh, which computes each trust label and the bundle’s health line, so that neither is a model’s arithmetic. These are the deterministic tools of the summary at the top of this page: a check gives the same answer every time, which neither the librarian nor the curator can promise.
As a flow diagram, drawn with Archify: light, dark.
In Obsidian there is no CI, so two optional plugins work inside the editor. KTL Registrar does the registrar’s work, checking each record as it is typed. KTL Curator is the curator’s assistant, and runs this repository’s ktl-curator review session with no agent in the loop (The bundle in Obsidian).
In the three lines of defence that regulated industries use, the librarian and the curator are the first line, the registrar the second, and the bundle holds the evidence a third line would need (three-lines.md).
The fifth skill, which is not a role
Section titled “The fifth skill, which is not a role”ktl-prose is the librarian’s copy editor. It rewords what an agent wrote, in plain English, before a person confirms it. It changes the wording and never a fact, it leaves every byte of frontmatter alone, and it never touches a concept a person wrote or confirmed. It is optional.
The sixth skill, which publishes the bundle
Section titled “The sixth skill, which publishes the bundle”ktl-website builds a website for the bundle. It has a page per concept with its trust label, the health page, the knowledge graph and search by trust and type, and it serves the four files lokf export writes beside the pages. The repository’s README, docs, changelog and LinkML schema pages join them when it has them. Its data joins them as SQLite databases to open in Datasette Lite, once a person turns that on. A workflow publishes the site to GitHub Pages. This repository’s site is the template’s first copy. The website skill is optional, like ktl-prose.
Trust stays visible
Section titled “Trust stays visible”The curator reports each concept’s trust record in plain words:
- Confirmed by a person: a named person checked it against its source.
- Checked by automation only: automation re-checked that the source still matches, and no person has.
- Nobody has checked this yet: no check of any kind is recorded.
- Still a draft, reopened, edited since a person last confirmed it, past its review date, a reader disputed this, retired or retired, replaced by its successor; and, for prioritising, how many other concepts rely on each one. A question asked after a confirmation reopens a concept and flags what waits. It never drops the rung. Only an edit after the confirmation does that.
As a flow diagram, drawn with Archify: light, dark.
The labels are computed from the frontmatter on every read, never stored, so they always agree with what they describe. Each is a signal for the reader to weigh, never a score. The number to watch is confirmed by a person: n of N. It is meant to rise slowly, a handful of concepts in a sitting.
Read on
Section titled “Read on”| How to install the six skills, which ones to start with, and how to pin them to one release | install.md |
| The context layer: what it is, how one bundle already is one, and why bundles federate through domains | context-layer.md, and what it integrates with |
| A federation of bundles: domains as manifests, tiers of domains, the workspace built ahead of time, what exists and what remains a design, and the decisions an adopter must make | federation.md |
| Knowledge outside the repository: wiki pages, documents and files in other repositories, mirrored by the ingest so the bundle can cite them | ingest.md |
| The mechanics: who writes the bundle and what checks it, the four levels of checking, which the plugins run live, how readers and verdicts steer the next run, and what to do when a bundle outgrows LOKF’s vocabulary | for-the-curious.md |
| What the project’s own words mean, such as sidecar, registrar, docent, desk and the pen | the bundle’s glossary |
| The bundle in Obsidian, and the two plugins | obsidian.md |
| Where each role sits in the three lines of defence, and the model’s critics | three-lines.md |
| Whether KTL helps a repository whose content is Agent Skills, and what remains to do there | skills-repositories.md |
Versioning: all six skills are released under one vMAJOR.MINOR.PATCH, so a set pinned to one tag agrees with itself |
releasing.md, CHANGELOG.md |
| Contributing, the repository tree, and reporting a security issue | CONTRIBUTING.md, repository-layout.md, SECURITY.md |
Credits
Section titled “Credits”- Nolan Nichols, creator of LOKF (Linked Open Knowledge Format) and its toolkit.
- The LinkML Community, creators of LinkML, the schema language LOKF is written in.
- Google Cloud, creator of the Open Knowledge Format (OKF) specification that LOKF profiles.
- Andrej Karpathy’s LLM Wiki, a pattern for building personal knowledge bases with LLMs.
- WikiSkill by Tang et al. (Google Research, 2026) and SkillWiki by Huang et al. (2026), two papers whose reading changed how the skills learn from readers and verdicts.
- Archify by tt-a1i, under the MIT License, which draws the flow diagrams in
.assets/companions/. They embed the JetBrains Mono font, under the SIL Open Font License.
This is an independent project. It is not affiliated with, endorsed by, or an official distribution of LOKF or of the Open Knowledge Format. “LOKF” and “Linked Open Knowledge Format” refer to the format and toolkit published by Nolan Nichols; “OKF” and “Open Knowledge Format” to the specification published by Google Cloud. Both are used here as descriptors, under their own open terms.