Skip to content
Knowledge Trust Ladder

Explanation

  • Hosts and doorways: where the bundle’s real folder lives edited since a person last confirmed it (confirmed 2026-10-13, edited 2026-10-26), reopened
    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.

  • Knowledge Trust Ladder in a skills repository edited since a person last confirmed it (confirmed 2026-10-13, edited 2026-10-29), reopened
    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 checked by automation only, still a draft
    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.

  • Three lines of defence - where each role sits, and what an auditor can check edited since a person last confirmed it (confirmed 2026-10-19, edited 2026-10-29)
    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.

  • What Knowledge Trust Ladder is for, and what it is not checked by automation only, still a draft
    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 SkillWiki edited since a person last confirmed it (confirmed 2026-10-19, edited 2026-10-29), reopened
    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.

  • What KTL took from WikiSkill checked by automation only, still a draft
    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.

  • When the built-in vocabulary stops fitting: domain schemas edited since a person last confirmed it (confirmed 2026-10-13, edited 2026-10-29), reopened 2026-10-29 by noelmcloughlin: 1 question waits
    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.

  • Why a registrar role, and why it is not a skill edited since a person last confirmed it (confirmed 2026-10-13, edited 2026-10-19), reopened
    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 four skill roles rather than one skill edited since a person last confirmed it (confirmed 2026-10-19, edited 2026-10-25)
    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 the skills live in their own repository checked by automation only, still a draft
    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.