Knowledge Trust Ladder Knowledge Bundle

A LOKF knowledge base for Knowledge Trust Ladder. Every Markdown file under knowledge/ is one concept; together they form a queryable knowledge graph, derived from this repository’s code and docs.

The root file declares
Base IRI	`https://w3id.org/ktl/knowledge/`
JSON-LD context	`https://w3id.org/lokf/context.jsonld`
Licence	CC BY 4.0
Publisher	Noel McLoughlin
Concepts	62

How far it has been checked

The bundle health page gives each concept’s label. The counts, computed from frontmatter when the site was built:

Confirmed by a person: 4 of 62
Checked by automation only: 41
Nobody has checked: 0
Drafts: 41
Reopened: 14
Past review date: 0
Edited since confirmed: 17
Retired: 0

Files

concepts.jsonld: every concept’s frontmatter and body under one JSON-LD context.
graph.nt: the whole bundle as N-Triples.
graph.json: the typed relations as cytoscape.js elements, which the knowledge graph draws.
datasets.jsonld: a schema.org Dataset description for each Dataset or Table concept.
index.md: the bundle’s root file, which declares the header above.
log.xml: the bundle log as an Atom feed, its newest 20 days.
previews.json: each concept’s title, type, genre, trust label and definition, which a link to the concept shows before it is followed.
Each concept page links the concept’s own Markdown file and its JSON-LD, at the concept’s path with .md or .jsonld added.
The bundle as it stood at each release is a zip on the releases page.

Playbooks

ktl-sidecar skill - Procedure that creates a .lokf/ sidecar, tooling, docs, a dummy skeleton, and the knowledge_bundle doorway link beside it, from bundled templates, or repairs a missing or broken sidecar file, then hands off to ktl-librarian.
Open the knowledge bundle in Obsidian - How a knowledge bundle meets an Obsidian vault: two vaults, the workshop someone keeps and the bundle opened as its own through the knowledge_bundle doorway, what Obsidian does with the link on each host, and why the bundle is never a real folder inside a vault.
The docent in Microsoft 365 Copilot - How a person gets ktl-docent-m365, the docent packed with a snapshot of the bundle as a Microsoft 365 Copilot custom skill, from a release or by building it, adds it to a declarative agent, checks the first answer and keeps it current, what to do when a step fails, and why only the read-only roles go there.
ktl-librarian skill - Recurring procedure that scrapes the host repository, derives and maintains the .lokf/ concepts and their typed relations, audits the bundle, and hands off for human review.
ktl-curator skill - A human curator’s assistant: a one-screen report of what needs a person’s attention, then a review session that records that person’s confirm, correct, retire or send-back verdicts in the bundle’s frontmatter, including on a domain host’s member concepts.
ktl-docent skill - The reader’s side: it answers questions from the bundle first, with each concept’s trust label, falls back to the repository when the bundle cannot answer, and records misses and disagreements for the librarian; it also answers for younger readers and from a domain host’s workspace.
Knowledge sources - Map of the repository locations this bundle was derived from, and how to re-check each on a future refresh.
Contributing - How to work on the skills: no build step but the website’s, the local checks to run before opening a pull request, the role boundary a change must respect, and which pages now hold the release and signing detail.
Releasing - How a release happens: semantic-release.yml computes the version from Conventional Commits and promotes CHANGELOG.md on merge to main but never tags, and a maintainer’s publish.yml run checks that version against the changelog, lets gh skill publish create the tag and release, dispatches knowledge-release.yaml to attach the bundle, domain schema and Copilot zips, and asks the sibling hosts to sync.
Repository validation - What CI checks on every pull request and weekly: the repository contract, the Agent Skills spec, shell and workflow linting, the install and website smoke tests, and Markdown, link and spelling checks.
ktl-prose skill - The librarian’s copy editor. It rewords the body of a concept an agent wrote, in plain English, before a person confirms it, changing the wording and never a fact or a frontmatter byte, and its script proves that only the wording changed.
Build, preview and edit the website - How the project website in website/ is built with Astro Starlight from the README, docs/, the knowledge bundle, CHANGELOG.md and, when shown, the LinkML schema’s pages and data; how to preview it locally with npm and uv; which file to edit for each kind of change; and how knowledge-website.yaml publishes it to GitHub Pages, on a push, weekly or by hand.
ktl-website skill - Procedure that installs an Astro Starlight website for the knowledge bundle in website/ from bundled templates, with a page per concept and its trust label, a health page and the knowledge graph, and a workflow that publishes it to GitHub Pages once KNOWLEDGE_WEBSITE_ENABLED is set; or repairs and updates a site it installed, and hands the maintainer the steps that retire an mkdocs site it replaces.
Curating a domain bundle - How the curator of a domain host confirms that a bundle belongs, what the domain’s four concept types hold, what moves a member, and how to read the workspace the domain’s releases build.
Knowledge outside the repository - How the ingest mirrors Confluence pages, web pages and PDFs, files in another git repository and a command’s output into .lokf/mirror/, with the manifest .lokf/ingest.yaml, the lock, sensitivity, the weekly pull request, and how the librarian cites a mirror file.

References

LOKF specification - The canonical definition of the Linked Open Knowledge Format - a semantic profile of OKF binding every field, type, and relationship to schema.org, DCAT, and PROV-O.
OKF specification (v0.2) - Google’s Open Knowledge Format - a folder of Markdown concept files with YAML frontmatter, requiring only type, plus the v0.2 provenance, trust, and lifecycle families.
Agent Skills specification - The specification defining a skill directory - a required SKILL.md with name/description frontmatter, plus optional scripts/, references/, and assets/.
LOKF toolkit (lokf on PyPI) - The lokf Python package, which validates, converts and serves a LOKF bundle and is the dependency the scaffolded .lokf/pyproject.toml declares.
LinkML (linkml.io) - The schema-modelling language LOKF is written in, and the generator suite that turns a schema into JSON Schema, Pydantic models, SHACL shapes, docs, and OWL.
gh skill (GitHub CLI) - The GitHub CLI command group that installs, pins, and publishes agent skills from GitHub repositories; the publish path this repository uses for releases.
Open Skills CLI (npx skills) - The vendor-neutral installer for agent skills, npx skills add, which takes a local path as its source, so this repository uses it as a pre-publication install check.

Glossary

LOKF - The Linked Open Knowledge Format, the semantic profile of OKF this bundle is written in, which binds every field to a public vocabulary so the bundle projects to RDF.
OKF - The Open Knowledge Format, Google’s specification for a folder of Markdown concept files with YAML frontmatter, which LOKF profiles.
Knowledge bundle - The knowledge bundle, .lokf/knowledge: one Markdown file per concept, readable as documentation and queryable as a graph; how it differs from the .lokf/ sidecar, what its reserved index.md and log.md hold, and the knowledge_bundle doorway that Obsidian opens as a vault of its own.
Trust label - The plain words the skills use for how far a concept has been checked, derived from its frontmatter on every read and never stored.
The pen - The name for knowledge-apply.sh, the only way ktl-librarian writes the bundle: it applies the operations in .lokf/patch.yaml, stamps generated, keeps the index in step, and refuses a human: actor.
Docent - A museum’s name for a guide, and the role that answers a reader’s questions from the bundle, says how far each answer has been checked, and writes nothing in the bundle.
Desk - The library word for the place where a role does its work with the bundle: the registrar is knowledge-apply.sh at the librarian’s desk, and knowledge-report.sh at the reader’s and the curator’s.
Registrar - The person in a museum who keeps the collection’s records, and Knowledge Trust Ladder’s fifth role, which programs play: the lokf toolkit, the gate knowledge-registrar.yaml (or knowledge-provenance.sh on another forge or none), the pen and the report script.
Sidecar - .lokf/, the folder beside a project’s code that holds the bundle and the tooling that checks it, kept out of the project’s build; also the role, and the ktl-sidecar skill, that installs it.
Accession - A museum’s word for an item added to its collection, which the registrar keeps documented with its provenance filed; in the bundle, each concept added is one.
Librarian - The role that binds a repository’s knowledge into order, played by the ktl-librarian skill: it derives concepts with their sources, classifies and links them, audits, and hands off for review. It catalogues without vouching, and writes the bundle only through the pen.
Curator - The role that holds the scales, always a person: in the museum sense, the one who authenticates, weighs provenance and decides what goes on exhibit. The ktl-curator skill and the KTL Curator plugin are that person’s assistants, and reach no verdict of their own.
Collection - A repository’s scattered knowledge as Knowledge Trust Ladder keeps it: catalogued, authenticated and explained, with the trust in every claim left visible. Each item added to the collection is an accession.
Context layer - A governed layer between an organisation’s sources and whoever consumes them, person or agent, that persists from one task to the next. One knowledge bundle is one repository’s context layer, and KTL federates many bundles into one layer through domains.
Trust ladder - Knowledge Trust Ladder’s answer to who is responsible for the quality of the context: written into each concept, where it came from and how far it has been checked, as rungs a claim climbs from still a draft to confirmed by a person.
Workshop - In the two-vault arrangement for Obsidian, the vault a person already has, in which nothing is moved or migrated. The bundle opens beside it as the exhibition, a small vault of its own, and the two never index the same file.
Exhibition - In the two-vault arrangement for Obsidian, the bundle opened as a small vault of its own: the checked part of what the workshop knows, which teammates, CI and agents read. The README’s Exhibitions are the sites that show a repository’s collection.
Doorway - knowledge_bundle, the link at a host’s root that ktl-sidecar creates onto the bundle, so the hidden .lokf/knowledge folder has a name a folder picker can see. Obsidian opens the bundle as a vault of its own through it.
Health line - The one line knowledge-report.sh prints for the whole bundle, counting its concepts under eight trust labels, such as “Confirmed by a person: 3 of 40” and “Reopened”. It is derived on every read and never stored, and it is the number to watch over time.
Work list - What knowledge-report.sh worklist prints for ktl-librarian before each refresh, from frontmatter and git, in paths and dates and nobody’s words: the concepts whose sources moved since they were derived or last checked, the notes a person left and the librarian’s own open questions. It also counts the reader feedback that waits.
LinkML - The schema language LOKF is written in, created by the LinkML Community. LOKF’s specification is a single LinkML schema, from which the JSON Schema, JSON-LD context, SHACL shapes and OWL ontology are generated, and a domain schema that extends it is written in LinkML too.
Domain schema - A schema written in LinkML that extends LOKF’s, for a domain whose concepts stop fitting LOKF’s short list of classes, so the domain’s own types are checked rather than tolerated. The curator flags concepts that no longer fit, the team decides, and the librarian applies it.
Three lines of defence - The model regulated industries use to say who owns a risk, who keeps the rules and who checks independently, whose reference version is the IIA’s Three Lines Model. In Knowledge Trust Ladder the librarian and the curator are the first line, the registrar the second, and the bundle holds the evidence a third line would need.

Policies

AI covenant - Community norms for AI use - contributors own what they submit regardless of tooling, AI systems must not be used to autonomously post comments, replies, or messages, AI co-authorship in commit messages is discouraged, and a repository-owned agent (e.g. ktl-librarian) must commit under a bot or maintainer identity with no trailer either way and land only as a human-reviewed PR.
Security policy - How to report a vulnerability privately, supported versions, and a surface table (what executes here, what guards it) that links to the shared threat model instead of restating it.
Threat model - The security design the three KTL repositories share, kept in one place so each SECURITY.md can link to it: repository hardening, the human:-attribution gate on a verified event, and the prompt-injection guard for each input path that reads content it did not author.
Versioning policy - One repository-level semantic version covering all six skills, released together under a single tag, with patch, minor and major decided by Conventional Commits.
Code of conduct - Contributor Covenant v2.1: its scope over issues, pull requests and discussions, and how to report unacceptable behaviour.

Explanation

Why four skill roles rather than one skill - Why the work is split into four skills, sidecar, librarian, curator and docent, named for the library and museum professions and run first in order and then as a loop, beside a fifth role that is not a skill (the registrar) and two optional skills beside the roles (ktl-prose, and ktl-website, which publishes the bundle).
Why a registrar role, and why it is not a skill - What the registrar, the fifth role and not a skill, does: it keeps every bundle record in order and ties every confirmation to a person, through the lokf toolkit, CI’s knowledge-registrar.yaml, the pen knowledge-apply.sh and knowledge-report.sh, while the KTL Registrar plugin does that work in Obsidian, where there is no CI.
Why the skills live in their own repository - Why the six skills are published from one installable repository: three install routes plus Microsoft 365 Copilot for the docent, one tag for all of them, one changelog, a bundle of its own that the docent answers from, and the repository’s rename.
Hosts and doorways: where the bundle’s real folder lives - Why the bundle is .lokf/knowledge, one real folder on every host, with knowledge_bundle beside it as a link for people and folder pickers; what each host can do, from GitLab, Codeberg, Forgejo and Gitea to Microsoft 365 Copilot; what the visible layout tried and why it was retired; what a shared folder that is not a vault may still do by hand; and how one vault can link many hosts’ bundles.
Three lines of defence - where each role sits, and what an auditor can check - The librarian, curator, registrar, sidecar and docent placed in the IIA’s Three Lines Model, for whoever adopts KTL: who owns a claim, what a machine checks, what a person can examine afterwards, the four limits on that evidence, the model’s critics with KTL’s answer to each, and what remains to do and who does it.
When the built-in vocabulary stops fitting: domain schemas - How a bundle in a specialised or regulated domain goes beyond LOKF’s core classes: the signs a domain schema is due, a LinkML schema importing LOKF’s, named by one schema variable in the sidecar’s justfile and checked with lokf validate --schema, the three layouts that variable allows, the domain.yaml the sidecar ships for a bundle that federates other bundles, reusing a domain’s own vocabulary such as the AI Risk Ontology through lokf adapt, the Microsoft 365 identity shape held in reserve, and who raises, decides and applies it.
What Knowledge Trust Ladder is for, and what it is not - A draft placeholder for a reader’s question no source settles: which uses Knowledge Trust Ladder is meant for, such as DevSecOps or technology governance, and which it is not. The README, docs/architecture.md and docs/context-layer.md state the purpose and name no use case or non-goal, and docs/skills-repositories.md answers it only for a repository whose content is Agent Skills.
What KTL took from WikiSkill - What Knowledge Trust Ladder (KTL) took from the WikiSkill paper (Tang et al., 2026), and what the paper leaves open. Both run one loop of maintainer, pen, consumer and gate, and the reading made seven changes to the skills, such as a consumer that writes nothing, a bounded run and a retrieval score.
What KTL took from SkillWiki - What Knowledge Trust Ladder (KTL) took from the SkillWiki paper (Huang et al., 2026) and its code: the four changes the reading made to the skills, the excerpt check that arrived with LOKF 0.9.0, and where the two designs part, such as who stands behind a decision.
Knowledge Trust Ladder in a skills repository - Whether to install Knowledge Trust Ladder (KTL) in a repository whose content is Agent Skills, as docs/skills-repositories.md answers: what it adds (the knowledge around the skills), what it leaves to evaluations (whether a skill works), what it costs when skills change weekly, this repository’s six skills and a run on anthropics/skills, how the librarian maps skills, and what remains to do.
The curated context layer: one bundle, and a federation of bundles - What a context layer is, and why one KTL bundle is already one repository’s context layer and where it stops. How bundles federate into one: domains as thin LOKF bundles that select releases, tiers of domains and the diamond rule, a workspace with one named graph per bundle served over SPARQL and MCP, and the products it can use.

Young readers

Retellings of concepts for younger readers, each derived from the concept it names. The folder’s own index lists them too.

The pen, for readers aged 13 to 18 - The pen retold for readers aged 13 to 18, the script that is ktl-librarian’s only way to write the bundle, and what it refuses.