docs: define deployment zone overlays

docs/financial-fabric-operator-guide.md

@@ -26,6 +26,28 @@ It defines:
 The baseline is not a security-zone model. Do not introduce realm, domain, or
 identity-zone language into the Fabric core when updating it.
 
+## Deployment Overlay Baseline
+
+Fabric membership is not the same as deployment environment. Use these current
+Railiance deployment overlays when interpreting discovery evidence:
+
+| Scenario | Environment | Access zone baseline | Notes |
+|----------|-------------|----------------------|-------|
+| `bernd-laptop` | `dev` | `private-dev` | Local machine used by one developer. Its loopback ports and local tools are useful evidence for debugging, but are not shared truth for other developers. |
+| `coulombcore` | `test` | `collaborator-test`, `early-access` | Central test-stage server for collaborating developers and friendly early-access users. |
+| `railiance01` | `prod` | `production-public`, `production-admin` | Production host. Developer access exists during alpha, but production should be able to move toward restricted operator access and applicable security and data-privacy controls. |
+
+The routing authority is the source that maps names or ports to services in a
+scenario. For local dev this may be a Makefile, script, process launcher, or
+loopback binding. For test and production this should usually come from
+Kubernetes `Service` and `Ingress`, Traefik/nginx/Caddy/HAProxy configuration,
+DNS, and TLS automation.
+
+Fabric should discover those routes and visualize the resulting zones. It
+should not allocate ports, author reverse-proxy config, or define the access
+policy. The policy authority is external evidence, such as NetKingdom IAM,
+ingress policy, network policy, or local-only loopback binding.
+
 ## Refresh Loop
 
 Run these checks from the `railiance-fabric` repo after changing declarations,