The Rig in C4

How the rig grows from one site on GCP to two sites, drawn in the C4 model. The page has one System Context view of the target, then one diagram per phase. State as of 2026-10-07.

Interactive views: /c4/ shows every view rendered by Structurizr from the DSL, with zoom, tooltips and a diagram key. CI rebuilds it whenever the DSL changes (c4.yml).
Source: the model is the Structurizr DSL at /diagrams/rig-c4.dsl, with the official C4 styles. It is the only copy: CI validates it on every change and regenerates the diagrams at /c4/ (see “How the Structurizr views are built” below).
Styling: a dashed border marks an element that is planned and not built yet, and an amber node border marks what a phase adds. A faded element is being retired. Each view’s key (press i in the viewer) lists them.

Phases

Phase	Diagram	What it adds	Status, 2026-10-07
1. GCP on GHCR	Container	GHCR pull secrets. Every fleet pulls from GHCR. Artifact Registry is switched off.	In progress: PR-1 to PR-5 merged, PR-6 (rig-gitops#939) waits on C0. PR-7 to PR-9 and PR-16 to PR-18 are next.
2. Dell standby	Deployment	A fenced copy on the Dell: the conductor at 0, Postgres, Valkey, KEDA, the egress gateway. Then the fleets at 0, the Dell tunnel and the map reader.	In progress: PR-11, PR-19 and PR-12 are live, infra#606 is fixed. PR-13 to PR-15 are planned.
3. One site per tenant	Deployment	Webhooks queued at the edge and delivered to the tenant’s site. Both conductors fenced by the D1 map. Moves from Rig Cockpit.	Planned: the router runs in shadow mode, live routing (rcw#265) is not built, the fence and sweep are built but inert.
4. Backups, first move	Deployment	Dell backups to R2, encrypted and signed. A restore drill. The first tenant runs on the Dell.	Planned: the bucket and scripts are built and inert. The tokens wait on operator-inbox#2.

How these phases map to the documented work:

Phase 1 is rig-gitops#896 Phase A plus Phase C.
Phase 2 is #896 Phase B (PR-10 to PR-19) and infra#606.
Phase 3 is the routing and go-live steps of the multi-location programme (rcw#251, rcw#265, rc#2561, rc#2562).
Phase 4 is rig-gitops#897 plus the first move.

Level 1: System Context

One person runs the rig. Work arrives from GitHub, and the rig answers in GitHub with commits, PRs, reviews and merges. Cloudflare fronts everything public. The models come from Anthropic and OpenAI, and Rig-E’s own model runs on a rented RunPod GPU.

Diagram: System Context, generated from the DSL by Structurizr. Open it to zoom, see tooltips and the diagram key.

Phase 1: one site on GCP, images from GHCR

Today the whole rig runs on the GCP cluster. Phase 1 changes where it gets its images: every image comes from GitHub Container Registry, which the Dell can also reach, and Artifact Registry is switched off.

The webhook router already runs at the edge, but only in shadow mode: it checks each delivery, logs where it would route it, and passes everything to the GCP conductor.

Diagram: Phase 1 container view, generated from the DSL by Structurizr. Open it to zoom, see tooltips and the diagram key.

Phase 2: a fenced standby on the Dell

The Dell gets a copy of the rig that cannot act. Its conductor runs with LOCATION=dell and no tenants, so it refuses every write. It stays at zero replicas until the fence is proven, and GCP keeps serving every tenant. The Dell pulls images from GHCR only, because it has no Artifact Registry credential.

Live:
- PR-11 (rig-gitops#913): KEDA 2.21 and the egress gateway.
- PR-19 (#915): CI render invariants.
- PR-12 (#925): the conductor at 0, Postgres and Valkey on local-path.
- infra CI applies the k3s settings over Tailscale, and infra#606 stops k3s exiting on big applies.
Planned:
- PR-13: the fleets at 0, agent-home on local-path, pgvector enabled.
- PR-14: the Dell tunnel (infra#602, C4).
- PR-15: the tenant-map reader (infra#603, C5).

Diagram: Phase 2 deployment view, generated from the DSL by Structurizr. Open it to zoom, see tooltips and the diagram key.

Phase 3: each tenant served by one site

The edge becomes the switch. Each webhook is queued in Cloudflare, looked up in the tenant map, and delivered to the site that owns the tenant. Both conductors read the same map and write only for their own tenants, so no tenant is ever served twice. A conductor that cannot reach the map for 60 seconds stops writing.

To build: live routing in the webhook router, meaning the Queue, the consumer, the dead-letter queue and ROUTING_MODE (rcw#265). The fence and the reconcile sweep are built and inert (rc#2561, rc#2562).
The operator’s go-live steps, in order:
1. ROUTING_MODE=live and the /api/merge* route.
2. LOCATION=gcp with the tenant map on GCP.
3. The same on the Dell.
4. A test move: draining, 15 minutes, then epoch + 1.

Diagram: Phase 3 deployment view, generated from the DSL by Structurizr. Open it to zoom, see tooltips and the diagram key.

Phase 4: backups proven, then the first tenant on the Dell

No tenant moves until the Dell’s data is backed up off site and a restore has worked. Then one tenant (T) moves to the Dell, and every other tenant stays on GCP. RunPod control, the daily cost report and rig-assistant stay on GCP.

Built, waiting on the operator:
- the bucket rig-backups-dell (EU, bucket lock), the backup image, the scripts and the drill kit (#897, P1a to P6);
- the writer and reader tokens, which wait on O1 (operator-inbox#2);
- the age and signing keys (O2).
Before the first move:
- an activation issue covering iBuild-E’s link to GCP’s Valkey, the Codex auth homes, the tenant database and the planner pin;
- a capacity plan for the Dell and an egress NetworkPolicy;
- a proving run, then drill A.

Diagram: Phase 4 deployment view, generated from the DSL by Structurizr. Open it to zoom, see tooltips and the diagram key.

Open questions

Failover. Moves are manual. A move forces after 15 minutes, but there is no runbook or drill for GCP being down.
Placement. Nothing says which tenants go to the Dell, or when. New tenants default to GCP.
Memory. A move starts fresh. Whether agent memory (pgvector) follows the tenant is not decided.
Cockpit reads. Cockpit still reads from the GCP conductor. How it shows a Dell tenant is not specified.
The Dell itself. It is one laptop with one disk and no UPS decision. etcd snapshots and the NAS copy are not designed.

How the Structurizr views are built

public/diagrams/rig-c4.dsl is the model. The c4.yml workflow validates it and exports it with Structurizr whenever the DSL changes, under the conditions of its security review (Stig-Johnny/claude-3#1059).

Inspect a change before it merges: open the c4.yml run on the PR, download its c4-site artifact, and open index.html. Every view is there with zoom, tooltips and a diagram key.
Layout: each view uses automatic layout, top to bottom (autoLayout tb), with explicit rank and node separation. Elements and relationship labels are styled smaller, so the fitted view stays legible.
One deployment group per site. In each deployment environment, every container instance belongs to the GCP or the Dell group. Structurizr copies a model relationship only between instances in the same group, so a Dell instance never appears to talk to a GCP one. The groups are placed like this:
- the Cloudflare edge pieces both sites use (the webhook router, the queue, the tenant map and Rig Cockpit) are in both groups;
- iBuild-E is in GCP’s group;
- the R2 bucket and the restore drill are in the Dell’s group.

Where these facts come from

The phase plans:
- rig-gitops docs/2026-10-03-ghcr-and-dell-standby-plan.md and docs/2026-10-04-dell-standby-overlay.md;
- rig-conductor docs/2026-10-02-multi-location-fencing.md;
- rig-cockpit-worker docs/2026-10-02-tenant-location-map.md and its webhook router doc;
- infra docs/2026-10-03-rig-backups-r2.md.
Live state: the 2026-10-07 checks on the Dell recorded on rig-gitops#896.
Where BRAIN.md is behind: it still lists older models (now opus-5-5, sonnet-5 and gpt-6.1-sol) and both registries. The per-repo docs win.