railiance-platform/SCOPE.md

# SCOPE

Reviewed 2026-09-05 against repository source, dated operating evidence and
adjacent owner contracts. This is a scope assessment, not a fresh live audit.
[INTENT.md](INTENT.md) remains the stable aspiration.

## Purpose and boundary

Railiance's S3 shared stateful services: database provision and placement,
secret custody and delivery, and platform-data backup and recovery behind
versioned consumer interfaces. Cache, general object storage and messaging
remain demand-led capabilities; their inclusion in INTENT does not mean they
are deployed or justify running them without consumers.

S3 owns the service promise, custody and acceptance evidence. A `rapp-*` repo
owns its deployable package; the cluster and host owners supply the runtime.
Identity integration means consuming identity claims, not operating an identity
or authorization authority. See [ADR-0001](docs/adr/ADR-0001-s3-platform-service-boundary.md).

## Current evidenced capability

| Service | Implemented / evidenced | Limit and authority |
| --- | --- | --- |
| `apps-pg` | CNPG source, per-consumer database ACLs, 20-connection allowances, 15-second timeouts; daily backup, continuous WAL and 30-day retention; 56-second scratch restore and 14/14 boundary probes on 2026-08-20 | One instance; restart recovery, no HA or measured latency SLO. Ceiling 3, overflow `apps-pg-2` provisionable but demand-gated. S3 owns this CR and its controls. |
| `platform-pg` | Package-operated CNPG service, governed dynamic credentials, backup/restore evidence, Core Hub admission and private shadow evidence | `rapp-postgres` owns CR/provisioning/restore. S3 owns custody, placement policy and consumer disclosure. Ceiling 4 declarations, counting the probe; platform-pg is 4/4 and the deployed platform-pg-2 hosts sbom-nexus at 1/4. One instance is not HA. |
| OpenBao and credential delivery | CCR validation, policy/grant boundaries, approved apply interfaces, runtime KV/ESO and short-lived database lanes, ephemeral custody lifecycle | Package assets belong to `rapp-openbao`; custody/policy remains here. Existing helpers are not authority to mint arbitrary credentials. Operator-only access cutover and incident residuals remain open. |
| Backup storage consumption | Governed off-cluster S3 backup destination and credential lane used by CNPG; encrypted upload tooling for other backup consumers | Resource procurement belongs to `resource-control`/`reef-storage`. This does not establish a general S3 service or deployed MinIO. One successful restore does not establish a recurring recovery guarantee. |
| Cache / general object storage / messaging | Valkey deployment is gated; no supported consumer interface or deployed shared broker/general in-cluster object store is established by this review | Demand, reuse, ownership, service contract and recovery design must precede deployment. No engine/provider choice is made here. |

Evidence and contracts: [consumer interfaces](docs/s3-consumer-interfaces.md),
[apps-pg restore](docs/evidence/RPF-WP-0019-backup-restore-2026-08-20.md),
[apps-pg isolation](docs/evidence/RPF-WP-0019-isolation-2026-08-20.md),
[placement](docs/placement-policy.md), [tenancy](tenancy.yaml), and
[Core Hub capacity admission](docs/evidence/core-hub-postgres-capacity-admission-2026-08-20.md).
The former “apps-pg has no backup” and “both ceilings missing” scope statements
were stale. Dated evidence above must not be presented as current health.

## Responsibility split

| S3 retains | Other owner / handoff |
| --- | --- |
| Database service placement, custody and acceptance | `rapp-postgres`: package, admission enforcement and restore; consumers: schemas, migrations, workload SLOs and app verification |
| OpenBao service custody, ACL/role review, approved delivery and revocation proof | `rapp-openbao`: package; `key-cape`/`net-kingdom`: issuer, OIDC/MFA, directory/provider reconciliation |
| Platform acceptance of a credential lane | `secrets-engine`: lifecycle engine; `ops-mason`: construction coordination through engine APIs; `flex-auth`/access-engine and `approval-engine`: decisions and approval consumption |
| Service health semantics, recovery expectations and evidence production | `railiance-telemetry`: Q2 collection, retention and alert transport; it is not S3's monitoring implementation to build |
| Platform snapshot/unseal/readiness contribution to an outage | `railiance-infra`: host/reboot; `railiance-cluster`: Kubernetes/restart; consumer owner: synthetic load and application acceptance |
| Database/object-store/credential interfaces consumed by the forge | `railiance-forge`: forge backup orchestration, artifact retention and pruning; `activity-core`: automation execution |
| Scope accuracy and file-backed source records | `railiance-master`: fleet taxonomy and Q3 placement; `repo-manager`/State Hub: derived record identity and projection correctness |

DNS, host firewall, TLS/ingress primitives, Kubernetes runtime, CI templates,
application releases, business logic and identity/authorization decisions are
outside S3. Existing Forgejo helpers, ArgoCD bootstrap/application manifests,
and OpenBao package compatibility assets are retained migration surfaces, not
an expansion of that boundary. Transfer requires an accepting owner and tested
replacement entry points; source files are not deleted merely to tidy scope.

## Work that closes the intent gaps

The [current work index](workplans/README.md) groups six open workplans.
The [full assessment](history/2026-09-05-platform-intent-workplan-assessment.md)
records every reviewed plan and the consolidation mapping.

| Priority | Gap | Canonical work |
| --- | --- | --- |
| First | Reported credential exposures need final disposition and dependable operator custody | RPF-WP-0027: KeyCape/NetKingdom residual evidence and S3 custody; RPF-WP-0029: provider invalidation and replacement backup recovery |
| First | Private attended OpenBao access remains unproven end to end | RPF-WP-0025-T03; keep its window separate from incident/recovery actions |
| Next | Recovery procedures exist, but two cross-owner exercises still lack completion evidence | RPF-WP-0015-T02/T03: S3 contribution, with audit-core and S1/S2 executing their own parts |
| Next | Three requested credential lanes have designs but no live acceptance | RPF-WP-0035: one queue with separate consumer/issuer/approval gates |
| Next | Numeric availability/recovery promises, evidence freshness, recurring drills, emission and admission drift lack a complete S3 acceptance loop | RPF-WP-0036-T02–T05 |
| Next | Compatibility ownership, stale Hub aliases, and undeployed capability demand need explicit disposition | RPF-WP-0036-T06/T07 |

RPF-WP-0036 now provides local assurance/admission checks and explicit service
disclosures; its remaining tasks wait for live proof and owner acceptance.
It must define achievable promises for the existing single-node substrate,
not declare HA through documentation. Any stronger availability target needs
an S1/S2 dependency and a package-level failover proof. Fleet-wide Q3 ownership
is an architecture question; it does not suspend S3's own recovery obligations.

## Provided capabilities

```capability
type: infrastructure
title: PostgreSQL via CloudNative PG (cnpg)
description: Shared database service and placement policy with apps-pg controls and rapp-postgres package integration. Current evidenced deployments are single-instance; HA is not established.
keywords: [postgresql, postgres, cnpg, cloudnative-pg, operator, database, kubernetes]
```

```capability
type: infrastructure
title: Valkey / Redis-compatible cache
description: Declared shared cache capability, not a supported live service. Deployment stays gated on an accepted consumer and service contract.
keywords: [valkey, redis, cache, shared, session, queue]
```

```capability
type: data
title: Object storage (MinIO / S3-compatible)
description: Governed external S3 backup-storage consumption exists. A general shared object-storage service, including in-cluster MinIO, remains undeployed and demand-gated.
keywords: [minio, s3, object-storage, storage, artifacts, backup]
```

```capability
type: security
title: OpenBao platform secrets service
description: S3 custody, policy and approved runtime credential delivery; package assets belong to rapp-openbao. SOPS/age supports bootstrap custody. New lanes need independent live acceptance.
keywords: [openbao, secrets, vault-compatible, secret-management, dynamic-credentials, audit, kubernetes-auth]
```

## Getting oriented

Read [AGENTS.md](AGENTS.md), [INTENT.md](INTENT.md), then
[workplans/README.md](workplans/README.md). Completed plans are preserved under
`workplans/archived/`; [WORK-RECORDS.md](WORK-RECORDS.md) is the generated current
index (archives omitted). Routine sync follows AGENTS.md. The dated `.custodian-brief.md` and Hub
legacy aliases are not additional authoritative obligations.

## Assurance implementation — 2026-09-05

`make assurance-admission` checks package-native capacity/retention and source
disclosure drift. `make assurance-capture` pins the cluster and collects only
status metadata; `make assurance-check` fails on incomplete/stale/failed evidence.
The first live run found all three database cells Ready with same-day backups
and archiving, but three failing ESO resources. Recurring restore acceptance,
validated restore adapters and Q2 delivery remain open. See
[service assurance](docs/service-assurance.md) and RPF-WP-0036.