diff --git a/ArchitectureBlueprint.md b/ArchitectureBlueprint.md index a9b2d1e..82a338d 100644 --- a/ArchitectureBlueprint.md +++ b/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 diff --git a/workplans/RAILIANCE-WP-0016-apps-pg-resource-evidence.md b/workplans/RAILIANCE-WP-0016-apps-pg-resource-evidence.md index 3524d39..7d9884d 100644 --- a/workplans/RAILIANCE-WP-0016-apps-pg-resource-evidence.md +++ b/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.