## 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.