Ontoref is a Standalone Protocol Project, Not Part of Stratumiops
Accepted
Context
The ontology/reflection patterns originated inside stratumiops as self-description tooling (stratum-ontology-core, stratum-reflection-core, stratum-daemon). Consumer projects (typedialog, vapora, kogral) needed the same patterns but had no path to adoption that did not entangle them with stratumiops' pipeline-specific crates (stratum-graph, stratum-state, stratum-orchestrator). Protocol evolution (schema changes, ADR lifecycle, daemon features) was blocked behind stratumiops release cycles. The three crates were logically a specification layer that happened to live in the wrong repo.
Decision
Ontoref is extracted as a standalone protocol project with independent versioning, CI, and crates: ontoref-ontology (Rust types for the ontology graph), ontoref-reflection (mode runner and schema validation), ontoref-daemon (NCL export cache, file watcher, actor registry). Consumer projects adopt the protocol via a thin `scripts/ontoref` bash wrapper and a `.ontoref/config.ncl` declaration. The ontoref project itself is allowed to use infrastructural — not domain-specific — stratumiops crates as peer dependencies via workspace path references. As of 2026-08-08 that surface is four crates, and they are NOT all optional: stratum-db and platform-nats are declared `optional = true` and drop out under --no-default-features, while `auth` and `ui` (from stratumiops/stratum-ui) are declared without `optional` in the workspace root. Cargo resolves every workspace member's manifest eagerly, so the two required ones are a build precondition for the WHOLE workspace — including ontoref-ontology, the crate this ADR calls the protocol's minimal adoption surface. The prohibition below is unaffected: none of the four is a domain crate.
Constraints
- Hard ontoref crates must not import stratumiops domain crates: stratum-graph, stratum-state, stratum-orchestrator, stratum-llm, stratum-embeddings
- Hard The ontoref entry point must not unconditionally overwrite ONTOREF_PROJECT_ROOT — it must default only when unset
- Soft A consumer project must only need .ontoref/config.ncl and scripts/ontoref to adopt the protocol — no other files copied into the consumer
Alternatives considered
- Keep all tooling in stratumiops, consumers depend on it as a git subtree or submodule — rejected: Submodule/subtree patterns create update friction and do not solve the versioning coupling. Every consumer needs stratumiops' full dependency tree even for protocol-only use.
- Publish ontoref crates to crates.io and consume via version pins — rejected: Rapid iteration on protocol schemas makes published crate semantics too rigid at this stage. Path dependencies allow simultaneous development of protocol and consumers without publication ceremony.
- Inline protocol tooling into each consumer project separately — rejected: Schema drift across projects would immediately arise. The protocol's value is precisely its shared contract — decentralizing it defeats the purpose.