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>

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

@@ -0,0 +1,78 @@
+---
+id: RAILIANCE-WP-0016
+type: workplan
+title: "Publish apps-pg resource and recovery evidence"
+domain: financials
+repo: railiance-platform
+status: ready
+owner: codex
+topic_slug: railiance
+created: "2026-08-11"
+updated: "2026-08-11"
+related:
+  - RAILIANCE-WP-0003
+  - RESOURCE-WP-0003
+state_hub_workstream_id: "49084fb8-de63-4f32-a4a9-3a42d4e708ac"
+---
+
+# 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
+status: todo
+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
+status: todo
+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
+status: todo
+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.
+
+## 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.