railiance-platform/history/2026-09-05-platform-assurance-implementation.md

RPF-WP-0036 implementation — 2026-09-05

Implemented the ready plan's repository work and performed bounded live status inspection using the existing SSH route to the pinned railiance01 cluster. No credentials were fetched, no backup/restore or infrastructure mutation ran, and no scheduler, external notification or owner acceptance was created.

Delivered

• ADR-0004 and service records disclose unsupported availability/RPO/RTO commitments, existing evidence, retention and accountable decision owners. Local freshness/headroom thresholds are diagnostic, not SLAs.
• An admission checker reuses the apps-pg and rapp-postgres validators, verifies effective retention and placement ownership, and refuses a changed source hash/disclosure baseline. Five-consumer and mismatched-retention fixtures fail.
• A cluster-pinned collector supplies selected CNPG status, aggregate connection counts, metrics and unauthenticated OpenBao seal status. It reads no Secret, application data, session SQL text or logs. SSH argv are quoted; failures suppress raw output; successful observation files publish atomically at 0600.
• A closed observation evaluator distinguishes healthy, stale, missing, failed and unavailable samples, rejects wrong clusters/future/unknown payloads, and makes missing emission detectable through capture expiry. Transport remains explicitly unmonitored pending Q2 acceptance.
• Corrected placement/interface disclosures: tenant-engine's PostgreSQL cutover completed; platform-pg is 4/4 and the deployed platform-pg-2 holds sbom-nexus.
• Exact compatibility path/hash/caller inventories and a dated retention decision are ready for owner review. No functioning entry point was removed.
• ADR-0005 defers unrequested cache/general storage/broker deployments with explicit review triggers and prefers existing storage interfaces for demand.

Live findings

The default workstation kube context and the misleading config-railiance01 file reached a different host; config-hosteurope depended on a down local forwarder. The collector therefore uses existing SSH to railiance01 and checks kube-system UID a553c742-0115-43d4-99a4-a5ca56fe0786 before service reads. No context was rewritten or tunnel deployed.

All three deployed database cells matched one instance, 1Gi memory limit, 100 aggregate connections and 30-day retention. Each was Ready, had a completed backup from 02:15 UTC that morning and reported continuous archiving. Aggregate connection/memory occupancy passed the local 80% diagnostic threshold. OpenBao was unsealed. These are point-in-time observations, not new guarantees.

The checker also exposed three failed ESO resources (SecretSyncedError): forgejo/forgejo-mailer, reuse/reuse-surface-runtime and target-revenue/target-revenue-runtime. The earliest successful refresh was 2026-08-06. Their active/obsolete status and exact cause need consumer/platform review before a lane repair or retirement; no credential diagnosis is inferred from this condition alone.

Evidence: docs/evidence/RPF-WP-0036-assurance-2026-09-05.json includes capture, evaluation time, live limits and sanitized failing-resource metadata. It does not manufacture isolated-restore receipts from historical prose. Missing restore/snapshot/offsite inputs and failed/stale ESO keep overall assurance non-green, which is the expected correct result.

Validation

Full repository unittest discovery: 176 passed. Focused assurance tests after collector output hardening: 14 passed. Admission baseline check passed; fresh live capture completed and its specification limits matched the source. Cases cover wrong clusters, future/naive times, stale/replayed captures, missing and failed signals, unexpected payloads/value-safe errors, unavailable native reads, memory units, missing ownership/overflow, fifth consumer admission, and unhonoured retention. This is not a restore or alert-delivery test.

Remaining acceptance

T02/T05/T07 are done. T03 waits on fresh owner-validated recovery/offsite receipts, independent recovery access and approved recurring execution. T04 waits on the Q2 receiving contract and controlled failure/absence delivery; ESO findings remain visible for exact owner disposition. T06 waits on accepted handoffs and scoped alias cleanup. The installed brief generator still reads legacy open aliases; generating the brief alone would reproduce those rows.

The prepared owner request content is in docs/platform-ownership-handoffs.md. Its transmission is not claimed. The plan remains blocked on these explicit acceptance gates; source implementation is not substituted for owner/live proof.