The predecessor AirGap Controller, Time host, and shared DAL sources are withdrawn by OK-5 under the approved posture split. Platform owns generic environment-state custody; the surviving policy/replication and OfflineKit time-verification libraries own interpretation and verification. This does not retire the exchange libraries or claim the separate live stop/schema window has run. Earlier host instructions below describe the predecessor. See the current split in docs-archive/modules/export-center/consolidation-design.md.

Microservice → database ownership matrix

Status: historical baseline with individually dated follow-up evidence + Accepted target (ADR-039 rev-13). Sources: devops/compose/docker-compose.stella-services.yml, live stellaops-postgres catalog (read-only), AddStartupMigrations sweep over src/, the data-and-stores role playbook (AGENTS.md — Memory). src/ wins over this document; rows marked (verify) lack a confirmed code anchor.

Source verification (2026-09-09)

Verified against 286391582b4d00782ae61002941079d40ef8c68e; current unresolved work is routed by the estate board. The older physical inventory and per-family rows below retain their own evidence dates. They are not a fresh census of the running estate.

No deployed ownership or closure row was changed by this source verification.

1. Historical physical baseline (measured 2026-07-22)

• One shared instance stellaops-postgres (postgres:18.1), one volume (99.25 GB), three databases: stellaops_platform 91 GB, stellaops_authority 252 MB, postgres 7.7 MB.
• Every service except Authority connects with the same STELLAOPS_POSTGRES_CONNECTION (→ stellaops_platform). ~46 service schemas share that database.
• Vulnerability data plane inside stellaops_platform: vuln 71 GB, vex 9,625 MB, vexhub 5,908 MB, concelier 2,322 MB ≈ 89 GB = 97.8%. Everything else totals < 3 GB (largest: scanner 2,110 MB, advisoryai 271 MB, timeline 199 MB; platform itself 2,024 kB).

Currency note (re-measured 2026-08-03, read-only, same lab database). These sizes move a lot: vuln 24 GB, concelier 1,551 MB, vex 3,968 kB, vexhub 680 kB ≈ 25.5 GB, scanner 2,701 MB. The lab was reset between the two readings, so the 2026-07-22 figures above are a fuller-corpus snapshot and neither reading is the production estate. Do not use either as a reclamation or headroom target — the SPRINT_20260722_008 VULN-G1 window measures the target database at step 0; see the G1 execution-window runbook §1–2.

Source boundary update (CM-6, 2026-08-26; verified against d3358c84319b0da835e944d70f360f7df526d9c5). Platform no longer reads RO topology tables or carries the RO migration plugin. It reads active tenant UUIDs from its own shared.tenants, then consumes the tenant-scoped RO owner API described in X22 below. Re-verify with rg -n "ReleaseOrchestratorMigrationModulePlugin|PostgresTopologySourceReader" src/Platform (the plugin name must return zero hits; the whole plugin mechanism was deleted 2026-09-14, PLT-4) and rg -n "topology-snapshot" src/Platform src/ReleaseOrchestrator. Platform’s own 098_v1_release_topology_inventory_projection.sql (Startup band) creates the release.topology_* projection tables in stellaops_platform.

2. Deployable → schema matrix

Replica sets (web/worker/init of one service) are one row — they legitimately share the owner database. Wave = adoption wave from ADR-039 (1 = vulnerability plane now, 2 = large/high-churn next, 3 = small batch moves). Risk = migration risk of the move itself.

The Cluster column is historical as of 2026-08-14 — read it as “which cluster this row was once planned for”, not as current topology. SPRINT_20260810_002 (PTC-1…PTC-5) consolidated the estate onto ONE PostgreSQL server per the ADR-039 P1 topology clarification: “own physical database” means a logical database + its own role on the shared installation cluster, and a dedicated server is an optional scaling choice, not the default. So a vulndata value below names a retired cluster (STOPPED 2026-08-14, volume kept as the repoint rollback), and every stellaops_* database in this table that exists today lives on stellaops-postgres / db.stella-ops.local. The boundary is the per-database role plus REVOKE CONNECT, not the container — see §5.4 for the measured census.

Notes:

• “One microservice, several replicas” (scanner-web/worker, excititor-web/worker, export web/worker, evidence-locker web/worker, riskengine web/worker, packsregistry web/worker, advisory-ai web/worker) share one owner database by design. Concelier vs. Excititor vs. VexHub are independent deployables and get independent databases — this matrix does not reinterpret database-per-service as schema-per-service.
• The vuln schema today mixes two ownership categories (Concelier canonical advisory source vs. rebuildable serving projection); in the target both live inside the single hub database stellaops_vuln as internal schemas (ingest/facts vs consensus/dist) per the v2 design — the rev-1 two-database split (stellaops_concelier + stellaops_vuln) was superseded by D2.

3. Cross-service SQL inventory (violations to burn down)

X1–X17 were re-verified by EST-2 on 2026-09-10 (Europe/Sofia): nine closures, one bar-dependent result and seven remaining source entries. The report carries current anchors, owning-row states, commit/test links and executed checks. It closes the verification task, not the estate-wide empty-register gate.

Approved cross-service SQL exception register (ADR-039 P5): the previously named X6, X8 and X9 transitional approvals have reached their closure conditions and are removed from this approval list by the 2026-09-10 verification. This does not approve any remaining source violation. The target SQL-exception register is empty; new raw-SQL approvals require an ADR-039 amendment. X22 is the intended replacement pattern: an explicit, producer-owned HTTP read contract into a consumer-owned rebuildable projection, not permission to connect to the owner database.

X10 REMOVED from the approved list 2026-08-17 (SPRINT_20260722_009 DOC-4/DOC-5 stage 4). It was approved “until D11 lands”; D11 has landed and the reach is gone, not merely dispositioned — the five cross-schema checks, the information_schema.tables enumerator and the eleven-schema expected set are all deleted (0daa7e086c). Its ROW above stays, annotated CLOSED, per the convention X7 and X21 use: the table is the inventory and keeps its history, this sentence is the standing APPROVAL and must not name a contract nobody holds.

X7 also removed here, because its own row already reads “CLOSED 2026-08-17 — the cited anchor no longer exists” with the compose evidence beside it; leaving it in the approved list contradicted the row. Flagged rather than silently taken: X7 belongs to the Authority/D10 lane, so if that closure is premature the sentence is where to put it back.

4. Shared-fallback burn-down — COMPLETE (2026-09-14)

The generic STELLAOPS_POSTGRES_CONNECTION has no live consumer anywhere in the estate, and the transitional pin register that tracked its retreat is EMPTY. ADR-039 P3 is discharged.

The burn-down ran 21 service definitions → 11 → 1 → 0. The last two steps are worth separating, because they were different defects wearing the same variable:

• SPRINT_20260722_021 PLT-3 (2026-09-13) cleared the last services that used it as their OWN storage pointer, ending with Platform itself moving to STELLAOPS_POSTGRES_PLATFORM_CONNECTION.
• SPRINT_20260913_001 ORP-3 (2026-09-14) cleared the survivor that used it to read SOMEBODY ELSE’s data: integrations-web held PolicyStorage__Postgres__ConnectionString pointed at stellaops_platform.policy, a schema frozen on 2026-08-15 when Policy moved to stellaops_policy. There was no lawful repoint — provision-service-database.sh revokes CONNECT from PUBLIC and grants it only to the owner role — so the read moved to Policy’s owner API (POST /api/v1/policy/gate/decisions/by-digest, policy:read, tenant from the bearer).

Two guards hold the floor, and they are different in kind:

• Compose_PostgresConnections_AreOwnVariableOrPinned is the shrink-only ratchet. It would have accepted a NEW service consuming the variable with a NEW pin, reading that as transitional debt.
• Compose_GenericConnectionVariable_HasNoLiveConsumerAndNoPin is the absence pin added with the final deletion. It fails on any live consumer AND on any pin, so reopening the programme requires deleting a named test and saying why.

One residue, out of scope and owned elsewhere: docker-compose.local-export-worker-rollback.yml still carries ConnectionStrings__Default: ${STELLAOPS_POSTGRES_CONNECTION}. It is the recorded rollback posture of the LIVE stellaops-export-worker container (RAR-7), so it is deliberately a frozen historical value rather than a live pointer — but it is a real estate-wide grep hit and it belongs to the OfflineKit consolidation lane, not here.

5. Full rename map — every container: current → target

Legend: unchanged = same name/src path. (verify) = project name not yet confirmed against a code anchor — the owning program’s S0 task confirms it. D12 DAL renames (…Storage/…Database → StellaOps.<Service>.Persistence) land with each service’s own wave, never out-of-band. “shared DB” = stellaops_platform (name kept — owner correction 2026-07-22). The container/instance half of that naming plan is WITHDRAWN: the owner DECLINED it on 2026-09-13 (SPRINT_20260722_021 PLT-2, ABANDONED). The bare stellaops name is NOT applied at the container level — the Platform service container stays stellaops-platform, which is what container_name: ${STELLAOPS_ESTATE_PREFIX:-stellaops}-platform already renders, in the same shape as every other service. Grounds are recorded in PLT-2’s status; the load-bearing one is that nothing in the estate resolves Platform by container name (every consumer uses the platform.stella-ops.local alias), so the rename bought no behaviour and would have made Platform the sole exception to the prefix convention.

5.1 Vulnerabilities program (sprints 003–008)

5.2 Family merge programs (sprints 010–016)

D-EVD3-14 — the Evidence DAL name (corrected 2026-08-10, EVD-3 Stage B). The attestor row above originally read StellaOps.Evidence.Persistence. That assembly name is already taken by src/__Libraries/StellaOps.Evidence.Persistence, an unrelated shared library owning a different evidence schema (generic evidence records, EF Core, once migrated centrally by platform-web’s EvidenceMigrationModulePlugin — deleted with the plugin mechanism 2026-09-14, PLT-4) and compiled by Platform.Database. Two projects cannot share an assembly name, so the merged DAL is StellaOps.Evidence.Persistence.Consolidated, following the Notify / Timeline / ReleaseOrchestrator / Integrations / CredentialStore precedent. The two evidence schemas never collide — one lives in the shared platform database, the other in stellaops_evidence, where it holds the migration ledger pair plus the Evidence-owned Timestamp Assurance state from migrations 002/003. Applies to the evidence-locker-web + worker row too, which points at the attestor row via “merged ↑”.

5.3 Same service, new database (Waves 2–3; D12 DAL rename where deviating)

Owning programs: Scanner → SPRINT_20260722_017; ReleaseOrchestrator → 018; Signer → 019; Platform → 021 (endgame); Graph+ReachGraph → 023; Integrations → 024; the Registry family (registry-web + registry-token) → SPRINT_20260803_004 (ADR-041 OD-2 removed registry-token from 024’s scope); EvidenceLocker → 011; doctor-web → retirement via 009; remediation → archived; ExportCenter + AirGap (+ Mirror.Creator) → 025 (OfflineKit, owner-approved); every other row → SPRINT_20260722_020 (batch).

Evaluation families (VexLens fold, Reachability, Offline/exchange): SPRINT_20260722_022.

5.4 No database / infrastructure (unchanged unless noted)

Bench/tools data (groundtruth, public; analytics is VulnCorrelation) is non-runtime. The predecessor BinaryIndex host did migrate/serve golden_sets, but its approved retirement disposition is fixtures/bench (014 D-BIN3-6/A6), never a hub runtime schema. BIN-9 verified that the only predecessor golden-set rows are exact committed reference seeds, with no authored definitions, targets or audit records. The original schema remains pending separately authorized DROP; retaining it does not require creating a replacement runtime database.

5.5 Measured role boundary (census 2026-08-14, SPRINT_20260810_002 PTC-6)

The ownership boundary on a shared server is the per-database role plus REVOKE CONNECT, so it has to be demonstrated, not asserted. Re-measure with bash tools/scripts/deploy/postgres/probe-database-isolation.sh (read-only; SELECT 1 per cell).

Six login roles on stellaops-postgres: stellaops (superuser), policy, replay, signals, timeline, vuln. Six further *_admin roles (authority_admin, findings_ledger_admin, notify_admin, policy_admin, scheduler_admin, vex_admin) are NOLOGIN and carry no session.

A *_admin role is provisioned by the install path, never by a migration — a migration runs as the service’s own NOCREATEROLE role and cannot create one. The requirement, the from-scratch failure it prevents (42501 permission denied to create role) and the exact statement to run on an operator-managed cluster are stated once, in INSTALL_GUIDE.md - PostgreSQL roles the install path must create. Currency, 2026-09-14 (SPRINT_20260914_003 JEF-1): 05-service-admin-roles.sql provisions authority_admin (AUTH-26, 2026-09-09) and scheduler_admin (moved there when the platform scheduler block left 00-v1-baseline.sql; the JobEngine 001 baseline guards on that role). The existing 00-v1-baseline.sql still provisions findings_ledger_admin. The remaining Notify, Policy and VEX admin-role requirements and the installer verification command are recorded in the install guide above.

Isolation matrix: 25/25 PASS (5 service roles × 5 service databases) — each role reaches exactly its own database; all 20 cross-database attempts refused.

Currency (re-measured 2026-08-23, read-only). The census above is the frozen PTC-6 reading. The live login-role set is now eleven: stellaops (superuser) plus policy, registry, release_orchestrator, replay, sbomservice, signals, signer, timeline, unknowns, vuln. The four wave-3 roles this sprint owns were re-probed against all twelve stellaops_* databases with has_database_privilege(<role>, <db>, 'CONNECT'): timeline, signals, sbomservice and unknowns each return true for exactly their own database and false for the other eleven — a 4 × 12 slice that is exactly diagonal, 44 refusals and 4 grants. Note platform and authority still connect as the superuser and therefore sit outside this boundary by design, as PTC-6 recorded.

Two honesty caveats a reader must not gloss:

• platform and authority are outside the role boundary. Both still connect as the stellaops superuser, which bypasses REVOKE CONNECT by design, so they are excluded from the matrix rather than passing it. Their own separation programs close this.
• A passing policy cell proves the boundary exists, not that policy is behind it. Measured 2026-08-14: the live policy-engine container’s Postgres__Policy__ConnectionString names Database=stellaops_platform;Username=stellaops, where the real projection lives (policy.vuln_gate_current = 10.5M rows). POL-F6 has not cut over; that is SPRINT_20260722_007’s work, not a topology-window regression. Updated later the same day: stellaops_policy is no longer empty — a cutover attempt converged its schema (59 base tables + 7 views in policy, 7 in eventing), created the first policy pack and seeded 906,000 gate rows before rolling back. Those rows carry no consumer checkpoint, so they are a resumable partial seed rather than a live projection; nothing reads that database today. The blocker the attempt found, because it changes what the next window must do first: Policy resolves tenant UUIDs from Platform’s shared.tenants, so on stellaops_policy a gate evaluation decides and attests correctly and then 500s writing decision history. The exit is SCR-3 (SPRINT_20260722_027) — flip Catalog:Replication:Tenants so Policy resolves tenants from its own replica of Authority’s catalog. Sequence: SCR-3 first, verified on the shared database; then POL-F6.

Two-consumer trap when re-running the probe: it derives pairs from STELLAOPS_POSTGRES_<SVC>_CONNECTION lines in devops/compose/.env, but the vulnerability hub’s connection is assembled in docker-compose.vulnerabilities.yml and has no .env presence at all since PTC-6 dropped VULN_POSTGRES_HOST. A plain run therefore silently reports a 4×4 matrix and omits vuln. Feed it an env file built from .env plus the value read from the live container (live truth, not a hand-copied duplicate that can drift), and delete that file afterwards:

cp devops/compose/.env /tmp/probe.env
docker inspect stellaops-vulnerabilities-web --format '{{range .Config.Env}}{{println .}}{{end}}' \
  | grep '^STELLAOPS_POSTGRES_VULN_CONNECTION=' >> /tmp/probe.env
bash tools/scripts/deploy/postgres/probe-database-isolation.sh --env-file /tmp/probe.env && rm /tmp/probe.env

6. Non-database owned state (P16 / DC-27 / DC-28)

Databases are not the only shared state: Valkey keyspaces/streams and object-store buckets/prefixes have named owners, a prefix convention, and P7 budgets. The FULL inventory is SPRINT_20260722_028’s deliverable — the rows below are the ones their owning task has already landed, so nothing waits on that sweep to be recorded.

6.1 Valkey keyspaces / streams

Live inventory 2026-08-02 (SPRINT_20260722_028 NPS-1: read-only SCAN + MEMORY USAGE against the lab stack — 882 keys, 19.3 MB total; re-verify against a production-shaped estate before treating counts as budgets). Convention: keys under {service}:, streams under the existing stream:{name} form; cross-service consumption of another owner’s stream is a DC-06/DC-07 envelope contract, never an ad-hoc key read.

Cross-service ad-hoc key reads found: none. Every prefix has exactly one writing owner; the only cross-service touch points are the router transport queues (that is their job) and consumer-group reads on the streams, which is the sanctioned contract. Consumer groups in compose: 40 distinct Router__Messaging__ConsumerGroup values, one per service — matching the convention.

6.3 Named volumes (round-22 scope: ALL persistent non-Postgres state)

Live docker volume ls sweep 2026-08-02 (lab; compose project prefix stripped; scratch/QA projects excluded). Rule: every named volume has an owner and a class; *-plugin-scratch volumes (11 found: advisoryai, authority, concelier, doctor, excititor, integrations, notify, policy-messaging, scanner, scheduler, +) are ephemeral by contract (tmpfs-mode plugin staging) and carry a standing infra-exempt note as a family.

Method correction 2026-09-15 (NPS-3) — read this before trusting the section’s completeness. The inventory above was built from a live sweep of one lab, so it could only ever cover what that lab happened to be running on 2026-08-02. A declaration-side sweep — every top-level volumes: entry across devops/compose/*.yml, diffed against this table — had never been run. Running it found fourteen shipped states with no row at all, including two custody surfaces (stellaops-cryptopro-keys, openbao-data), three volumes live in the estate right now (findings-advisory-corpus, vulnerabilities-corpus-publications, packsregistry-upload-data), and one object-store bucket missing from §6.2 (registry-content) whose own compose comment calls it P16-owned. Every overlay that was switched off in the lab — openbao, cryptopro, rekor-tiles, tile-proxy, consul — was invisible to the original method by construction. Those rows are added below and in §6.2.

The consequence for anyone auditing P16: SPRINT_20260722_021 PLT-4 ticked its P16 audit criterion on “All 15 §6.1/§6.2 rows name an owner”. That counted rows in this table, not stores in the estate, so it could not have detected an absent row. A future audit must diff declarations against this table, not read the table back to itself. The mechanical form of that check belongs in tools/scripts/validate/ with a --self-test (AGENTS.md §2.13), and is carried by SPRINT_20260915_001 OSM-9.

6.2 Object-store buckets / prefixes

Live inventory 2026-08-02 (SPRINT_20260722_028 NPS-2: lab filer lists ONE provisioned bucket at 33.6 MB total store; the rest are configured-but-unprovisioned env keys that materialize on first write). Rule: cross-service object access goes through the owner’s API or the digest contract (ADR-033/035) — never raw paths. Sweep result: zero cross-owner raw-path consumers — every bucket’s S3 access lives in its owning family’s tree.

Explicitly NOT decided here (owner R3): long-term generation retention for verdict replay — i.e. whether a verdict pins its corpus generation in the evidence plane so it stays replayable after the working set has rotated. The last-N working set above is a matcher-host guarantee, not an evidence guarantee; CorpusGenerationStore.ReadRetained says so in its failure message rather than implying replay works forever. Recorded by SPRINT_20260722_005 VULN-D4 (2026-08-02).