Skip to content

Why KTL Registrar

Explanationexplanation/why-ktl-registrar

Checked by automation only

still a draft

Written 2026-10-16 by ktl-librarian (automation). Last checked 2026-10-27 by ktl-librarian (automation).

The full record
Checks
  • 2026-10-27 by ktl-librarian (automation)
Sources
About
Related to
Graph
Open this concept in the knowledge graph
IRI
https://w3id.org/ktl/registrar/knowledge/explanation/why-ktl-registrar
Licence
CC BY 4.0
Files
MarkdownJSON-LDSource on GitHubHistory on GitHub

KTL Registrar keeps a LOKF knowledge bundle well-formed as a person edits it in Obsidian. The README names it the registrar of Knowledge Trust Ladder: it checks that every record is well-formed, and it reaches no verdict of its own on whether a record is true. docs/architecture.md places that job for anyone who works under the three lines of defence: the plugin is second-line work, keeping the format and never judging truth.

Plain OKF is a folder of Markdown files whose only required field is a type. LOKF holds the same folder to a stricter dialect, with every field and relationship bound to a public vocabulary (schema.org, DCAT, PROV-O), so the bundle can be turned into a knowledge graph without loss. docs/for-the-curious.md lists what the plugin checks of that dialect:

  • the bundle-root semantic header;
  • the form and authority of base_iri;
  • a controlled type vocabulary;
  • the optional Diátaxis genre;
  • typed relationships whose targets must exist;
  • id consistency;
  • the shape of the OKF v0.2 §5 trust and lifecycle fields.

docs/architecture.md says its authors know of no other tool that checks the LOKF semantic layer.

Why it checks the OKF v0.2 base layer itself

Section titled “Why it checks the OKF v0.2 base layer itself”

Every LOKF field is a LOKF schema slot, so the plugin already has what it needs to check the plain OKF rules underneath the dialect. These are the okf/* findings: a required type, the Attested Computation contract, the reserved index.md and log.md structure, and the v0.1 to v0.2 migration hints. Severity follows the specification’s own force: what OKF marks REQUIRED or MUST, or lists under §11 conformance, is an error, and the shape of optional fields and the migration hints are warnings.

Enforce OKF conformance as errors is on by default in src/settings.ts. Turning it off downgrades the mandatory errors to warnings for a bundle in mid-migration, so the findings stay visible without blocking, and leaves LOKF’s own structural errors (base_iri, Field and Distribution) as errors. docs/for-the-curious.md calls it a break-glass switch, not recommended otherwise.

Settings → OKF v0.2 base layer switches the okf/* findings off in one place for a person who runs a dedicated OKF validator. docs/architecture.md names OKF Enforcer as one validator for that layer, and says that none is required because the same base rules are checked here.

LOKF’s own rules are permissive: a missing optional field, an unknown type or a broken cross-link must never cause rejection. So the plugin reserves errors for four kinds of structural problem, which docs/for-the-curious.md lists under “Why almost everything is a warning”, and reports everything else as a warning a person can act on or ignore. It writes only on an explicit command, and only to the form of a record, never to a claim.

The plugin checks the shape of the §5 trust and lifecycle fields and never their credibility. It does not weigh a source’s signals, rank trust tiers or decide whether a claim is current, and it executes nothing. Whether a claim is true takes a librarian pass and a curator’s review, and the sibling KTL Curator is where that review happens in the editor. The plugin never loads or calls a skill, an agent or another plugin, and neither plugin detects whether the other is installed. The one point of contact is the read-only api that docs/using.md describes, which another plugin may read without either depending on the other.