KTL Registrar Knowledge Bundle

A LOKF knowledge base for the KTL Registrar Obsidian plugin. Every Markdown file under knowledge/ is one concept; together they form a queryable knowledge graph, derived from this repository’s code and docs.

base_iri is https://w3id.org/ktl/registrar/knowledge/, a namespace under Knowledge Trust Ladder’s w3id.org authority, which resolves it to this plugin’s knowledge site.

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

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: 0 of 24
• Checked by automation only: 24
• Nobody has checked: 0
• Drafts: 9
• Reopened: 0
• Past review date: 0
• Edited since confirmed: 0
• 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.

Contents

Services

• KTL Registrar Plugin - The plugin lifecycle in src/main.ts: fifteen commands, the status bar, vault-wide scanning, bundle-root resolution, and the read-only API the sibling KTL Curator may read.
• Validator Engine - The import-free rule engine in src/validator.ts: the LOKF semantic layer (bundle header and base_iri, type vocabulary, typed relationships, id minting, trust and lifecycle shape), the OKF v0.2 base layer behind checkOkfBaseLayer, the errors lokf validate also raises, and pure bundle-root detection.
• Report View - Collapsible side-panel view rendering the vault-wide LOKF conformance report.
• Settings Tab - The declarative settings tab in src/settings.ts (Obsidian 1.13.0 getSettingDefinitions API): its eleven groups, how list settings are stored and saved, bundle root folders and the break-glass whole-vault switch, and Known LOKF types as the domain-schema extension point.

References

• LOKF specification
• LOKF Toolkit - The lokf PyPI package that the .lokf/ sidecar depends on (lokf[build]>=0.9.0) and runs through the justfile recipes and the website’s sync; a separate resource from the LOKF specification website.
• OKF Specification (v0.2) - The Open Knowledge Format v0.2 specification: a folder of Markdown files with YAML frontmatter, one concept per file, with a type as the only required field, plus the provenance, trust and lifecycle fields and attested computations.
• Obsidian Plugin Guidelines - Obsidian’s developer guidelines for community plugins, for example sentence case in UI text, setHeading in a settings tab, no innerHTML, no detaching leaves in onunload and no hardcoded styling, which eslint-plugin-obsidianmd enforces in this repository.
• Commands and Settings - Every KTL Registrar command with its id and name, what the status-bar item does when clicked, and the settings groups under Settings → KTL Registrar, including Known LOKF types for a domain schema, from docs/using.md and src/main.ts.

Glossary

• LOKF - LOKF, the Linked Open Knowledge Format: a semantic profile of OKF that binds every field, type and relationship to a public vocabulary, so a bundle expands to JSON-LD and RDF and can be queried.
• OKF - OKF, the Open Knowledge Format: a folder of Markdown files with YAML frontmatter, one concept per file, whose only hard requirement is a type.
• Diátaxis genre - The optional Diátaxis genre facet (tutorial, how-to, reference or explanation) that tags how a concept’s prose serves the reader; the plugin warns on a value outside the list.

Playbooks

• Knowledge Sources - Map of the repository files and outside sources this bundle is derived from, which concepts each feeds, how a refresh re-checks each, which files are left out on purpose, and which have no concept yet.
• Contributing - How to set up KTL Registrar for development, how src/ splits into pure and Obsidian-bound modules, and the checklist before a pull request: npm run check, the changelog entry, a releasing pull request title, and the skills pin, which knowledge-sync.yaml and knowledge-sync.sh move with every template the release’s knowledge-sync.manifest lists.
• Releasing - Semantic-release computes the version and promotes CHANGELOG.md on merge to main, behind a required-reviewer Environment; the resulting tag invokes the same hardened build-and-attest workflow a hand-pushed tag always has.
• Quality Gates - The lint-and-docs.yaml workflow: ShellCheck, actionlint with a check that every action is pinned to a commit, markdownlint, a link check and codespell, on pushes to main, every pull request and a weekly schedule; plus the markdownlint rule overrides and the Dependabot updates that keep the pins current.
• Scheduled Librarian - The knowledge-librarian.yaml workflow: three jobs split by privilege, so the agent proposes bundle changes as a patch under a read-only token and only a job that runs no agent pushes the branch and opens the review pull request; how it is switched on, when a scheduled week runs no agent, and the checks publish makes.
• Knowledge registrar gate - The knowledge-registrar.yaml workflow: it validates the bundle and its relation targets and checks the sidecar conventions on every pull request that touches the bundle, and ties every human: confirmation a change adds, alters or removes to that person’s approving review or verified signature, with an environment reviewer’s attestation as the fallback.
• Knowledge Website - The website/ folder and the knowledge-website.yaml workflow: an Astro Starlight site built from the bundle, the README, docs/ and the changelog, how to preview it, what to edit, and how the workflow builds it on pull requests and deploys it to GitHub Pages at https://noelmcloughlin.github.io/obsidian-ktl-registrar/ once KNOWLEDGE_WEBSITE_ENABLED is true.
• Install KTL Registrar - How to get a LOKF bundle, open it as its own Obsidian vault, and install KTL Registrar there from a GitHub release, with BRAT or from source. The plugin is not yet in the community plugin store and needs Obsidian 1.13.0 or later.

Policies

• No Telemetry - KTL Registrar makes no network requests, has no telemetry and no external services, and loads no remote code; it reads the open vault and writes only when a person runs a command that edits a note.
• AI Covenant - Contributors own what they submit, whichever tools helped write it; AI may support discussion but never take part on a person’s behalf; a repository-owned agent commits under a bot identity, proposes every change as a reviewed pull request, runs with least privilege, and never records a person’s verdict itself.
• Code of Conduct - The project’s code of conduct, adapted from Contributor Covenant 2.1, for harassment-free participation; the same file as the sibling knowledge-trust-ladder repository’s.

Explanation

• Why KTL Registrar - Why KTL Registrar exists: no other known tool checks the LOKF semantic layer, so it checks that layer and the OKF v0.2 base layer beneath it in the editor, reports rather than blocks, lets a person turn off Enforce OKF conformance as errors to downgrade the OKF errors to warnings, and stays independent of its sibling KTL Curator.