ADR 0001 — Simple product; legacy is not the spec

Date: 2026-07-29
Status: Accepted
Deciders: RevRec redesign working session

Context

The current Chargebee→RevRec path (Hotglue ETL, OrderDetails manufacturing, Camunda sync jobs, Redis/SingleStore dual stores) is complex and hard to operate. It is easy to treat that stack as requirements.

Decision

RevRec Next is designed as a simple ASC 606 revenue subledger (+ AR sibling) that delivers what the product advertises.

• Optimal architecture first.
• Existing systems are a quarry (tests, edge policies, merchant configs) — not the architecture to clone.
• Move pieces only when the target can replace them; leave the rest behind.
• Correctness = ASC 606 + audit + close — not CSV sheet parity with Hotglue.

Consequences

• Docs and code grow in revrec-next (and extract in temporal_poc) without requiring Hotglue/Camunda shapes.
• Migration uses shadow accounting compares.
• Features like multi-PO SSP / usage land as explicit policies when demand is proven.

Alternatives considered

1. Incremental rewrite inside revanu/Hotglue constraints — rejected as primary strategy (keeps accidental complexity).
2. Full parity-first port of contracts.py — rejected as definition of done.