RPLAT-ADR-0001 accepted · 1.0 railiance-platform reviewed 2026-08-17generated from canonical source — do not edit

ADR-0001 — S3 owns platform services, not the substrate beneath them

Source: railiance-platform · docs/adr/ADR-0001-s3-platform-service-boundary.md · 62423fd0925d75f5a2b27034044dc1080823d341

Review due: 2027-02-17

Context

railiance-platform is S3 on the OAS Stack: the shared services several applications depend on — PostgreSQL, secrets, cache, object storage. The layers around it are S1 railiance-infra (OS and host concerns), S2 railiance-cluster (Kubernetes runtime, ingress), S4 railiance-enablement (tooling and CI), S5 railiance-apps (workloads).

This boundary has been stated in SCOPE.md and in ADR-003 of railiance-infra since the five-repo split, and it has been tested twice. RAIL-PL-WP-0001 existed to extract platform services out of S2 subcharts. On 2026-08-17 POLICY-NEXUS-WP-0001 assigned this repo "the substrate — DNS, TLS, ingress, hosting" for policy.coulomb.social, which would move the boundary back the other way.

The pressure is predictable and will recur: S3 is the layer that looks like it owns infrastructure, because it owns things that feel infrastructural. Recording the rule as an ADR rather than as a line in SCOPE.md gives future requests something to be answered against.

Decision

**S3 owns shared platform services and the interfaces consumers bind to. It does not own DNS, TLS, Kubernetes ingress, host configuration, or CI.** A request that would place any of those here is redirected to S1, S2 or S4 rather than absorbed, even when this repo is the closest available owner and even when absorbing it would be faster.

Where S3 has a genuine part in such a request — an object-storage bucket, a credential lane, a database — it supplies that part and co-signs the rest. It does not become the owner of the whole by being the first repo asked.

Consequences

  • POLICY-NEXUS-WP-0001 T04 needs splitting: ingress and TLS to S2, DNS to S1 or the reef boundary, storage and credentials here. Routed as RPF-WP-0018 finding F1.
  • A request this repo declines does not thereby become nobody's. Declining carries an obligation to name the owner, which is why F1 names two.
  • The rule cuts against this repo's convenience in the common case. That is what makes it a rule rather than a preference.
  • rapp-openbao and rapp-postgres are the same principle applied inward: the deployable package left, custody and policy stayed. See docs/rapp-openbao-boundary.md and docs/rapp-postgres-boundary.md.

Alternatives considered

Accept the substrate assignment as written. Fastest, and the requester had already resolved it with the operator. Rejected: it re-imports the coupling RAIL-PL-WP-0001 spent a workplan removing, and a boundary that yields to whoever asks most recently is not a boundary.

Own ingress for S3-adjacent services only. A narrower version, and it fails on the first argument about what counts as adjacent. The line has to be drawn where it can be checked.