railiance-platform/history/2026-09-05-platform-intent-workplan-assessment.md

Railiance Platform intent, scope and workplan assessment — 2026-09-05

Conclusion

The backlog mostly serves INTENT, but its presentation confused completed implementation, waiting live acceptance, and work belonging to other owners. The largest missing part of the intent is a continuing service-assurance loop: clear promises, fresh recovery evidence, monitored capacity and observable failure. It is not a lack of additional credential designs or a reason to install every aspirational stateful service.

The review starts from platform commit 9d958f8e09a057d6ad688dc77001368b5feea029. It covers all 37 file-backed workplans and 168 task records, with detailed inspection of every unfinished task, its source contracts and available owner updates. Completed records were triaged by deliverable/boundary, not recertified as current production health. The scope of work is assessment and consolidation; no credentials were read, no live infrastructure changed, no external messages sent, and no transfer acceptance was fabricated. INTENT is unchanged.

What changed

Before: 29 finished plans, 2 active, 5 blocked, 1 archived; 31 files at the workplan root, including 24 already finished. Task states: 150 done, 7 wait, 4 progress, 1 cancel and 6 historical cancelled tasks in the retired baseline. Those legacy task spellings are preserved rather than silently rewriting the historical baseline.

After: 32 finished plans, 5 blocked, 1 ready, 1 archived (39 records total). Only six current workplans remain at the root; 27 completed plans moved to workplans/archived/260905-* with their IDs and managed UUIDs intact. No source record was deleted. The three design plans finish because their design work is delivered and each implementation task is explicitly superseded in RPF-WP-0035. They do not claim live lane completion. RPF-WP-0036 adds the missing assurance work with six actionable follow-ups rather than six more umbrella workplans.

The number of blocked plans remains five: three lane waits became one queue, and two apparently active plans were corrected to blocked because their remaining work waits on owners/live windows. A smaller number achieved by marking unperformed live work done would hide obligations, not consolidate them.

SCOPE.md now describes actual service boundaries, dated evidence and unsupported guarantees. workplans/README.md is the short current queue. The accompanying inventory preserves before/after statuses, task dispositions, source revisions and every archive path.

Important findings

1. Two claimed platform gaps were already closed

SCOPE said apps-pg had no backup and both shared clusters lacked ceilings. RPF-WP-0019 and its 2026-08-20 evidence show daily backup/continuous WAL, 30-day retention, a 56-second scratch restore, 14/14 isolation/control probes, and a three-consumer apps-pg ceiling with a provisionable overflow cell. The consumer interface records platform-pg's four-declaration ceiling.

Evidence: apps-pg restore, isolation, and interfaces. These are dated proofs, not a fresh claim about backup age today. Do not reopen the completed bootstrap work.

2. Recovery/availability promises remain weaker than the aspiration

Both published shared database interfaces declare one instance and no HA. CNPG's presence is not a multi-node availability guarantee. Database restore artifacts exist; the examined OpenBao snapshot/preparation receipts and restore templates do not establish a current recurring isolated-restore guarantee. The earlier reboot returned the same PVC and is not proof of node-loss recovery.

S3 needs per-service accepted availability/RPO/RTO, retention and evidence-age budgets, recovery custody/operator availability, and recurring proof of restore. No numeric promise should be invented from one elapsed-time observation. RPF-WP-0036-T02/T03 closes this gap while preserving the two specific pending experiments in RPF-WP-0015. Fleet Q3 ownership remains for railiance-master; S3 cannot use that uncertainty to decline its own recovery responsibility.

3. The security incident records need evidence reconciliation, not another rotation

KEY-WP-0011 is finished and NK-WP-0033-T04 records the bundle replacement. Platform RPF-WP-0027-T04 was stale; it is now done by that existing owner evidence. NK-WP-0033's 2026-08-27 update also records the resolver binding reconciliation, but no complete green receipt and no retained predecessor for the negative test. T03/T05/T06 remain waiting on current evidence disposition and exact custody. The incident owner must decide how the missing predecessor proof is treated; manual observations cannot be promoted into a fabricated receipt.

Provider/resolver/MFA verification belongs to NetKingdom and KeyCape; S3 owns custody and its acceptance. RPF-WP-0029 remains a separate, high-priority backup credential exposure until provider invalidation and replacement recovery are proved. Neither a source fix nor this consolidation closes an exposure.

4. Observability is a shared dependency with a retained S3 obligation

docs/placement-policy.md labels capacity monitoring unmonitored. The reviewed railiance-telemetry source is still seeded and owns the standard emission and transport contract. Platform must define what its service signals mean, emit safe metadata, and prove a failed/stale check reaches a named recipient. It should not build a second monitoring plane, nor mark emission complete because another repo has not delivered the receiver. RPF-WP-0036-T04 makes this split and its end-to-end acceptance explicit.

5. Consumer admission records drift even though their controls exist

The placement policy mixes desired tenant-engine placement with statements of live co-residency and predates Core Hub admission. The interface and package source must be joined before deciding occupancy, overflow or retention impact. This is an evidence/disclosure gap, not permission to move workloads. RPF-WP-0036-T05 reconciles it using existing package admission checks.

6. Credential designs fit S3, but their end-to-end applications do not

The three new designs remain useful. Their platform-owned portions are custody, exact policy/auth bindings, delivery and negative verification. Issuer/JWKS, application CAS/session behavior, lifecycle/approval consumption, and runtime rotation fencing belong to their respective owners. RPF-WP-0035 is the single implementation queue, with separate gates for each lane.

The signing demand has a material qualification: STATE-WP-0085-T09 finished its plan-generation scope on 2026-08-31. FLEX-WP-0020-T05 still needs signing for its proposed live rename. State Hub's INTENT now places it in retirement planning. Reconfirm the runtime and demand with State Hub/repo-manager and the consumer before creating another transitional secret lane. Do not infer demand is withdrawn merely because the service is transitional.

7. Some operational code remains in the wrong long-term ownership home

Forgejo pruning, image-inventory integration and backup orchestration belong with railiance-forge, using S3's custody/storage interfaces and activity-core's execution. OpenBao package wrappers belong to rapp-openbao. ArgoCD bootstrap, generic delivery paths and individual app manifests need S2/S4/S5 splits. These are retained compatibility assets; deleting or moving them without accepting owners and tested callers would break working operations. RPF-WP-0036-T06 carries a concrete acceptance-based handoff, not an assertion that delegation already happened. The old architecture backlog RPF-WP-0011 stays closed; its unrelated fleet rows are not resurrected here.

8. Aspirational services need demand decisions, not speculative deployment

Cache, object storage and messaging fit INTENT. Valkey has no supported current consumer interface and its deployment is deliberately gated. External S3 backup consumption exists, so “no object storage” is too broad, while “MinIO provided” is also unsupported. No shared messaging service is established by this review. RPF-WP-0036-T07 must decide reuse, defer with a trigger, or accept a bounded consumer-backed delivery plan for each. Resource purchase/engine selection and provider deployment are not part of this assessment.

Ownership and handoff assessment

These are recommended/respected responsibility boundaries, not newly accepted external assignments. Existing task references show where owner work already exists; missing acceptance stays a platform follow-up rather than disappearing.

Platform task/surface	Owner work elsewhere	What stays here / completion boundary
RPF-WP-0015-T02	audit-core AUDIT-WP-0008 synthetic load/app proof; rapp-postgres database acceptance	Lease/ESO preconditions and restart-free recovery evidence for the exact consumer; fresh live window
RPF-WP-0015-T03	railiance-infra reboot, railiance-cluster recovery, audit-core app proof; existing reviewed procedure receipts	Snapshot/custody/quorum/ESO/database readiness contribution, not whole-host execution ownership
RPF-WP-0025-T03	rapp-openbao RAPP-OPENBAO-WP-0002; net-kingdom NK-WP-0032; S1/S2 DNS/network; ops-bridge tunnel	Exact OpenBao callback and private attended access acceptance; source readiness does not prove cutover
RPF-WP-0027-T03/T05	KEY-WP-0011 delivered; NK-WP-0033-T03/T05 residual command/evidence disposition	Accept provider evidence; do not repeat its completed rotation or take over resolver operations
RPF-WP-0027-T06	NetKingdom operator handoff and eventual routing consumer	Canonical confirmed custody coordinates, scope, lifecycle and receipt
RPF-WP-0029-T02	Provider owner for invalidation; RAIL-HO-WP-0012 for S1 backup; railiance-forge for forge recovery	Governed replacement custody and accepted invalidation/upload/restore evidence
RPF-WP-0035-T02	KEY-WP-0009 issuer; SECRETS-WP-0008-T06 login and SECRETS-WP-0007-T04 apply authority	Exact JWT role/policy and custody acceptance, not lifecycle engine implementation
RPF-WP-0035-T03	MASON-WP-0005 construction; FT-WP-0002 client; IAM group/assurance owners	Operator-write CCR/validator and exact OpenBao scope; no Telegram application logic
RPF-WP-0035-T04	State Hub runtime/rotation, FLEX-WP-0020-T05 cutover, repo-manager retirement coordination	Confirm demand; scoped signing-key custody and delivery; no repository rename
RPF-WP-0036-T04	railiance-telemetry Q2 receiving/emission contract	S3 signal semantics and producer/receipt acceptance
RPF-WP-0036-T06	Forge/package/S2/S4/S5 accepting owners; repo-manager/State Hub derived records	Exact inventory, stable contracts, tested handoff; preserve responsibility until accepted
RPF-WP-0036-T07	Resource-control/reef-storage procurement; artifact-store existing surface; railiance-master Q3 placement	Demand/reuse review and S3 service obligations; no fleet architecture program here

Task-level consolidation and status corrections

Source task	Disposition	Successor / reason
RPF-WP-0032-T02	wait → cancel (superseded)	RPF-WP-0035-T02; original JWT design preserved
RPF-WP-0033-T02	wait → cancel (superseded)	RPF-WP-0035-T03; original operator KV design preserved
RPF-WP-0034-T02	wait → cancel (superseded)	RPF-WP-0035-T04; original signing design preserved and demand qualified
RPF-WP-0015-T02/T03	progress → wait	Procedures prepared; live experiments/owner gates outstanding
RPF-WP-0027-T03/T06	progress → wait	Current evidence disposition and confirmed custody still outstanding
RPF-WP-0027-T04	wait → done	Existing KeyCape/NetKingdom owner-controlled replacement evidence; no new live act
RPF-WP-0027-T05	stays wait	Complete residual evidence/incident-owner disposition absent
RPF-WP-0025-T03	stays wait	Fresh attended callback/login and retraction proof absent
RPF-WP-0029-T02	stays wait	Provider invalidation and replacement recovery evidence absent

All other pre-existing task statuses are retained. No IDs or managed UUIDs are reassigned. Archive moves preserve identity; the JSON inventory records exact old/new paths. Historical evidence references keep their historical meaning; resolve moved records through the per-plan register below and the archive map.

Intent gap closure sequence

1. Keep the two exposure residuals first in the attended queue: RPF-WP-0027 and RPF-WP-0029. Close by evidence/disposition, not by recreating old actions.
2. In parallel with waiting for owners, begin RPF-WP-0036-T02 (service promises) and T05 (admission/disclosure consistency). These have local work available.
3. Finish private access under RPF-WP-0025, then schedule independent recovery exercises under RPF-WP-0015 with fresh gates. No combined blanket approval.
4. Implement recurring proof T03 and S3 emission T04 against owner contracts.
5. Advance each RPF-WP-0035 lane only as its consumer/issuer/authority gates clear. Revalidate the transitional signing demand first.
6. Complete compatibility handoffs and capability demand decisions, T06/T07. Do not build HA, cache, MinIO or a broker merely to make the scope sound full.

Derived-state caveat

The start-of-session topic query included other financial-domain repositories; it is not a repo backlog. After filtering the actual platform repo UUID, two active legacy aliases remained alongside their canonical records:

Legacy Hub record	Canonical source record
88c4ef7f-0af8-580e-90dc-a2bae2675a4d, railiance-wp-0024@retired-20260826	RPF-WP-0015, f4640325-e89c-591d-b58e-ec6b087900ac
038bc3c0-4492-5b91-95eb-ae515ca205df, railiance-wp-0029@retired-20260826	RPF-WP-0027, b2c25a01-4a80-55c1-90cf-8538000f7e0e

The generated brief is dated 2026-08-26 and also repeats stale work. These are not additional file-backed tasks. RPF-WP-0036-T06 records the scoped derived cleanup dependency; no blanket retirement or managed UUID rewrite is justified. The fast sync receipt verifies the current pushed source projection; it must not be interpreted as proof that all historical alias views were repaired.

Review limitations and maintenance

This is source/evidence review, not a live cluster, IAM, billing or service health audit. Sibling SCOPE files themselves sometimes lag owner workplans; newer dated task evidence takes precedence for the findings above. No previously approved live authority is renewed by a documentation edit. Existing unrelated history is unchanged. Revisit this assessment on an incident closure, consumer admission, telemetry contract availability or accepted service guarantee.

The following per-plan register is generated from the captured before-inventory and reviewed disposition map, not from the stale Hub brief.

Disposition of all 37 original plans

Workplan	Before → after	Assessment
RPF-WP-ADHOC-2026-08-23	finished → finished	Delivered tenancy evidence and broker test fixes; no residual project.
RPF-WP-0001	finished → finished	Delivered custody/grant broker; retain S3 policy, route future engine lifecycle to secrets-engine.
RPF-WP-0002	finished → finished	Delivered bounded delegated apply; S3 enforcement and approval boundary fit intent.
RPF-WP-0003	finished → finished	Delivered Issue Core runtime custody; app ingestion remains consumer-owned.
RPF-WP-0004	finished → finished	Delivered provider-key custody; provider/application lifecycle stays with its owner.
RPF-WP-0005	finished → finished	Delivered reuse-surface runtime custody; webhook application logic is consumer-owned.
RPF-WP-0006	finished → finished	Delivered OpenBao package boundary; compatibility handoff reviewed under 0036-T06.
RPF-WP-0007	finished → finished	Delivered PAT custody cutover; future pruning ownership belongs to railiance-forge.
RPF-WP-0008	finished → finished	Delivered CCR validation/test repair; keeps platform policy fail-closed.
RPF-WP-0009	finished → finished	Delivered S3 rapp/interface conventions; fleet family taxonomy stays with master.
RPF-WP-0010	finished → finished	Delivered apps-pg resource evidence; recurring freshness is 0036-T03/T04.
RPF-WP-0011	finished → finished	Delivered S3 architecture cleanup; unrelated fleet rows remain outside S3.
RPF-WP-0012	finished → finished	Delivered consumption-mode enforcement; consume policy, do not own commercial decisions.
RPF-WP-0013	finished → finished	Delivered agent high-risk deny coverage; retained S3 custody boundary.
RPF-WP-0014	finished → finished	Delivered hub-core candidate lanes; application migration stays with consumer/package.
RPF-WP-0015	active → blocked	Keep scoped recovery contribution; prepared procedures wait on fresh live gates.
RPF-WP-0016	finished → finished	Delivered ephemeral custody lifecycle; no unattended reaper authority implied.
RPF-WP-0017	finished → finished	Delivered output-containment repair; future drill still needs fresh acceptance.
RPF-WP-0018	finished → finished	Delivered tenancy/placement policy and ADR surface; ongoing drift is 0036-T05.
RPF-WP-0019	finished → finished	Delivered backup/controls/ceiling/isolation; correct stale SCOPE, do not reopen.
RPF-WP-0020	finished → finished	Delivered CCR migration/draft model; schema extension for new write lane is 0035-T03.
RPF-WP-0025	blocked → blocked	Keep private access cutover; exact attended login, package and network gates.
RPF-WP-0026	finished → finished	Delivered canonical authorization consumption; PDP remains outside S3.
RPF-WP-0027	active → blocked	Narrow to custody/residual evidence; owner rotation already delivered; no repeat rotation.
RPF-WP-0028	finished → finished	Delivered durable inventory; future forge/automation handoff is 0036-T06.
RPF-WP-0029	blocked → blocked	Keep provider invalidation/recovery evidence; source fallback removal alone is insufficient.
RPF-WP-0030	finished → finished	Delivered Core Hub onboarding; preserve distinct identity, reconcile disclosures in 0036-T05.
RPF-WP-0031	finished → finished	Delivered scoped identity repair; do not repeat or broaden UUID edits.
RPF-WP-0032	blocked → finished	Design delivered; implementation T02 superseded by 0035-T02.
RPF-WP-0033	blocked → finished	Design delivered; implementation T02 superseded by 0035-T03.
RPF-WP-0034	blocked → finished	Design delivered; implementation T02 superseded by 0035-T04; reconfirm transitional demand.
RAIL-PL-WP-0002	finished → finished	Historical secrets-service bootstrap; continuing assurance belongs to 0036, not reopened bootstrap.
RPF-WP-0021	finished → finished	Historical apps-pg bootstrap; stable identity preserved after previous collision repair.
RPF-WP-0022	finished → finished	Historical GitOps bootstrap; retained mixed ownership inventory goes to 0036-T06.
RPF-WP-0023	finished → finished	Delivered workload KV lane foundation; new demands use consolidated 0035.
RPF-WP-0024	finished → finished	Delivered CCR approval workflow; retain S3 policy and consume approval authority.
RAIL-PL-WP-0001	archived → archived	Retired baseline; six legacy cancelled tasks remain historical, not six open gaps.