---
id: RPLAT-ADR-0001
title: "ADR-0001 — S3 owns platform services, not the substrate beneath them"
status: accepted
revision: "1.0"
owner: railiance-platform
date: "2026-08-17"
last_reviewed: "2026-08-17"
review_interval: 12m
---

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

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