---
id: RPLAT-ADR-0002
title: "ADR-0002 — S3 owns the placement rule; the package repo owns the number"
status: proposed
revision: "1.0"
owner: railiance-platform
date: "2026-08-17"
last_reviewed: "2026-08-17"
review_interval: 6m
---

# ADR-0002 — S3 owns the placement rule; the package repo owns the number

## Context

An earlier draft of
`net-kingdom/canon/standards/tenancy-posture_v0.1.md` §8.2 proposed that
database placement policy — dedicated versus shared, and when that changes —
be owned by `railiance-platform`, co-signed by `adaptive-pricing`.
`tenant-engine` raised the same gap independently on 2026-08-16: both patterns
are live on railiance01, neither is written down, and each new service copies
whichever neighbour it looked at.

The complication is that this repo no longer holds the specs. `RAILIANCE-WP-0012`
and `RAILIANCE-WP-0015` moved the deployable surface to the `rapp-*` repos.
`platform-pg`'s `instances`, `max_connections`, memory limit and retention are
`rapp-postgres`'s cluster CR. Tenancy Posture §19.8 nonetheless asks *this repo*
for `platform-pg`'s declared maximum size — a question one hop from where its
answer lives.

Accepting ownership without stating this would produce either an answer we
cannot substantiate or a quiet non-answer.

## Decision

**Accept placement ownership, split along rule and number.**

*This repo owns the rule:* the default placement level, what overrides it, who
is accountable for each workload's placement, that a shared cluster must publish
a ceiling and an overflow target before its third consumer, that retention has a
floor and a ceiling, and that a consumer's erasure horizon on shared substrate
is disclosed rather than inherited silently.

*The package repo owns the number:* what the ceiling actually is, which resource
binds first, what the retention values are, and the validator that enforces them
where the CR lives.

**Placement ownership per workload sits with the consuming repo; this repo
co-signs.** The consumer knows its latency requirement, erasure horizon and
compliance position; S3 knows the substrate. A placement change needs both.
Putting the decision solely here would recreate the problem §8.2 exists to
avoid — an operations-shaped repo holding a commercial decision alone.

`adaptive-pricing` declined the standing co-signature on 2026-08-17. The
replacement is binding and machine-reconcilable: it publishes typed tier
minimums; this policy validates placement against them. Ownership stays here.

## Consequences

- `docs/placement-policy.md` is the operative document; this ADR is the
  decision behind it.
- §19.8 is answered for `platform-pg` by `rapp-postgres` ADR-0004: four
  consumers, with `platform-pg-2` named as the still-absent overflow target.
  Rule P-4.1 still requires `apps-pg` to declare its own ceiling before its
  third consumer.
- This repo owes `apps-pg`'s ceiling under its own rule. A policy whose author
  is exempt is not a policy.
- §8.1 requires triggers to be *monitored*. This repo has no monitoring plane,
  so the connection-and-memory-ceiling trigger is recorded `unmonitored`
  pending `railiance-telemetry`. Declaring a ceiling is a partial substitute —
  a written threshold is checkable by a human at provisioning, which beats a
  limit discovered by an OOM kill.
- `adaptive-pricing`'s decline is recorded as single policy ownership plus a
  mandatory typed constraint join, not as an absent signature.

## Alternatives considered

**Decline ownership; route it to `rapp-postgres`.** They hold the specs and the
operational knowledge. Rejected: placement is a cross-cluster question and
`rapp-postgres` owns one package. A policy owned by one substrate's operator
cannot govern movement between substrates.

**Accept whole, including the numbers.** Rejected: it would either re-import
the deployable surface this repo deliberately gave up, or produce numbers
restated here that drift from the CR — a second source of truth for exactly the
values a consumer must be able to trust.