coulomb/railiance-platform
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
railiance-platform/workplans/RAILIANCE-WP-0016-apps-pg-resource-evidence.md

90 lines
2.8 KiB
Markdown
Raw Normal View History

Assess the Railiance architecture in aspiration from INTENT files Reads all ten local railiance-* INTENT.md files as a statement of intended architecture, cross-checked against git history, remotes and the live cluster. Ten repos declare eight distinct intents. The aspiration is coherent and the handoffs are stated from both sides. Findings: railiance-bootstrap is a second local clone of railiance-cluster rather than a repo (which means fleet counts built by scanning ~ overcount, including the 112 figure in the org refactor); railiance-hosts and railiance-infra are distinct remotes with unrelated histories and byte-identical INTENT, both claiming S1; railiance-forge is unplaced in the OAS stack dimension; S4 is aspiration-only at 25 commits and zero workplans. The strongest finding is a shared thread nobody named: five layers independently aspire to be "self-evidencing" or "auditable", and no repo owns the verification substrate that would evaluate those claims. That is the same gap as the enforcement control loop, arrived at from the opposite direction. Also notes missing homes for observability, end-to-end restore proof, and the cost-attribution interface. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 21:01:21 +02:00
---
id: RAILIANCE-WP-0016
type: workplan
title: "Publish apps-pg resource and recovery evidence"
domain: financials
repo: railiance-platform
Finish RAILIANCE-WP-0016 apps-pg resource evidence Publish capacity, recovery, labor, and allocation-driver evidence for resource:railiance:apps-pg so resource-control can forecast and allocate without reading application data or inventing booked cost.
2026-08-14 02:05:25 +02:00
status: finished
Assess the Railiance architecture in aspiration from INTENT files Reads all ten local railiance-* INTENT.md files as a statement of intended architecture, cross-checked against git history, remotes and the live cluster. Ten repos declare eight distinct intents. The aspiration is coherent and the handoffs are stated from both sides. Findings: railiance-bootstrap is a second local clone of railiance-cluster rather than a repo (which means fleet counts built by scanning ~ overcount, including the 112 figure in the org refactor); railiance-hosts and railiance-infra are distinct remotes with unrelated histories and byte-identical INTENT, both claiming S1; railiance-forge is unplaced in the OAS stack dimension; S4 is aspiration-only at 25 commits and zero workplans. The strongest finding is a shared thread nobody named: five layers independently aspire to be "self-evidencing" or "auditable", and no repo owns the verification substrate that would evaluate those claims. That is the same gap as the enforcement control loop, arrived at from the opposite direction. Also notes missing homes for observability, end-to-end restore proof, and the cost-attribution interface. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 21:01:21 +02:00
owner: codex
topic_slug: railiance
created: "2026-08-11"
Finish RAILIANCE-WP-0016 apps-pg resource evidence Publish capacity, recovery, labor, and allocation-driver evidence for resource:railiance:apps-pg so resource-control can forecast and allocate without reading application data or inventing booked cost.
2026-08-14 02:05:25 +02:00
updated: "2026-08-14"
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>
2026-08-11 23:09:36 +02:00
state_hub_workstream_id: "49084fb8-de63-4f32-a4a9-3a42d4e708ac"
Assess the Railiance architecture in aspiration from INTENT files Reads all ten local railiance-* INTENT.md files as a statement of intended architecture, cross-checked against git history, remotes and the live cluster. Ten repos declare eight distinct intents. The aspiration is coherent and the handoffs are stated from both sides. Findings: railiance-bootstrap is a second local clone of railiance-cluster rather than a repo (which means fleet counts built by scanning ~ overcount, including the 112 figure in the org refactor); railiance-hosts and railiance-infra are distinct remotes with unrelated histories and byte-identical INTENT, both claiming S1; railiance-forge is unplaced in the OAS stack dimension; S4 is aspiration-only at 25 commits and zero workplans. The strongest finding is a shared thread nobody named: five layers independently aspire to be "self-evidencing" or "auditable", and no repo owns the verification substrate that would evaluate those claims. That is the same gap as the enforcement control loop, arrived at from the opposite direction. Also notes missing homes for observability, end-to-end restore proof, and the cost-attribution interface. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 21:01:21 +02:00
related:
- RAILIANCE-WP-0003
- RESOURCE-WP-0003
---
# RAILIANCE-WP-0016 — apps-pg resource evidence
## Goal
Provide platform-owned evidence for `resource:railiance:apps-pg`: demand,
utilization, recovery, operations labor, and consumer allocation. Origin:
`RESOURCE-WP-0003-T04` delegated evidence gap.
## T01 — Publish database capacity and utilization
```task
id: RAILIANCE-WP-0016-T01
Finish RAILIANCE-WP-0016 apps-pg resource evidence Publish capacity, recovery, labor, and allocation-driver evidence for resource:railiance:apps-pg so resource-control can forecast and allocate without reading application data or inventing booked cost.
2026-08-14 02:05:25 +02:00
status: done
Assess the Railiance architecture in aspiration from INTENT files Reads all ten local railiance-* INTENT.md files as a statement of intended architecture, cross-checked against git history, remotes and the live cluster. Ten repos declare eight distinct intents. The aspiration is coherent and the handoffs are stated from both sides. Findings: railiance-bootstrap is a second local clone of railiance-cluster rather than a repo (which means fleet counts built by scanning ~ overcount, including the 112 figure in the org refactor); railiance-hosts and railiance-infra are distinct remotes with unrelated histories and byte-identical INTENT, both claiming S1; railiance-forge is unplaced in the OAS stack dimension; S4 is aspiration-only at 25 commits and zero workplans. The strongest finding is a shared thread nobody named: five layers independently aspire to be "self-evidencing" or "auditable", and no repo owns the verification substrate that would evaluate those claims. That is the same gap as the enforcement control loop, arrived at from the opposite direction. Also notes missing homes for observability, end-to-end restore proof, and the cost-attribution interface. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 21:01:21 +02:00
priority: high
state_hub_task_id: "c772bcea-7ae0-4532-b434-31f75c905431"
```
Record instance count, CPU/memory requests and observed use, provisioned and
used storage, database growth, connections, I/O or other available saturation
proxies, and consumer database attribution with timestamps and provenance.
Done when resource-control can forecast database capacity without reading
application data or credentials.
## T02 — Publish recovery and operational evidence
```task
id: RAILIANCE-WP-0016-T02
Finish RAILIANCE-WP-0016 apps-pg resource evidence Publish capacity, recovery, labor, and allocation-driver evidence for resource:railiance:apps-pg so resource-control can forecast and allocate without reading application data or inventing booked cost.
2026-08-14 02:05:25 +02:00
status: done
Assess the Railiance architecture in aspiration from INTENT files Reads all ten local railiance-* INTENT.md files as a statement of intended architecture, cross-checked against git history, remotes and the live cluster. Ten repos declare eight distinct intents. The aspiration is coherent and the handoffs are stated from both sides. Findings: railiance-bootstrap is a second local clone of railiance-cluster rather than a repo (which means fleet counts built by scanning ~ overcount, including the 112 figure in the org refactor); railiance-hosts and railiance-infra are distinct remotes with unrelated histories and byte-identical INTENT, both claiming S1; railiance-forge is unplaced in the OAS stack dimension; S4 is aspiration-only at 25 commits and zero workplans. The strongest finding is a shared thread nobody named: five layers independently aspire to be "self-evidencing" or "auditable", and no repo owns the verification substrate that would evaluate those claims. That is the same gap as the enforcement control loop, arrived at from the opposite direction. Also notes missing homes for observability, end-to-end restore proof, and the cost-attribution interface. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 21:01:21 +02:00
priority: high
state_hub_task_id: "4eafebd5-0434-42a2-a126-c292c29c1f21"
```
Record backup coverage, restore-test results, recovery objectives, upgrade and
maintenance cadence, incidents, and setup/recurring operator labor. Keep
service procedures and execution in railiance-platform.
Done when the portfolio can distinguish verified recovery, unresolved local
storage risk, and platform labor cost.
## T03 — Define shared database allocation drivers
```task
id: RAILIANCE-WP-0016-T03
Finish RAILIANCE-WP-0016 apps-pg resource evidence Publish capacity, recovery, labor, and allocation-driver evidence for resource:railiance:apps-pg so resource-control can forecast and allocate without reading application data or inventing booked cost.
2026-08-14 02:05:25 +02:00
status: done
Assess the Railiance architecture in aspiration from INTENT files Reads all ten local railiance-* INTENT.md files as a statement of intended architecture, cross-checked against git history, remotes and the live cluster. Ten repos declare eight distinct intents. The aspiration is coherent and the handoffs are stated from both sides. Findings: railiance-bootstrap is a second local clone of railiance-cluster rather than a repo (which means fleet counts built by scanning ~ overcount, including the 112 figure in the org refactor); railiance-hosts and railiance-infra are distinct remotes with unrelated histories and byte-identical INTENT, both claiming S1; railiance-forge is unplaced in the OAS stack dimension; S4 is aspiration-only at 25 commits and zero workplans. The strongest finding is a shared thread nobody named: five layers independently aspire to be "self-evidencing" or "auditable", and no repo owns the verification substrate that would evaluate those claims. That is the same gap as the enforcement control loop, arrived at from the opposite direction. Also notes missing homes for observability, end-to-end restore proof, and the cost-attribution interface. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 21:01:21 +02:00
priority: medium
state_hub_task_id: "fc329443-a2fc-4409-b670-dfb103df2794"
```
Publish candidate consumer drivers such as database storage GB-month,
connections, transactions, or measured I/O. Include shared overhead,
unattributed residual, method version, and uncertainty.
Done when resource-control can allocate a referenced apps-pg cost without
making railiance-platform a financial ledger.
Finish RAILIANCE-WP-0016 apps-pg resource evidence Publish capacity, recovery, labor, and allocation-driver evidence for resource:railiance:apps-pg so resource-control can forecast and allocate without reading application data or inventing booked cost.
2026-08-14 02:05:25 +02:00
## Outcome
Published 2026-08-14. Observation
`docs/evidence/RAILIANCE-WP-0016-apps-pg-observation.json` and narrative
`docs/evidence/RAILIANCE-WP-0016-apps-pg-resource-evidence.md`.
- T01: 1/1 instance, 10Gi local-path, 590 MiB PGDATA, no CPU/memory
requests, two consumer catalogs (~16.6 MiB), `vergabe_db` unused.
- T02: no ScheduledBackup, not an Option A target, RPO unbounded, RTO
undefined — unresolved local-storage risk. Labor: ~6h setup, ~0.5h/month
recurring, high uncertainty, no EUR.
- T03: method `apps-pg-dbbytes-v1`, driver `database_gb`, residual
`platform:apps-pg-overhead` (94.8% of used volume is WAL/catalog).
Refresh: `make apps-pg-evidence`. resource-control can now replace the
illustrative `examples/control-cycle/apps-pg-*.json` fixtures.
Reference in a new issue Copy permalink