03 — IU KG Relationship Enrichment Readiness & Design (Điều 39)

Refines the predecessor KG pack with live column-level evidence. Recommendation unchanged in spirit, sharper in detail: enrich iu_relation in place + a governed read-only projection. No hidden second graph SoT. Vector stays OFF.

---

1. Live substrate (column-level, 2026-05-28)

iu_relation — UUID-native, 60 rows (all contains/active)

Columns: id uuid, source_unit_id uuid, target_unit_id uuid, relation_type text, relation_subtype text, relation_status text, operation_ref uuid, source_version_id uuid, target_version_id uuid, metadata jsonb, valid_from tstz, valid_to tstz, created_by text, created_at tstz.

• Has: temporal validity (valid_from/valid_to), version pinning (source/target_version_id), an operation link (operation_ref), a free metadata jsonb, and created_by (weak provenance).
• Lacks (vs Đ39 KG requirements): dedicated provenance, confidence, evidence_source, assertion_mode (asserted/inferred), negative_knowledge flag, override_of, explanation, feedback.

universal_edges — integer-keyed, 2199 rows

Columns include id integer, source_collection/source_id(integer)/source_code/source_composition_level, mirror target cols, edge_type/edge_subtype, weight numeric, source_info, is_auto_managed bool, symmetry_group_id uuid, metadata jsonb, valid_from/valid_to, status, _dot_origin, date_created/updated, confidence numeric, valid_time tstzrange, provenance jsonb.

• Correction to prior notes: universal_edges does carry provenance, confidence, and valid_time — it is already shaped to Đ39 v2.3 A8 ("provenance-or-quarantine"). But its keys are integer (source_id/target_id) — IU is UUID-native — so it structurally CANNOT hold IU relationships. It is the KG for integer-keyed collections, not for IU.

2. The core tension

Two graphs exist: a rich, Đ39-shaped, integer-keyed universal_edges (2199 rows, excludes IU) and a thin, UUID-native iu_relation (60 rows, containment only). Migrating IU into universal_edges would either require breaking its integer-key contract or maintaining a UUID↔integer mapping shim — either creates a hidden second SoT for IU relationships. That is forbidden.

3. Recommended architecture

Enrich iu_relation in place + expose a read-only UNION projection. Do NOT migrate IU into universal_edges.

1. Enrich iu_relation (additive columns, nullable, backfill-safe) to reach Đ39 parity:
   • provenance jsonb (source agent/run/manifest; required-or-quarantine per Đ39 A8).
   • confidence numeric (0..1).
   • evidence_source text / evidence_ref uuid.
   • assertion_mode text CHECK in (asserted,inferred) default asserted.
   • negative_knowledge boolean default false (records "X is NOT related to Y").
   • override_of uuid (self-FK; supersession of a prior relation).
   • explanation text (why this edge; for inferred edges).
   • feedback jsonb (human/agent correction signal).
   • Expand the relation_type vocabulary beyond contains toward the 8 information-atom relation rules: IDENTITY, BELONGS_TO, CONTAINS, DEPENDS_ON, USED_BY, TRANSITIVE, PEERS, SIMILAR (constrain via a vocab table / CHECK, not free text).
2. Governed read-only projection — a VIEW v_kg_edges_all that UNIONs universal_edges and iu_relation into one shape (src_kind, src_ref, tgt_kind, tgt_ref, edge_type, confidence, provenance, valid_time, status), normalizing UUID vs integer refs into a typed (kind, ref) pair. The view is read-only and derives from the two SoTs; it is NOT a third table. This gives 4 Mothers and the KG one query surface without a hidden SoT.
3. Vector stays OFF. iu_core.vector_sync_enabled is NEVER-FLIP. KG enrichment is relational only; no embedding/Qdrant work.

4. Why this avoids a hidden second graph SoT

• iu_relation remains the only writer/SoT for IU edges.
• universal_edges remains the only SoT for integer-keyed edges.
• The projection is a VIEW (no storage, no independent writes) — it cannot drift from its sources.
• No UUID↔integer shim table is created (that would be a hidden mapping SoT).

5. How 4 Mothers will use enriched relations later

• MOT (transforms) emits inferred edges with confidence + explanation + provenance → quarantined until reviewed.
• MOW (workflow) reads v_kg_edges_all to drive dependency-aware tasking.
• MOUT publishes asserted edges with full provenance.
• Negative-knowledge + override columns let the KG record corrections without deleting history (Đ30/Đ31).

6. DOT commands needed (design-time list; build later, governed)

• dot_iu_relation_create (asserted edge, requires provenance) — additive, mutating.
• dot_iu_relation_infer (inferred edge, requires confidence + explanation, lands quarantined).
• dot_iu_relation_validate / dot_iu_relation_resolve_all (read; parity with sql_link pattern).
• dot_kg_edges_project (read; materialize-free query over v_kg_edges_all).

7. Live-readiness matrix

Capability	iu_relation today	After enrichment	universal_edges
UUID-native IU edges	✅	✅	❌ (integer)
Containment	✅ (60)	✅	n/a
Semantic types (8 rules)	❌ (only contains)	✅	partial
Provenance	❌ (only created_by)	✅	✅
Confidence	❌	✅	✅
Temporal validity	✅ (valid_from/to)	✅	✅ (valid_time range)
Inferred/asserted	❌	✅	via metadata
Negative knowledge	❌	✅	❌
One query surface	❌	✅ (projection view)	n/a

8. Implementation authority pack (DEFER — design-first)

• Phase 1 (additive, low risk): ALTER TABLE iu_relation ADD COLUMN ... for the 8 enrichment columns (all nullable). No backfill required; existing 60 rows stay valid. Reversible (DROP COLUMN). Author + DRY-RUN rollback, COMMIT small, prove durability in a fresh connection.
• Phase 2: relation_type vocab table + CHECK; do NOT retro-reclassify the 60 contains rows without review.
• Phase 3: v_kg_edges_all projection VIEW (read-only).
• Phase 4: DOT commands (§6), each with a catalog row.
• Đ39 A8 enforcement: make provenance required for new edges (warn → block_new) the same staged way as P-pub (doc 05) — do not retro-block the 60 legacy rows.

9. No-go conditions

• Do NOT migrate IU rows into universal_edges.
• Do NOT create a UUID↔integer mapping table as a relationship store.
• Do NOT flip vector_sync_enabled.
• Do NOT hard-block legacy edges lacking provenance (stage it).
• Do NOT let the projection become a writable/materialized third SoT.