LOKF Toolkit
references/lokf-toolkitChecked by automation only
Written 2026-10-29 by ktl-librarian (automation). Last checked 2026-10-27 by ktl-librarian (automation).
The full record
- Checks
- 2026-10-27 by
ktl-librarian(automation)
- 2026-10-27 by
- Sources
- Related to
- Pointed to by
- Knowledge registrar gate (depends on)
- Knowledge Website (depends on)
- Scheduled Librarian (depends on)
- Validator Engine (related to)
- Graph
- Open this concept in the knowledge graph
- IRI
https://w3id.org/ktl/registrar/knowledge/references/lokf-toolkit- Licence
- CC BY 4.0
- Files
- MarkdownJSON-LDSource on GitHubHistory on GitHub
Overview
Section titled “Overview”.lokf/pyproject.toml declares lokf[build]>=0.9.0, and .lokf/uv.lock pins the version that is installed. In .lokf/justfile, the lokf-install recipe runs uv sync, and the lokf-validate, lokf-check-refs, lokf-convert and lokf-serve recipes run this package with uv run lokf .... The knowledge website’s sync also runs lokf export from this environment.
This package is a separate resource from the LOKF specification (lokf.nolan-nichols.com). That site documents what LOKF means, and its own, broader environment-bootstrap flow, which this sidecar does not follow. Treating the two as one would credit the tooling dependency to a website that does not host it.
When uv or Python is not available, fetch the raw LinkML schema (lokf.yaml, listed as a source at the commit tagged v0.9.0) for a manual structural cross-check. It does not replace the generated JSON Schema checks that lokf validate runs. It is enough to catch an obviously wrong class or field name.
Not to be confused with Validator Engine (src/validator.ts). That is the KTL Registrar plugin’s own independent TypeScript reimplementation of the same Golden Rules. It runs at vault-scan time and has no runtime dependency on this Python package. This toolkit only maintains this repository’s .lokf/ sidecar bundle.