Skip to content

The Deployment-Model Pivot — ADR-108

The Deployment-Model Pivot — ADR-108

Date: 2026-08-06 · Written in English per the 2026-08-01 convention change.

Provenance. An executive decision by the project owner, not a delegated ruling and not an audit finding. It is recorded in the same form as the delegated rulings because the obligation is identical — a decision without a written argument cannot be adjudicated later — but its authority is different, and that difference is stated rather than smoothed over: the commercial half of this decision is the owner’s, and nothing below reconstructs a rationale for it that was not given.

Numbering. The brief that requested this work proposed ADR-107. That number was already allocated on the same day to the vendored-module fork rule (Architecture_Decision_Rulings_R15.md), and §11’s index carries it as Accepted. Reusing it would have produced two Accepted records under one identifier — the exact failure ADR-045 §2 exists to prevent, and one this corpus has already suffered once with two mutually exclusive UGC isolation models coexisting under no status at all. This is ADR-108.

This file continues the R-numbered sequence for filing purposes only. There is no R10; the sequence is a filing convention, not a contiguous range.


ADR-108 — Exclusive Platform-Managed Deployment (Deprecation of the Self-Hosted Profile)

Status: Accepted · Date: 2026-08-06 · Amends 081 · Amends 083 · interacts with 030, 061

Context

§10 defined three deployment profiles and stated that no fourth was supported: Managed SaaS, Self-Hosted Single Container, and the DR Tier. The self-hosted profile was not a marketing line — the document committed to it as “a genuine first-class target”, and that commitment propagated into the invariants as exemptions:

  • ADR-081 (no audio or video is ever persisted) was scoped to the platform deployment and explicitly not extended to self-hosted, where the SFU is operator-run.
  • ADR-083 (the declared region pair) rejected a hardcoded region partly because it “would be wrong for both the Self-Hosted profile and any operator-chosen deployment”.
  • §6.1’s content protection was unavailable in that profile, because key custody cannot be assured off-platform.

The pattern is the load-bearing part. A deployment profile the platform does not control cannot carry a platform guarantee, so every guarantee written against it acquired a caveat — and a caveat on an invariant is not a smaller invariant, it is a different and weaker claim that a reader must remember to apply. Phase 4’s data-subject review reached the same boundary from the other side and asked for the self-hosted SFU to be named as a data-handling boundary rather than left as a capability footnote.

The owner’s decision is that the product is a managed platform. The architectural consequence is that the caveats have no remaining subject.

Decision

  1. Descent VTT is exclusively platform-managed. The Self-Hosted Single Container profile is removed from §10 and is not a supported target. Two profiles remain: Managed SaaS and the DR Tier (ADR-030), and the DR tier is the platform’s own business- continuity mode rather than a third party’s deployment.
  2. The platform’s guarantees are universal within the platform, and say nothing beyond it. Where a guarantee was previously scoped “platform deployment, but not self-hosted”, the exclusion is deleted rather than reworded — there is no longer a second deployment for it to exclude.
  3. ADR-081 becomes unconditional for the platform. No audio or video is persisted, with no deployment-shaped exemption. Its other limit is unchanged and must not be quietly widened by this ADR: the invariant never covered participants, and a GM or player running local screen or audio capture remains entirely outside it. Removing one caveat is not licence to drop the other, and conflating them would convert an honest scope statement into a false claim of total coverage.
  4. §6.1’s content protection is universally available, because key custody is now assured in every supported deployment. This required no edit to §6.1: its only exemption lived in §10’s profile matrix, and deleting the row deletes the exemption.
  5. ADR-083’s mechanism survives; only half its rationale is retired. A declared jurisdictional pair asserted in the infrastructure definition remains correct and remains the enforcement point. What lapses is the argument that hardcoding was wrong because a self-hosted operator’s geography is unknowable — the platform now knows its own. The mechanism is kept anyway, and the reason is recorded so a future reader does not mistake it for an oversight: a declared-and-asserted pair fails to provision on a crossing, whereas a hardcoded constant is a value somebody can edit without review.
  6. This ADR does not delete history. Records that reasoned about self-hosted constraints keep their text and receive a dated amendment block citing this ADR. Their diagnoses remain valid; only the profile they applied to is gone.

Alternatives Considered and Why Rejected

  • Keep the profile as “community, unsupported”. Rejected, and this was the closest call. It preserves goodwill at the cost of the exact ambiguity that motivated the decision: an unsupported profile still appears in the matrix, still needs every managed component to have an in-process substitute, and still forces every invariant to carry a caveat for a configuration nobody tests. The caveat, not the code, is the cost being removed.
  • Retain the invariants’ self-hosted exclusions as historical text in §10. Rejected under P6: a caveat retained in the authoritative specification is a live caveat, whatever the surrounding prose says about it. The place for history is the ADR record, which is where it has been put.
  • Delete the self-hosted discussion from R4 and the Phase 4 review. Rejected outright. Those files are decision records and audit history; docs-and-adr-workflow.md §1 and §7 are explicit that they are not drafts. A finding that was correct when written stays correct when written — an amendment block records that its subject was withdrawn, which is a different statement from the finding having been wrong.
  • Renumber the existing ADR-107 to free the number the brief asked for. Rejected. §11 carries 107 as Accepted and four documents cite it; renumbering an accepted decision to satisfy a draft’s placeholder is how a citation becomes a dangling reference.

Consequences (including negative)

  • A category of user is now unserved, and no architecture change gives them back. The community GM who would run one container is not a smaller customer; they are not a customer. That is a product decision with an architectural consequence, stated here so it is not later rediscovered as a surprise.
  • Every managed component loses its documented in-process substitute obligation. This is the largest simplification the pivot buys, and it is also a one-way door: the substitutes were never built, so reinstating the profile is new work rather than re-enabling a flag.
  • The DR Tier is now the only reduced-capacity topology, so it carries alone the burden of proving that the system runs without a backplane. Previously two profiles exercised that path; now one does, and it is the one that only runs during an incident. This is a real reduction in coverage and is the strongest argument the rejected alternative had.
  • Nothing about the tick budget changes. §5.2’s per-host bound was never a self-hosted concession — it is a property of one Orleans activation — and Open_Items_S1_and_BENCH04.md cites the self-hosted profile only as a worked illustration of it. The illustration is retired; the bound is not.

Rights-holders (ADR-079)

None. This decision retains no new class of data. It narrows the set of parties who handle player media: the operator-run SFU that ADR-081 could say nothing about no longer exists as a supported configuration.

Enforcement

  • §10’s profile matrix is the enforcement point for the profile’s removal — a row is either there or it is not, and adr_link_lint.py holds the index consistent with the records.
  • ADR-081’s enforcement is unchanged: the SFU deployment definition, with LiveKit’s recording and egress capabilities not deployed and their absence asserted in the infrastructure definition. What changes is that there is no longer a deployment the assertion cannot reach.
  • ADR-083’s enforcement is unchanged: a crossing region pair fails to provision.
  • No new normative sentence is introduced by this ADR, which is deliberate. It removes a profile and deletes exemptions; it does not add a requirement that would need an enforcement point of its own (ADR-045 clause 2).