diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md
index 7b21b18..f3071f6 100644
--- a/docs/CURRENT-STATE.md
+++ b/docs/CURRENT-STATE.md
@@ -957,6 +957,55 @@
   **So R10 is EXECUTED and its prediction held, but the fuller answer is that there is NO single
   host on which preflight is currently correct** -- vcloud has the credentials and not the
   clients, voffice1 the reverse. Logged, not ruled.
+- **STAGE-5 DEPLOY ORDER RULED 2026-07-27 (GA-R5). Question as presented:** does Stage 5 deploy
+  `vr1-dc0` first -- restoring the phase-4 runbook's own stated order (`## Sequence (repeat
+  entire sequence once per DC, DC1 first)` with `export DC=vr1-dc0`, i.e. its "DC1" IS
+  `vr1-dc0`) and making DC0 the NOC -- or does it proceed dc1-first as the current artifacts
+  assume? Raised because the operator described the test's posture (Office1 stands up first as
+  a simulated regional office -> dark fiber to DC0 -> DC0 fully bootstrapped becomes the NOC ->
+  a technician at a desk in Office1 connects to the NOC and pushes a deployment to DC1) and
+  observed that the deployment steps for it were not in the roadmap. **Operator answer, exact
+  utterance: "We have passed far enough into this deployment I am willing to step away from the
+  DC0 then DC1 deployment roadmap. We can take that posture on the next deployment after we
+  have fully completed this push, configuration, and hardening. We can push deployment to each
+  DC from voffice1 the same way. The deployment of DC0 and DC1 deployment files should be
+  almost identical. Overall, the base deployment yaml, the overlays, and the only differences
+  should be the Netbox assignments."** CONSEQUENCES: (1) there is NO ruled DC ordering for this
+  deployment -- both DCs deploy from voffice1 by the same procedure, so the dc1-first artifact
+  state is no longer a divergence from the roadmap and needs no correction; (2) the
+  DC0-then-DC1 / NOC-as-milestone posture is DEFERRED to the NEXT deployment, after this push,
+  configuration and hardening complete -- it is Roosevelt-relevant content that currently has
+  no durable home (see the D-number question below); (3) the target artifact shape is
+  CONFIRMED and is the same shape ruling 3 of 2026-07-25 already ruled -- a DC-neutral base
+  `bundle.yaml` plus per-DC overlays. **WHAT THE AUDIT FOUND ABSENT AND IS NOW CONFIRMED
+  ABSENT: the NOC concept appears NOWHERE in the live repo** (`grep -rniE '\bNOC\b'` over
+  `docs/ runbooks/ scripts/ bundle.yaml` -> zero hits outside archive), nor does the
+  technician-at-Office1 scenario; D-100 defines the fabric and says the Office1<->DC fiber
+  "carries management traffic only (MAAS/Juju/operator)" but never states the sequenced test.
+  **MEASURED CAVEAT TO "only differences should be the NetBox assignments" -- the target is
+  nearly right, and the exceptions are the point.** Confirmed NetBox-derived and symmetric: the
+  VIP overlay is a pure prefix remap (`10.12.4/8/12` -> `10.12.64/68/72`, host octets
+  unchanged). Confirmed per-DC but NOT NetBox-derived, so a symmetric render cannot source
+  them: (a) the machines overlay's MAAS tag (`openstack-vr1-dc0` vs `-dc1`); (b)
+  `overlays/octavia-pki.yaml`, per-DC generated CA material under the R7 amendment, which
+  preflight P4 CHECK 0 and phase-01:144-145 both hard-require; and (c) **`ovn-chassis`
+  `bridge-interface-mappings`, which is the consequential one -- see the next entry.**
+- **READINESS FINDING 3.8 IS PROMOTED FROM LATENT TO LIVE BY THE ORDER RULING ABOVE.**
+  `bundle.yaml:462-464` sets `bridge-interface-mappings: br-ex:52:54:01:d1:04:02
+  br-ex:52:54:01:d1:05:02`. MEASURED against `scripts/lib-hosts.sh` (the host-identity
+  authority): the `52:54:01:d1:NN:01` scheme is **vr1-dc1's** pinned MAC convention
+  (lib-hosts:132 states it encodes the node index for `opentofu/vr1-dc1-substrate`), `:04`/`:05`
+  being compute-01/-02. **So the file documented as "the vr1-dc0 source of truth" carries dc1's
+  compute provider MACs.** vr1-dc0's boot MACs are an entirely different, NON-schematic set
+  (`52:54:00:be:69:c5`, `52:54:00:02:ff:57`, ... -- randomly generated and pinned after the
+  fact from measurement, lib-hosts:118-122), so they cannot be derived from a pattern the way
+  dc1's can. CONSEQUENCE, quoting the audit: on a dc0 deploy "no local MAC matches,
+  `ovn-chassis` builds no br-ex mapping, provider egress is dead on dc0 compute, and **no gate
+  fails**". While the plan was dc1-first this was harmless and was recorded as such; under the
+  ruling that BOTH DCs deploy by the same procedure, a dc0 deploy is now certain to happen and
+  would silently produce a cloud whose compute nodes have no provider egress. It is also a
+  per-DC value that is NOT a NetBox assignment, so it must move into the per-DC overlays for
+  the ruled symmetric shape to be truthful. Logged, NOT fixed (hard rule 1).
 - Position inside Stage 3: deploy step A EXECUTED 2026-07-19 (6/0/6
   exact; convergence zero --
   `docs/audit/outer-plan-20260719-postA-converged.txt`). **Deploy step B