Semantic Registry

The API name for the shared nine-hub graph store is semantic_*:

semantic_nodes
semantic_edges
semantic_backing

This is not a replacement for hub payload tables. Events, anomalies, journals, rules, infra observations, QA behaviours, suites, tests, and wiki pages keep their own tables or files. The semantic registry is the cross-hub index that an agent can query when it needs the shape of the system.

Tables

semantic_nodes stores one row per canonical hub object:

kind: one of idea, behaviour, implementation, suite, test, anomaly, infra, event, journal
id: stable hub-local id
title, summary, properties_json: compact read model fields

semantic_edges stores sanctioned graph relations. Writes are validated against @cv/graph, so relation shortcuts do not enter D1.

semantic_backing stores why a node or edge is real: markdown, feature, code, test, config, db-row, provider-event, generated, or other. There is no permanent grounding_status; missing backing is an integrity finding.

Compatibility

ops_hub_edges is now legacy/compat storage. New Ops edge writes enter semantic_edges and are mirrored to ops_hub_edges while older readers still exist. The migration endpoint copies legacy edge rows into semantic_edges without inventing fake nodes or fake backing.

The long-term consolidation is:

semantic_edges becomes the canonical edge table
ops_hub_edges can be removed after all readers use /semantic/edges
domain tables remain the source for payload depth
semantic_backing links domain rows, files, and provider evidence back to nodes

Integrity

GET /semantic/integrity reports:

dangling edges whose source or target node is not in semantic_nodes
nodes without backing evidence in semantic_backing
nodes missing required local graph links from @cv/graph

Those are findings for repair, not alternate node states.