Standard rate scheduling is permanent until overridden

Date: 06-08-2026 Author(s): Jayden Vicarey Source: EM-3691 rate-guard team discussion (prior team consensus restated)

Hub can schedule standard rates (discount / cashback) via scheduled changes. The scheduled-change domain also supports temporary changes with an expiry action of CREATE_UPDATE (revert to prior values) or DELETE. For promotions, temporary windows with a DELETE (or revert) at end are correct. For standard rates, allowing a scheduled "end" would make the rate temporary — which is what a promotion already models.

The team previously decided that Hub standard-rate scheduling is permanent until a later override. A legacy Hub endpoint still exposes revert/DELETE behaviour for discount/cashback scheduled changes; developers know not to use that path for standard rates. DiscountChangeProcessor and CashbackChangeProcessor still handle Operation::DELETE because of that legacy surface.

Decision Drivers

Keep a clear domain split: promotions are temporary windows; standard rates persist
Avoid modelling "ending a standard rate" as a first-class Hub workflow
Document legacy DELETE support so it is not treated as the intended product behaviour
Enable cleanup of legacy endpoint and DELETE handling without reopening the product rule

Considered Options

Standard rates are permanent until overridden

No Hub-first-class end/revert for standard rates; next CREATE_UPDATE replaces the current rate.

Allow temporary standard rates with revert/DELETE on expiry

Treat standard rates like promotions with start and end scheduled changes.

Keep legacy DELETE indefinitely as a supported Hub feature

Document and test DELETE for discount/cashback as intentional ongoing behaviour.

Decision Outcome

Chosen: Standard rates are permanent until overridden.

Justification: A standard rate that ends is effectively a promotion. Permanence until the next scheduled/override CREATE_UPDATE keeps the model simple and aligns Hub with how rate conflict guards treat standard rates (they remain in effect for later promotions).

Legacy DELETE on discount/cashback processors and the legacy endpoint are deprecated transitional support and should be removed in a follow-up cleanup — not expanded.

Consequences

Positive

Clear mental model for Hub authors and rate-guard logic
Touches between promo end and standard-rate CREATE_UPDATE are about starting a new permanent rate, not ending one
Cleanup work has an explicit ADR to cite when deleting legacy DELETE paths

Negative

Processors still contain DELETE branches that look like supported behaviour until cleanup lands
Confusion risk if someone uses the legacy endpoint's revert/DELETE for standard rates

Neutral

Promotional rate DELETE/CREATE_UPDATE pairs remain the supported temporary-window mechanism
ADR 0002 (DELETE before CREATE_UPDATE ordering) still applies to promo reverts and any remaining legacy DELETE rows