Does LightRAG consume domain/range too

[antejavor]

Part of #344

Question

Does LightRAGBackend consume the ontology's structural constraints, or does it stay post-hoc-only — and is the resulting asymmetry acceptable?

The plan says LightRAG needs no change: the domain/range check runs against whatever is already in Memgraph, whichever backend wrote it. That holds cleanly only if enforcement is post-hoc everywhere. Once GLiNER2 gets extraction-time constraints, the backend choice starts changing enforcement semantics, not just extraction quality.

Context: Ontology.entity_types_guidance() already steers LightRAG's prompt for entity types, and Ontology's own docstring records that relation_types has no LightRAG consumer at all — LightRAG has no relation-type steering hook, and writes generic :DIRECTED edges with no typed label (which is why unstructured2graph/evals reports LightRAG's relation scores as n/a rather than zero).

Open:

1. Can domain/range be expressed to LightRAG at all — as prompt guidance analogous to entity_types_guidance(), given there is no native hook?
2. If yes, is prompt-level steering meaningfully "enforcement", or just a suggestion that needs the post-hoc check anyway?
3. If no, is a two-tier model acceptable — GLiNER2 constrained at extraction, LightRAG validated after — or does that make the two backends non-comparable in a way that undermines them being pluggable alternatives at all?
4. Does LightRAG's lack of typed relation labels make this moot until that is fixed separately?

Blocked by #348: there is only an asymmetry to resolve if extraction-time constraints are adopted. Most likely ticket on this map to turn out to be fog — if #348 lands on post-hoc-only, close this as out of scope rather than resolving it.

[antejavor]

Narrowed by #348. Half of this is now answered: the post-hoc pass is backend-agnostic by construction — enforce_relation_domain_range checks whatever is in Memgraph regardless of who wrote it — so LightRAG gets domain/range validation for free, with no LightRAG-specific work at all.

What remains is only the extraction-time half: does LightRAG get domain/range as steering? Concretely, does rdfs:domain/rdfs:range go into its prompt guidance the way entity types already do via entity_types_guidance?

Worth carrying in from #348 and ADR 0002: prompt guidance is steering, not enforcement — "LightRAG's own entity_types_guidance is just prompt text, no code-level check against what the LLM returns." So the question here is purely whether the steering improves LightRAG's edges, not whether it makes them trustworthy. The post-hoc pass is what makes them trustworthy, and it already covers this backend.

A second thing to weigh: LightRAG writes generic :DIRECTED edges with no typed relation label. Domain/range steering over untyped edges may be close to meaningless — which could make the answer here "no, and here is why", cheaply.

[antejavor]

Answer: no — at neither end, and that is by design rather than a gap

LightRAG consumes neither half of the two-compilation model #348 settled. Not extraction-time steering, and — contrary to what #348's own follow-up note said — not post-hoc validation either.

There is no relation type to constrain

LightRAG's extraction prompt emits relationship rows as:

relation{tuple_delimiter}source_entity{tuple_delimiter}target_entity{tuple_delimiter}relationship_keywords{tuple_delimiter}relationship_description

(lightrag/prompt.py:78-84). There is no type field — nothing a RelationType.label could bind to, and therefore nothing for start_labels/end_labels to constrain. The same prompt, rule 6, adds: "Treat all relationships as undirected unless explicitly stated otherwise." Domain/range is inherently directional, so the model is being told to discard the very distinction the constraint is made of.

Storage agrees: lightrag/kg/memgraph_impl.py:618 and :829 write MERGE (source)-[r:DIRECTED]-(target) — a single untyped relationship type, merged on an undirected pattern, so even the stored direction is arbitrary.

So extraction-time steering is not expressible

The only ontology-shaped hooks LightRAG exposes are {entity_types_guidance} (prompt.py:117) and two few-shot example lists overridable via entity_type_prompt_file (prompt.py:527, :705) — all entity-shaped. LightRAGBackend never sees an Ontology at all (extraction_backend.py:56); the ontology reaches LightRAG only as addon_params() at wrapper-init, a separate call site. Even if relation vocabulary were smuggled into the entity guidance string, the output format has no field to put a type in. This answers the ticket's questions 1 and 2 together: not expressible, so the "is prompt steering really enforcement" question never arises.

And post-hoc validation is vacuous, not free

enforce_relation_domain_range matches relationships by type label. Every LightRAG edge is :DIRECTED. The check matches zero rows and reports zero violations — on a graph that may hold thousands of semantic edges, none of them typed.

This revises #348's follow-up note, which read: "post-hoc is backend-agnostic, so LightRAG gets domain/range validation for free." Backend-agnostic it is; free it is not. A clean bill of health from a vacuous check is indistinguishable from a clean bill of health from a conformant graph — which is the exact failure shape that chartered this map.

The plan's §2 line is wrong for the same reason and gets corrected in the revision:

extraction_backend.py / LightRAGBackend: no change — the domain/range check runs post-hoc against whatever's already in Memgraph regardless of which backend wrote it, same as today's entity-label gate.

The action stays right — LightRAGBackend still needs no code change. The claim is what changes: the relation half of the ontology is inert for this backend, and the plan should say so rather than imply coverage it does not have.

---

The asymmetry is stated, not reconciled

Ante's scope call, which reframes the ticket's question 3:

"I am more focused on making GLiNER2 default for this and adapting the code base more to it, but I want to make things swappable to different model. So LightRAG is second-order citizen but I don't want to delete or forget about it."

"I am considering them single choice deal, they should not be interchangeable in results but maybe in the process."

So the two backends are interchangeable in process, never in results. That is a sharper statement than either the plan or extraction_backend.py's own docstring makes today — the ExtractionBackend Protocol sells them as pluggable alternatives behind one contract, which is true of the process (one aingest_chunk, one workspace label, one entity_type property, one file_path=chunk hash) and false of the product (typed, directed, domain/range-constrained edges versus untyped undirected :DIRECTED).

There is therefore no two-tier enforcement model to justify and no comparability to defend. GLiNER2 is the typed-relation backend. LightRAG is a retained alternative pipeline: not deleted, not forgotten, not invested in. The ticket's question 4 — does LightRAG's lack of typed relation labels make this moot — is answered yes, and it stays that way; typing LightRAG's edges is ruled out of scope on the map rather than deferred.

---

What gets built: a coverage signal, reporting-only

The asymmetry needs no compatibility scaffolding, but the silence does need a voice. A vacuous pass returning [] is a bad signal in any backend's hands, so enforce_relation_domain_range gains an observational signal. It reads the graph, not the backend — no ExtractionBackend protocol change, no capability flag, none of the call-site coupling ADR 0003 refused, and it works for a backend that does not exist yet.

Rejected: a supports_typed_relations capability on the Protocol (threads backend knowledge into call sites, and every future backend must answer it), and documentation-only (detects nothing at runtime, which is how an edgeless graph reached a scored 100-question eval).

What it counts, whole-workspace and idempotent on re-run, matching its sibling promote_entity_types_to_labels (memgraph.py:111):

1. Discriminated emptiness. When zero relationships carry any declared relation type, the issue names which of two different bugs it is:

   • "workspace holds N relationships, none of a declared type" — a backend emitting untyped edges. LightRAG's exact signature, and the expected steady state there.
   • "workspace holds zero relationships at all" — nothing extracted. A GLiNER2 misconfiguration, and literally the bug this map was chartered on.

   A single "no typed edges" message would conflate them.

2. Per-type coverage, aggregated into one issue listing declared relation types with zero instances. One issue, not one per type — a twelve-type derived ontology on an early run would otherwise emit twelve and drown the signal.

Severity is reporting-only; it never blocks, and enforce_ontology gates it exactly as it gates the rest of the post-hoc half (#348).

Why the per-type half is here and not deferred

#347 made the relation vocabulary derived automatically, with no human approving it. A derived relation type that never materializes once across a whole corpus is the cleanest available evidence that the derivation is wrong — and nothing in the system would currently notice. It is the reporting-only counterpart to #347's hard hygm.validation self-validation gate, produced by the same query that answers (1), and expensive to bolt on later.

Its real consumer is #353 (derivation quality) and #350 (reading the edges), not this ticket. Noted on #353.

Where it surfaces

In ReconciliationSummary (sessions-graph/reconciliation.py:140), alongside the infeasible-window fallback counter #348 put there — not as a log warning.

This confirms a plan revision #348 already forced rather than making a new one. The plan §2 says issues are logged as warnings and explicitly declines to thread results into sessions-graph's return types; #348 breached that for its fallback counter, leaving the plan inconsistent with itself. Both counters land in the same place, which is also where they are most useful — "N windows fell back" and "these 4 declared relation types never materialized" are one diagnosis from two angles.

The decisive argument is the eval: context-graph-eval's reconcile.py _tally already walks ReconciliationSummary objects, so this reaches the eval path for free. A coverage signal the eval cannot see does not help hit the eval metrics, and hitting them is the point.

---

Follow-ups

• Plan §2 gets two corrections: the LightRAGBackend line's claim (action unchanged), and the "return types unchanged" line (already superseded by Extraction-time constraints vs post-hoc validation #348).
• The derivation contract for LlmRecommendationStrategy #353 gains the per-type coverage signal as an input for judging a derived vocabulary.
• Map Notes record the standing preference: GLiNER2 is the primary backend and the target of adaptation; LightRAG is a retained, non-interchangeable alternative pipeline.
• Map Out of scope records that typing LightRAG's edges is not pursued.