Open Data

Constitutional + legal basis: the non-enclosure floor

Open data on the substrate is constitutionally grounded in SS-5 Commons non-enclosure-floor — a substrate-mandatory floor prohibiting decisions that enclose a class of resources — and in the EU Open Data Directive 2019/1024, which requires public-sector data to be both openly accessible and free at the canonical layer while permitting charges for value-added services on top.

The substrate models these as two separable axes. The access tier answers who may read; the commercial posture answers how the AI-readiness labour is compensated. Conflating them is the trap — a single is_public boolean answers neither cleanly.

The non-enclosure invariant. For an open data space, the canonical plane (original bytes + content + a basic manual/AI read path) is free, unmetered, and publicly readable regardless of commercial posture. Only the enrichment/retrieval plane (embeddings, the semantic graph, the metadata index, high-volume AI query) may be metered — and for an open space, only above a free baseline so the citizen/basic path stays free. The fee attaches to the labour of AI-readiness, never to the data. Metering the data itself is rejected as enclosure (unlawful for public-sector open data; violates SS-5).

This floor is structural, not procedural: guard:open-data-canonical-plane-unmetered (BLOCKING-from-day-one) asserts every commercial posture carries metersCanonicalPlane === false, that the open tier carries canonicalPlaneFree === true, and that the V016 open read policies are SELECT-only (open widens read visibility only — never a write or fee gate). Fee-gating the canonical plane of an open space is impossible by construction.

Axis 1 — access tier (who may read)

The access tier is declared at the data-space level, with per-node redaction layered on top as a reversible visibility overlay (see the dedicated section below). The open read principal spans two surfaces: any authenticated participant of any org (V016), and — on deployments that enable it — fully anonymous (logged-out) readers (V018; see the dedicated section below).

Generated from lib/registry/data-space-access-tiers-registry.ts · 2 closed tier(s) (widening requires a §ZCS amendment)

Axis 2 — commercial posture (how AI-readiness is compensated)

The commercial posture is a per-space configurable option the publisher elects — there is no hardcoded global default. The UI MAY suggest publisher-funded for open/government data (the open-data obligation is met and the AI-readiness labour is funded by the publisher, not the citizen), but the publisher chooses. Every posture below carries metersCanonicalPlane = false — that is the non-enclosure floor expressed at the policy layer.

Generated from lib/registry/data-space-ai-access-policies-registry.ts · 3 closed posture(s) (widening requires a §ZCS amendment)

Plane separation — where the free/paid boundary lands

Canonical plane (always free for open). The original bytes stay canonical in org_files; governed node content lives in data_space_nodes; a basic manual/AI read path resolves through local RLS. For an open space this plane is free, unmetered, and publicly readable — V016 adds the _is_open_data_space SQL helper plus permissive SELECT-only open read policies (no open INSERT/UPDATE/DELETE).

Enrichment / retrieval plane (optionally metered). Embeddings, the semantic graph, the metadata index, and high-volume AI query are the labour of AI-readiness. Only this plane may be metered, and for an open space only above a free baseline. Metering rides the existing §X impact-metering primitives (impact_metering_events) via lib/modules/data-space/ai-access-metering.write.ts, which throws CanonicalPlaneMeteringError if a caller ever attempts to meter the canonical plane.

Pricing is config-only (Rule 22). Quotes are computed by mapping the enrichment meter onto the §K usage_metered_flow pricing template (lib/modules/data-space/ai-access-pricing.ts). Every amount — including the free baseline — is sourced from runtime configuration (system_settings.billing.*); no currency literals live in code (guard:no-hardcoded-pricing).

Anonymous (logged-out) public read

For genuinely public open data — the “anyone can read without an account” stance — the substrate exposes a fully anonymous (unauthenticated) read surface under app/api/public/data-space/**: a directory of open spaces, a canonical read of one open space (its committed nodes), and a free, capped basic retrieval query. Migration V018 extends the SELECT-only open widening from the authenticated role to the anon role (three *_open_select_anon policies, FOR SELECT TO anon only); no anon write policy exists, so the anonymous path widens read visibility only — never a write or fee gate, and protected spaces stay invisible.

Deployment-gated. The anonymous surface is enabled by default on saas / on-demand deployments and disabled by default on sovereign tiers (on-prem / air-gapped / jv-bespoke) — derived from the deployment-modes registry, never a hardcoded subset — so a sovereign / closed-network deployment exposes no unauthenticated internet read surface unless its operator explicitly opts in (SOVERN_OPEN_DATA_ANON_READ). When disabled the routes return 404 (the surface is invisible, not a 403 leak).

Abuse controls + never billed. Anonymous requests are rate-limited per-IP (directory/read 60/60s, retrieval query 15/60s). The anonymous path is never billed — structurally, the anonymous edge module never imports the enrichment metering writer, so an anonymous request cannot enter the billable enrichment plane by construction. Higher-volume / agent-grade AI retrieval requires an authenticated, billable identity; a durable per-identity free-baseline quota is tracked at <horizon:data-space-open-data-anon-free-baseline-quota>.

Per-node redaction — reasoned, reversible, disclosed

An open data space sometimes needs to withhold an individual record — a page carrying personal data (GDPR), an embargoed draft, third-party IP, or a record under legal hold. The substrate models this as a visibility overlay, never a content mutation: the canonical record stays immutable in data_space_nodes; a separate append-only data_space_node_redactions row (V019) hides the node (and, by default, its subtree) from the public + anonymous read planes via the _is_node_open_redacted RLS helper. Lifting a redaction restores visibility — withholding is reversible by construction.

Withholding is never silent — the anti-enclosure floor for redaction. Per-node withholding on an open space could become quiet partial enclosure if it were invisible. It is not: every redaction carries a reason code from the closed registry below, and the public space page discloses, in aggregate, how many records are withheld and why (count by reason) — never the withheld content, but always the fact and the rationale. An operator-configurable warn ratio surfaces a prominent notice when a large share of a space is withheld, so heavy redaction cannot hide behind a clean-looking public view.

Generated from lib/registry/data-space-redaction-reasons-registry.ts · 5 closed reason code(s) (widening requires a §ZCS amendment)

The market arc

Most organisations do not have an AI problem — they have a knowledge-structure problem. The output here is not a data lake, a vector database, or a RAG pipeline; it is a governed data space where humans and agents participate, permissions apply, sources are traceable, and provenance exists. Open data spaces are a primary adoption pathway: the data problem is immediate, measurable, and already budgeted; the coordination opportunity emerges once the data space is established.

For public-sector publishers the deal is clean: publish the data openly and free (the obligation), and fund — or meter above a free baseline — only the AI-readiness that makes a hundred-thousand-document corpus genuinely navigable by an AI. The citizen keeps free access; the bulk/commercial re-user who consumes the AI plane pays for the labour, never the data.

Registry sources: lib/registry/data-space-access-tiers-registry.ts (2 tiers) · lib/registry/data-space-ai-access-policies-registry.ts (3 postures) · lib/registry/data-space-redaction-reasons-registry.ts (5 reason codes)

C-GG-23 trust-page-no-i18n — inline English literals · CONTRACT §ZCS · AGENTS.md Rule 31

guard:open-data-canonical-plane-unmetered (BLOCKING) · guard:open-data-redaction-overlay-only (BLOCKING) · guard:trust-open-data-page-matches-registry (BLOCKING) · guard:no-hardcoded-pricing (BLOCKING)