Raxx · internal docs

internal · gated

ADR-0075: Billing Stays in Queue — Operator Override of ADR-0073

Status: Superseded by ADR-0076 Superseded by: ADR-0076 (2026-05-11 UTC) — operator clarified that v1 launches WITH billing-in-Queue on the aggressive 12-day timeline; ADR-0075's framing that "v1 launches without billing" is incorrect. Date: 2026-05-11 UTC Refs: ADR-0071 (Queue-as-authority — confirmed), ADR-0073 (Raptor stopgap — superseded by this ADR), docs/architecture/stripe-customer-billing.md (v3 design — unchanged target) Supersedes: ADR-0073

Operator decision verbatim

2026-05-11 ~21:08 UTC, in response to ADR-0073 (Raptor stopgap proposal):

"Billing is going to Queue, if it means slippage, so be it. Do not put billing in stopgap mode. Go ahead and wait for full onboarding with stripe once queue is built."

Decision

Billing tables (billing_customer, billing_subscription, billing_invoice, processed_stripe_events, billing_action_log, billing_reconcile_log) ship in Queue, per ADR-0071's original intent. The Raptor-stopgap path from ADR-0073 is rejected.

Sub-cards #406, #407, #408, #409, #1630, #1631, #1632, #1633, #1635 stay labeled area:queue. No retarget to area:raptor. They are blocked until Queue's foundation is built.

v1 launch posture (2026-05-23 UTC) — REVISED by ADR-0076

This section reflects the original interpretation of the operator decision, which was subsequently clarified.

Original interpretation: without billing in v1, the launch posture was free signups only, paid tiers handled manually.

Correct interpretation (ADR-0076): Operator's follow-up at 21:18 UTC ("No, v1 comes with billing...") and 21:20 UTC ("Hold 2026-05-23 launch — compress Queue + billing into 12 days (Aggressive)") clarified that v1 ships ON 2026-05-23 WITH billing-in-Queue. The launch date and architectural integrity are both non-negotiable. Engineering sprint posture.

See ADR-0076 for the corrected framing and the 12-day aggressive execution plan.

Why operator overrode the architect

Architect's analysis (ADR-0073) optimized for the v1 deadline. Operator optimized for architectural integrity + avoidance of stopgap debt.

The architect's case for Path B was real: - 12-day launch window - Queue not built - Schema portable, migration mechanical - "Architectural purity is a post-launch problem when the deadline is fixed"

The operator's case for rejecting Path B: - Stopgaps tend to outlive their stated lifespan - Billing PII in the wrong DB creates GDPR/audit complexity that's costly to claw back - A rushed Queue migration post-launch produces the same risk in reverse (rushed migration, billing-in-flight, customer money in the middle) - Manual Stripe ops for v1 customers is bounded — N customers × ~5 min each — and forces ops discipline that's valuable in early days - Architectural integrity is a load-bearing decision for the whole platform's future shape (Queue is meant to own customer identity, billing, RBAC, audit — letting one of those slip "temporarily" sets a pattern)

Both positions are defensible. Operator's call stands. Architect's analysis preserved in ADR-0073 for historical record.

What this changes

Sub-cards (no retargeting needed)

Design doc

docs/architecture/stripe-customer-billing.md v5 reverts the v4 "Raptor stopgap" addendum. Schema unchanged. Queue is the v1 home.

Queue priority

Queue moves from "architectural target with no timeline" to "critical path for billing." Queue's Phase 1 work becomes the next architecturally-significant epic.

Status

Superseded by ADR-0076. The core decision (billing stays in Queue, no stopgap) is confirmed and carried forward. What ADR-0076 corrects is the v1 launch posture: billing ships WITH v1, not after.