Saltar al contenido principal

dataspace

Since v1.31.0 · Top-level declaration

Grammar​

dataspace <Name> {
    # Body is intentionally open at the parser level — the v2.0.0
    # tenant model + cross-tenant proof obligations are enforced
    # in downstream v1.31.0 column-proof checks, not in parse.
}

dataspace declares a named, isolated data namespace that holds a related set of axonstores. Where axonstore declares one typed store, dataspace declares the namespace every store within it shares — multi-tenant by construction, with cross-tenant proof obligations enforced by the v2.0.0 column-proof discipline.

The dataspace is the unit of tenancy in the data plane: a write to an axonstore at dataspace D under tenant T cannot be read by tenant T' even at the SQL level (the column-proof mandates tenant_id filtering on every query against HIPAA/GDPR/PCI-tagged stores).

Surface​

dataspace is a top-level declaration. It is not nested inside an axonstore or manifest.

dataspace ClinicalData {
    # The dataspace body is open at the parser level. Future
    # cycle increments will land typed fields here (retention,
    # cross-store query policies, etc.). For now the dataspace
    # is a reference target: axonstore declarations under this
    # dataspace cite it for cross-store consistency proofs.
}

Anatomy​

Header — dataspace <Name>​

A PascalCase identifier unique within the module. Common patterns: per-domain (ClinicalData, BillingData, AuditData), per-region (USData, EUData, APACData), or per-tenant-class (SharedTenants, DedicatedTenants).

Body — { ... }​

The body is currently open at the parser level: the parser accepts any content + skips it structurally. This is intentional — the v2.0.0 + v1.31.0 cross-store proof discipline sits above the parser, and future cycle increments will land typed fields (e.g. retention: 7y, region: "us-east-1", cross_query_policy: deny_join).

Runtime behaviour​

dataspace lowers to a DataspaceDefinition IR node. At deploy time, the runtime registers the namespace; every axonstore that references the dataspace is mounted within it.

The cross-tenant proof obligation: any compliance-tagged axonstore (HIPAA, GDPR, PCI_DSS, SOX) inside a dataspace MUST carry a tenant_id column. The v1.31.0 column proof at parse time enforces this; runtime reads/writes that don't filter on tenant_id are rejected (cross-tenant data movement is a shield breach, not a runtime fault).

Audit rows: every cross-dataspace operation emits dataspace:<source>:<dest>:transfer with full lineage so data movement between namespaces is reviewable.

What this primitive is NOT​

  • Not an axonstore. An axonstore is one typed store; a dataspace is the namespace multiple stores share.
  • Not a database. Multiple dataspaces can live on the same physical backend — the namespace is logical, not storage-bound. The v1.31.0 isolation discipline does the work.
  • Not a manifest. A manifest deploys infrastructure (resources + fabric); a dataspace declares the data-plane namespace those stores live in.
  • Not optional for multi-tenant deployments. Production multi-tenant AXON programs declare a dataspace per tenancy policy; without one, the v2.0.0 column proof falls back to permissive mode (audit row axon-W012 warns).

See also​

  • axon://primitives/axonstore — typed stores within a dataspace.
  • axon://primitives/manifest — infrastructure deployment layer (orthogonal to dataspaces).
  • axon://primitives/pix — provenance chain (often one per dataspace).
  • axon://compliance/gdpr — region-locked dataspace pattern.
  • axon://logic/flow_composition — when to declare multiple dataspaces vs. one.