Establish all six OAS dimensions as a working model

Populates each canonical dimension with Railiance's actual position, canon's
sub-levels, owners where they exist, and honest status.

Findings from doing it:
- Q1 Security and Compliance is already implemented in S3 to a mature standard
  (approval gates, delegated apply, revocation, front-door readiness) and was
  never named as a dimension. Evidence the dimensions describe real structure
  rather than impose vocabulary.
- Plane is operated in full and declared nowhere. P1 workload, P2 control
  (ArgoCD, CNPG, ESO, cert-manager), P3 management (State Hub, master,
  workplans). Likely to clarify the rail/rapp relationship, since a rail is
  essentially a P1 contract.
- Intelligence is already referenced in practice - qonto-assistant cites an I1
  isolation profile - and the whole agent operating model is I4-I5. Leaving it
  unmodelled understates what this fleet actually is.
- Q3 Operability and Q7 Governance remain unowned; Q5 unaddressed.

Adds a recommended establishing order for railiance-master to ratify: Quality
first (most unowned concerns), Plane second (cheap, descriptive), Capability
third (blocked on the C1 attribution drift), Intelligence fourth, Logic last or
never if Helix Forge owns functional decomposition.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

ArchitectureBlueprint.md

@@ -127,6 +127,90 @@ The recurring "self-evidencing" aspiration across five stack layers (§3) is, in
 OAS terms, five Stack-dimension repos each independently asking for Q2 and Q7.
 That is what a missing dimension looks like from inside the one you are using.
 
+### 2.2 The six dimensions, established
+
+Railiance's position on each canonical dimension, with owners where they exist.
+Sub-levels are canon's, not invented here. **Status** is honest about what is
+implemented versus merely named.
+
+#### Stack — technical hosting substrate · *in use*
+
+S1 `railiance-infra` · S2 `railiance-cluster` · S3 `railiance-platform` ·
+S4 `railiance-enablement` · S5 `railiance-apps`. See §2.
+
+#### Quality — cross-cutting architecture properties · *the priority*
+
+| Sub-level | Railiance concern | Owner | Status |
+| --- | --- | --- | --- |
+| Q1 Security and Compliance | credential custody, OpenBao lanes, CCR approval, grant catalog | S3 | **implemented**, never named Q1 |
+| Q2 Observability | metrics, logs, traces, alerting | `railiance-telemetry` | seeded 2026-08-11, no implementation |
+| Q3 Operability and Resilience | restore drills, rollback proof, DR | — | split S1/S3/S5, **unowned** |
+| Q4 Isolation and Tenancy | consumer isolation, tenant keying | `rapp-postgres` (per-consumer) | implemented, not modelled fleet-wide |
+| Q5 Performance and Scalability | — | — | **unaddressed** |
+| Q6 Cost and Efficiency | cost attribution, unit economics | `resource-control`, `fin-hub` | outside the family, boundary undeclared |
+| Q7 Governance and Change Management | the conformance loop, policy enforcement | — | **unowned** (§5.3) |
+
+Q1 is worth dwelling on: S3 has been building a mature Q1 practice for months —
+approval gates, delegated apply, revocation semantics, front-door readiness —
+without ever naming the dimension. That is evidence the dimensions describe real
+structure rather than imposing vocabulary.
+
+#### Plane — operational responsibility · *implicit, unnamed*
+
+| Sub-level | Railiance reality |
+| --- | --- |
+| P1 Workload Plane | `rapp-*` packages and the workloads they run |
+| P2 Control Plane | ArgoCD, CNPG operator, External Secrets, cert-manager |
+| P3 Management Plane | State Hub, `railiance-master`, workplans, decisions |
+
+Railiance already operates all three; none is declared. This is the dimension
+most likely to clarify the `rapp-*` / `rail-*` relationship, since a rail is
+essentially a P1 contract.
+
+#### Capability — stable capability modeling · *partial*
+
+C1 Capability Model / C2 Contract / C3 Realization / C4 Shared Platform
+Capabilities / C5 Business Capabilities.
+
+`railiance-fabric` models C1–C3; the per-repo `registry/capabilities/`
+declarations and `reuse-surface` federation cover C4. C5 is unaddressed and is
+where the boundary with `resource-control` / `fin-hub` (and Q6) belongs.
+**Contradiction C1 lives here**: the hub's capability attributions do not match
+repo declarations.
+
+#### Logic — functional decomposition · *unused*
+
+L1 Capability Domain / L2 Service Realization / L3 Composition and Integration /
+L4 Solution Layer. No Railiance repo is organised on this axis. Lowest priority:
+the Stack and Quality dimensions carry more weight for an operations framework,
+and Logic is likely more relevant to Helix Forge's capability-first model.
+
+#### Intelligence — degree of intelligent automation · *emerging, unnamed*
+
+I1 Deterministic Automation / I2 Language Interaction / I3 Knowledge and
+Reasoning / I4 Assisted Adaptation / I5 Agentic Delegation.
+
+Already referenced in practice — `qonto-assistant/docs/SecurityPractice.md`
+cites an "I1 Reinforced minimum" isolation profile — and the whole agent
+operating model (autonomy lanes, Kaizen agents, `/ralph-workplan`) is I4–I5
+territory. Declared nowhere in Railiance. Given how much of this fleet is
+agent-operated, leaving Intelligence unmodelled understates what the system
+actually is.
+
+### Establishing order
+
+Recommended sequence, for `railiance-master` to ratify:
+
+1. **Quality first.** It holds the most unowned concerns (Q3, Q7) and the
+   already-built-but-unnamed ones (Q1, Q4). Q2 has a home as of 2026-08-11.
+2. **Plane second.** Cheap — it is descriptive of what already runs, and it
+   sharpens the `rail-*` contract.
+3. **Capability third.** Requires resolving C1 (hub attribution drift) and C4
+   first, or the model is built on bad data.
+4. **Intelligence fourth.** Needs a real decision about how much of the agent
+   operating model belongs in Railiance versus the-custodian.
+5. **Logic last**, or never, if Helix Forge owns functional decomposition.
+
 ### The layering contract
 
 Each layer hands the next a **verified** substrate and does not reach past its

workplans/RAILIANCE-WP-0016-apps-pg-resource-evidence.md

@@ -9,10 +9,10 @@ owner: codex
 topic_slug: railiance
 created: "2026-08-11"
 updated: "2026-08-11"
+state_hub_workstream_id: "49084fb8-de63-4f32-a4a9-3a42d4e708ac"
 related:
   - RAILIANCE-WP-0003
   - RESOURCE-WP-0003
-state_hub_workstream_id: "49084fb8-de63-4f32-a4a9-3a42d4e708ac"
 ---
 
 # RAILIANCE-WP-0016 — apps-pg resource evidence
@@ -70,9 +70,3 @@ unattributed residual, method version, and uncertainty.
 
 Done when resource-control can allocate a referenced apps-pg cost without
 making railiance-platform a financial ledger.
-
-## Acceptance
-
-- [ ] Capacity and utilization evidence is consumer-aware and non-secret.
-- [ ] Recovery and labor evidence is timestamped and verifiable.
-- [ ] Shared allocation drivers reconcile with explicit residuals.