Teams that adopt an ontology to govern their data quickly hit a gap: the ontology is the source of truth, but the runtime consumes plain JSON/YAML config, not an RDF graph. So someone bridges it — usually by hand, or with a one-off script per concept, or (lately) by asking an LLM to "turn this ontology into config." All three rot the same way: the config drifts from the ontology, nobody can say which graph version a given config came from, and "regenerate the config" becomes a risky, non-reproducible chore. The seam between the knowledge graph and the application is where ontology projects quietly lose their guarantees.
ontology-config-generator makes that seam a deterministic compiler:
- Pure function of the graph. Same extension TTL + same spec table + same namespace ⇒ the same configs, every time. No model, no temperature, no hidden state. You can diff yesterday's configs against today's and the diff is the ontology change.
- Provenance on every artifact. Each config carries
_generated(source file, namespace, the binding it came from, how many entities were extracted), so "where did this config come from?" is answerable by reading the file — not by archaeology. - The domain is data, not code. A ~40-line generic extractor (named subclasses + named individuals; blank nodes skipped; label/comment fallbacks) does the work; which concepts exist is a reviewable, versionable spec table. Adding a concept is a one-row change a non-engineer can read, not a new code path to test.
- Degrade-open, so it's safe in a pipeline. A missing or malformed extension doesn't fail the build — it produces valid starter-shaped configs and logs the reason. A generation step can run unconditionally on every change without becoming a flaky gate.
Once config has drifted from the ontology by hand, you can't recover the mapping — you have to reverse-engineer which JSON keys correspond to which classes, and you've lost the per-artifact provenance entirely. And an LLM-"generated" config is non-deterministic by nature: you can't reproduce it, can't diff two runs meaningfully, and can't put it on the critical path of a governed change without a human re-reviewing the output each time. Adopting a deterministic compiler as a primitive means every config is born as a provable, provenanced projection of the graph — and the cost is a small, zero-dependency library whose only heavy import is lazy.
Anywhere a shared ontology fans out into per-deployment / per-tenant config: multi-tenant platforms where each tenant extends a common core, product lines that share contracts but differ in taxonomy, or any system with a "the ontology changed → the runtime must see new config" loop that you want to be one reproducible command rather than a manual, un-auditable edit.