Skip to content

Why a registrar role, and why it is not a skill

Explanationexplanation/why-a-registrar-role

Edited since a person last confirmed it (confirmed 2026-10-13, edited 2026-10-19)

reopened

Written 2026-10-19 by ktl-librarian (automation). Last checked 2026-10-13 by noelmcloughlin (a person).

The full record
Checks
  • 2026-09-10 by noelmcloughlin (a person)
  • 2026-10-03 by noelmcloughlin (a person)
  • 2026-10-29 by ktl-librarian (automation)
  • 2026-10-13 by noelmcloughlin (a person)
Review by
2027-09-10
Sources
About
Related to
Pointed to by
Graph
Open this concept in the knowledge graph
IRI
https://w3id.org/ktl/knowledge/explanation/why-a-registrar-role
Licence
CC BY 4.0
Files
MarkdownJSON-LDSource on GitHubHistory on GitHub

A museum registrar keeps a collection’s 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. docs/architecture.md calls the registrar the fifth role, which is not a skill, beside the four skills (why four skill roles). No person has to do it. The lokf toolkit checks every change, and CI’s knowledge-registrar.yaml checks every pull request that touches the bundle. There it also ties each confirmation that is added or removed to that person’s approval or their signed commit.

At the librarian’s desk the registrar is knowledge-apply.sh, the pen, the only way the librarian writes the bundle. The librarian describes each change as an operation in .lokf/patch.yaml, and the script writes it. The script stamps generated from the clock, keeps a concept’s description equal to its two index bullets, and files the log line under the day’s heading. It refuses a human: actor, a rewrite of text a person wrote, and the deletion of a concept a person confirmed or left a note on. In a scheduled run the wrapper applies the patch after the agent has finished.

At the reader’s desk and the curator’s the registrar 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: a check gives the same answer every time, which neither the librarian nor the curator can promise.

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. Obsidian is optional in both directions: the skills rely on lokf validate, not on a plugin, and the plugins work on any LOKF bundle however it was made (docs/obsidian.md).

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 of defence).

The curator is always a person. The skill and the plugin that carry the name reach no verdict of their own.