Cloud infrastructure

The infrastructure that runs SoulMap sits on Google Cloud, owned by the Google Workspace organisation neumatics.eu, with workload separated into dedicated projects under a platform/ folder and a neumatics-network-host Shared-VPC project under shared-services/. Every CMEK-supporting resource is encrypted with a key from a single keyring in europe-west4. AlloyDB was the operational store, run paused by default whenever the product did not need it awake (posture superseded — its retirement was decided on 2026-08-04 and is pending execution; runbook docs/runbooks/alloydb-retirement-2026-08-04.md); per-domain Cloud Run services replace the old functions/main.py monolith; Datastream streams change-data from AlloyDB into BigQuery; an aggregated org-level audit sink lands in a sealed neumatics-audit-logs project that no application service can reach. On top of all of this rode the first-generation calibration pipeline that produced the Phase-1 corpus; its scoring layer was decommissioned as a runtime scorer on 2026-08-04, and its shakedown convergence receipt was withdrawn as validation evidence on 2026-08-20 (see validation). All calibration evidence on this estate, of either generation, is from synthetic personas; no human being has been measured.

This is the reviewer-grade view. The methodology that the calibration pipeline serves lives at /about/science. The full per-report deliverable surface, including the proprietary IP that does not belong in a public document, sits in a passkey-gated reports tier, available on request.

The pages below are written against what is actually deployed, with infra/, services/, src/lib/api-helpers.ts, and apphosting.yaml as the source of truth. Where Foundation v1 names a commitment that has not yet shipped (Knowledge Catalog tagging, the Firestore region cutover), the pages say so explicitly with a ⏳.


What you'll find here

PageWhat it coversTypical read
ArchitectureThe block diagram across two layers — the Foundation v1 platform (Workspace org, projects, AlloyDB, BigQuery datasets, KMS keyring, Shared VPC + VPC-SC, Datastream CDC, per-domain Cloud Run services, audit sink) and the calibration pipeline (Cloud Workflows + Vertex Batch + Custom Training) that runs on top. The service-choice rationales behind each non-default pick.18 min
OperationsThe AlloyDB cost-control plane (pause-by-default; posture superseded — retirement decided 2026-08-04). The BACKEND_ROUTING per-route cutover layer in src/lib/api-helpers.ts. The PAM-mediator service that injects per-grant delays. The audit-alerter Cloud Run job. EU residency. The cohort-keyed calibration profile registry. Idempotency under retry.14 min
Cost engineeringThe platform run-rate (~€100–150/mo combined; the AlloyDB pause-by-default line is historical — retirement decided 2026-08-04). The eight calibration-pipeline cost levers from Phase-1 (unchanged by the foundation). The local QA harness as the unconventional ninth lever.17 min
ReceiptsWhat landed in the Foundation v1 refactor and what is still in flight. The Phase-1 calibration shakedown narrative compressed to one page: 18 workflow smokes + 5 trainer probes uncovered 27 bugs across 8 categories. (The final probe's convergence receipt was withdrawn as validation evidence on 2026-08-20 — it diagnosed a since-decommissioned scoring layer.)9 min

What we shipped, summarised

Foundation v1 — workload projects live
3

neumatics-prod, neumatics-audit-logs, neumatics-network-host — Workspace-rooted, CMEK across the estate

Monolith decomposed into per-domain services
1,461 LOC

functions/main.py monolith replaced by per-domain Cloud Run services; per-route cutover via BACKEND_ROUTING in src/lib/api-helpers.ts

AlloyDB run-rate
~€48/mo

Pause-by-default posture, superseded — retirement decided 2026-08-04; runbook docs/runbooks/alloydb-retirement-2026-08-04.md

Calibration shakedown (2026-05)
27 bugs

18 workflow smokes + 5 trainer probes; the pipeline it hardened was decommissioned as a runtime scorer on 2026-08-04, and its convergence receipt was withdrawn as validation evidence on 2026-08-20

The first-generation calibration pipeline was the first tenant of a much larger platform. Foundation v1 built the platform around it: a Workspace-rooted org with three live workload projects, CMEK on every store, per-domain Cloud Run services replacing the monolith, and Datastream feeding BigQuery from AlloyDB.

Why this shape

Three forces converged on the foundation refactor at 2026-05.

The calibration corpus was the next big lock-in. (Written ahead of the campaign; the Phase-2 plan as designed was later superseded — the calibration programme that actually ran in August 2026 is documented on the science tier.) The plan anticipated committing several thousand euros of Vertex AI compute and tens of millions of rows into neumatics-prod's BigQuery nexus_calibration_corpus dataset. Once there, every later analytics surface, every reasoning audit trail, every Reading-shape downstream of it inherits the dataset's location, partitioning, schema, and CMEK posture. Reshaping after the fact means rewriting the writers, the readers, the workflows, and the manifests. Reshaping before Phase-2 fires is a few days of DDL and IAM. We chose now.

Migration must never break the live product. Per-route cutover via BACKEND_ROUTING in src/lib/api-helpers.ts moves SoulMap from the old monolith to per-domain Cloud Run services one route at a time, each behind its own graduation gate, so no cutover step ever puts the consumer surface at risk.

Compliance retrofit is a step-function expense. CMEK on Firestore is destroy-and-recreate. VPC Service Controls require an organisation. ISO 27701 + 42001 audits require an immutable audit log from day one. Doing all of that now is a few days of org setup; doing it later is a quarter of remediation in 2027. The foundation lands ahead of the scale that would make the retrofit expensive.

The full execution spec the refactor is built against — the eight architectural commitments F-3.1 through F-3.13 plus the parallel security track S-4.1 through S-4.10 — lives at nexus_foundation_v1.md in the repo root. The pages below are the public-facing summary of what shipped against that spec; the gated reports tier (available on request) carries the full per-component receipts including the IAM bindings, the BigQuery DDL excerpts, the per-cluster pause/resume audit trail, and the per-smoke calibration ledger.


The order we recommend reading these pages is the order they sit in the table above: architecture for the spine, operations for the discipline, cost engineering for the dollar story, receipts for what landed and what is still ⏳. Each reads independently if you only have time for one.