MCN’s compression works because MORK is small by design — it’s a deliberately minimal mapping calculus, and the complexity that would normally live in the vocabulary is pushed into the category-theoretic machinery instead. The decision ladder in your L0 kernel (“Q1: wire shape, concept, or mapping? Q2: does the target exist?…”) is answerable purely from MORK’s own closed, ~14-code structure. That’s what makes a fixed, hand-written, CI-gated doctrine set (lenses, minimal pairs) tractable — the author of MTP is also the domain expert for MORK’s own semantics, so the “extensive explanation” cost you’re worried about has already been paid, once, by the MORK team.
The target ontology inverts this. It isn’t minimal by design — it’s supposed to carry the domain’s real distinguishing structure — and nobody on your side is the domain expert for whatever ontology a customer brings. So writing an equivalent minimal-pairs table (“use InsurerRole when X, ClaimantRole when Y”) for an arbitrary target ontology isn’t a compression problem, it’s a knowledge-acquisition problem wearing a compression costume. That’s the part that’s genuinely a gamble if you try to fully automate it with no review loop — an auto-generated wrong minimal pair is worse than no minimal pair, because it produces confident-wrong mappings instead of the MU/low-weighting behaviour your whole design exists to prefer.
Notice your own llm-training.md §6(e) already lists a retrieval index as one of four compilation targets alongside the prompt bundle, grammar, and fine-tune corpus — all sourced from the same artefact. That’s the right instinct to extend to the target-ontology side rather than treating “compile an MTP” and “use Graph RAG” as competing architectures. Split the target-side problem into three tiers by risk, and only push into the riskier ones as ROI justifies it:
Tier 1 — mechanical, build now, no domain knowledge required. A codebook/CURIE-shortening pass over the target ontology (spec/*.ttl, vocab/*-vocab.ttl, applied-layer spec/) and a compact “shadow” structural index: class hierarchy, disjointness, domain/range, cardinality, named individuals. This is exactly the same mechanical operation MORK’s own §20 codebook generator already does against Mork.ttl — it doesn’t touch meaning, only shortens identifiers and exposes structure the checker can already validate against. Any ontology following the literate-spec convention this repo already uses (Definition + comment on every term, turtle-spec/turtle-vocab separation) gives you this almost for free. Token savings with zero semantic risk.
Tier 2 — Graph RAG, moderate risk, this is where real disambiguation lives. Retrieve, per mapping decision, the small neighbourhood that actually matters: candidate class + its comment, sibling/disjoint classes (to prevent exactly the code-confusion your minimal-pairs table prevents on the MORK side), domain/range of candidate properties, and — this is the important bit — prior confirmed mappings from the projection store. That last one is just MORK’s own tri-stratum Recognition→Community→Projection engine pointed at the target instead of the source. You don’t need the model to know the whole ontology; you need the SME-equivalent fragment for the field it’s looking at right now, the same way a human reviewer would only ever hold one corner of a large spec in their head at a time.
Tier 3 — auto-drafted doctrine, defer, gate hard if you ever do it. LLM-assisted lens/minimal-pair generation for the target ontology is possible, but it should follow the same discipline this repo already enforces on itself for new substrate content: generic premise first, non-domain examples before mechanism prose, SHACL/conformance gating before anything is promoted into an always-resident tier, provenance (mtp-version, profile-hash) on every proposal. Treat it as AI-proposes/deterministic-and-human-verifies, exactly like MORK’s own pipeline — never as something that ships ungated into L0–L4.
A 10,000-class ontology with a rdfs:comment (or better, an fnd:utility-style usage note) on every term and a handful of worked examples is a good Graph RAG target — retrieval quality tracks documentation quality, not term count. A 500-class ontology with bare class names and no comments is a bad target regardless of size, because there’s nothing for either retrieval or auto-doctrine to work from — that’s precisely the “extensive explanation from a domain expert” gap you flagged, and no amount of clever compilation removes it. Worth stating explicitly back to whoever owns onboarding a new target ontology: the literate-spec discipline this repo already enforces on itself (Definition/Utility per term, worked examples before mechanism prose) is a prerequisite for Tier 2/3 working well, not a nice-to-have.
Your MTP design leans hard on hash-pinning and byte-stable prefix caching for reproducibility across runs (§6a–c). Live Graph RAG cuts against that a little — retrieval results aren’t guaranteed stable run-to-run unless you snapshot the index too. The fix is consistent with what you’re already doing elsewhere: version and hash the retrieval index itself as a build artefact (same treatment as AllowanceDefinition conservation laws or spaceHash on a ValueSpace — a derived product with source, profile, and authority declared), and record its hash alongside mtp-version in the run provenance. Then “Graph RAG” isn’t an exception to the reproducibility story, it’s just another versioned compilation target.
If it’d help, I can draft this as an ADR in the style your docs/adr/ directory already uses (Status/Context/Decision/Consequences) rather than leaving it as chat prose — just say the word and I’ll write it up as a proper design document rather than baking any of this into the substrate itself.