ADR-005: Single-Operator Multi-Environment Tenancy

Status: Accepted
Date: 2026-05-18
Sprint: SPRINT_20260518_054_Single_tenant_product_position.md

This record defines the trust boundary of a Stella Ops deployment: one deployment runs inside one operator’s trust boundary, and the “tenants” inside it represent environments and sub-organizations under common control — not mutually adversarial SaaS customers. Read it before reasoning about tenant isolation guarantees, planning per-customer hosting, or filing a product-gap verdict that assumes hostile multi-tenancy. For the token-selection mechanics inside this posture, see ADR-002.

Context

ADR-002 defines how a caller selects one tenant for a token. This ADR is orthogonal: it defines who those tenants are allowed to represent in a deployment.

EvidenceLocker F11 and its follow-up sweep proved route-level tenant isolation through slug resolution, envelope-bound identity, and tenant-scoped service authorization. Requests for one tenant must not read another tenant’s evidence, findings, or audit data, and the same envelope-bound stellaops:tenant claim is the architectural source of tenant context across services.

Tier 7 operator-trust planning on 2026-05-18 identified three missing product surfaces that determine whether mutually adversarial tenants can safely share one deployment: per-tenant disk or object-store quotas, tenant-partitioned rate limits, and automated hard tenant-delete. Without those surfaces, one tenant can consume shared storage, saturate shared routing capacity, and cannot be cleanly offboarded by a supported product workflow.

The license posture already prohibits multi-tenant SaaS commercial hosting without a commercial arrangement. This ADR makes the architecture posture match that legal posture so product docs, operator expectations, and future QA verdicts are consistent.

Decision

Stella Ops is a single-operator deployment product. One deployment is operated inside one trust boundary.

“Tenants” inside that deployment represent environments, business units, sub-organizations, or other logical scopes that share the same operator trust assumptions: the same security team, on-call authority, incident-response owner, deployment policy, and data-residency posture.

Cross-tenant adversarial workloads are out of scope for the current architecture. Tenant isolation guarantees protect against accidental cross-tenant leakage and mistakes by trusted users, not against an unrelated tenant that is intentionally trying to deny service, exhaust storage, probe covert channels, or exfiltrate from another tenant.

Consequences

Supported deployment patterns:

Unsupported deployment patterns:

Operator obligations:

QA implications:

Documentation implications:

Compliance and legal implications:

Future Direction

This ADR may be revisited only after all of the following ship and are verified by a fresh Tier 7 run:

  1. Per-tenant disk and object-store quota enforcement at write boundaries, plus a quota_remaining_bytes observability query.
  2. Router rate-limit partitioning on the resolved stellaops:tenant claim, with per-tenant budgets.
  3. A hard tenant-delete workflow with cross-database cleanup, dry-run mode, idempotency, and audit.
  4. Per-tenant audit isolation verified across claim, header, query, and direct-id attack vectors.
  5. A per-tenant tester cleanup endpoint so adversarial test runs can remove fixture data without cross-contamination.
  6. A product decision for tenant-scoped GDPR Article 17 erasure that remains compatible with EvidenceLocker immutability.

When all prerequisites are complete, open a new sprint to re-open or supersede this ADR. The architecture posture and license posture must remain aligned.

References