56d516e10c
RPLAT-ADR-0001–0003 so policy-nexus can register the S3, placement, and file-backed decision records.
68 lines
3 KiB
Markdown
68 lines
3 KiB
Markdown
---
|
|
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.
|