railiance-platform/docs/adr/ADR-0001-s3-platform-service-boundary.md
codex e7e4e33bb8 RPF-WP-0018 T01-T06: publish S3 posture, placement policy, quotas, ADR surface
T01 docs/tenancy-posture.md - vector set per service rather than one repo
vector, with the provider-versus-consumer finding routed to net-kingdom.
T02/T03/T06 docs/placement-policy.md - accepts placement ownership scoped
to rule-here/number-there, records a placement owner per workload, reports
the latency-critical + batch co-residency on platform-pg, marks the
connection-ceiling trigger unmonitored pending railiance-telemetry, and
answers the retention floor/ceiling question.
T04 s3-consumer-interfaces 1.1.0 - quota disclosure per SS10.2. Surfaces
that apps-pg has no backup, no resource limits and no tuned parameters.
T05 docs/adr/ created with a mandatory-frontmatter convention and the
first three ADRs. This repo previously held none.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-17 21:55:11 +02:00

67 lines
3 KiB
Markdown

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