Last verified: 28 September 2026
Data Spaces
A Data Space is governed knowledge, not a free-form archive. Data enters through a metadata gate; the original bytes stay canonical in org_files; meaning is derived into span-provenanced semantic content; and the meaning graph is built from typed, attested relations. Immutability binds at commit — corrections happen through versioning and governed retirement, never silent deletion.
Governed ingestion
Data is never silently free-form-archived. It is admitted through a metadata gate: the original bytes remain canonical in org_files, and meaning is derived from those originals into org_semantic_content as span-provenanced embeddings — each carrying space_id / node_id / char_start / char_end so a unit of meaning points back to exactly where it came from.
Nodes form a Document → Provision → leaf hierarchy in data_space_nodes. Org-member-scoped per Rule 14 (environment_id fanout + restrictive environment-match policy); the module follows the substrate service → repository → PostgreSQL pattern with a typed event per mutation.
Lifecycle: immutability binds at commit (§3.8)
A node moves through a closed lifecycle. Immutability binds at committed; staging is the only tier that can be hard-deleted (the "wrong file" escape hatch). The closed lifecycle-state enum is { staging, committed, retired, erased }:
staging — hard-deletable · A freshly-staged node may be discarded outright (discardStagingNode rejects any node that has left staging). This is the only destructive escape hatch.
committed — immutable · commitNode promotes a staging node to committed exactly once; committed sources are never silently mutated or deleted. Corrections happen through versioning.
retired — soft retirement · retireNode is the governed-removal path for a committed node. The row survives for audit; it is simply no longer operative.
erased — privileged tombstone · A privileged erasure tier reserved for right-to-erasure obligations; the node becomes a tombstone rather than disappearing from the chain of custody.
Typed attested relations (§3.5 / D6)
The meaning graph is built from typed semantic edges in data_space_relations. Every relation carries a provenance and a derived trust_level. The substrate never accepts a caller-supplied trust level — it is derived from provenance, so AI only ever suggests and import is the highest-trust source:
imported → authoritative · steward-asserted → asserted · ai-suggested → suggested
relation_type is validated against the closed base vocabulary (DATA_RELATION_TYPES) at the application layer — unknown types are rejected. The column is stored as text (not a DB enum) to keep a future per-domain extension path open under closed-canon discipline.
Closed base relation vocabulary
Generated from lib/registry/data-relation-types-registry.ts · 9 closed relation types (per-domain extension is a future concern, deliberately not implemented at v1)
cites — Cites
The source node references the target node as a citation / authority.
directional (from → to)
amends — Amends
The source node modifies the target node (e.g. an amending instrument changes an article).
directional (from → to)
supersedes — Supersedes
The source node replaces the target node as the operative version.
directional (from → to)
repeals — Repeals
The source node revokes the target node, removing it from force.
directional (from → to)
implements — Implements
The source node gives effect to the target node (e.g. a regulation implements a directive).
directional (from → to)
derived-from — Derived from
The source node was produced from the target node (extraction, summarisation, transformation).
directional (from → to)
contradicts — Contradicts
The two nodes are in tension; the relation is symmetric (no fixed orientation).
symmetric (no fixed orientation)
references — References
The source node mentions the target node without asserting authority (a soft cross-link).
directional (from → to)
part-of — Part of
The source node is a structural component of the target node (e.g. a provision is part of a document).
directional (from → to) · inverse: references
Accepted ingestion formats
Every accepted format flows through the same canonical ingestion pipeline: parse → segment → stage → embed / FTS index → governed retrieval. No format receives a bespoke pipeline — adding format support means adding a parser that produces the same ParseCanonicalTextResult shape. Two routing tiers exist: in-runtime formats are parsed in-process without external dependencies; extraction-sidecar formats delegate heavy decoding to the operator-run sovereign extraction sidecar (SOVERN_EXTRACTION_URL). Sovereign-safe formats ingest faithfully even when the sidecar is absent.
Generated from lib/registry/ingestion-formats-registry.ts · 17 accepted formats (closed at v1 — additions require a §SS amendment)
Registry source: lib/registry/data-relation-types-registry.ts (9 closed relation types) · schema: migrations/V008__data_space.sql · module: lib/modules/data-space/
C-GG-23 trust-page-no-i18n — inline English literals · §SS Data Expression · AGENTS.md Rule 30
guard:data-space-canonical-immutability (BLOCKING) · guard:data-space-relation-provenance (BLOCKING) · guard:trust-data-spaces-page-matches-registry (BLOCKING)