ADR 002 — Daily-close crossings and sparse balances

Status: implemented; decision recorded 28 September 2026

Context

The original daily-balance output and (stock key, crossing day) alert identity need one unambiguous crossing rule. Intraday crossings could occur more than once per day and would need a different identity model.

Decision

Use UTC daily-close crossings: previous close at or above the fixed reorder threshold, current close strictly below. Use the opening balance as the predecessor for the first activity day. Do not emit an alert merely because the opening balance already starts below threshold.

Publish balance facts only for days containing at least one active transaction. Carry balances implicitly across gaps. Withdraw a previously published balance when its final active transaction disappears. Keep current and historical results correction-aware; calendar midnight does not finalize a fact forever.

Alternatives

Intraday running-balance alerts would add ordering-dependent business semantics and require finer identities. Dense daily balances would avoid disappearing activity-day rows but require a defined reporting horizon and extra synthetic daily output.

Consequences

The example remains compact and consistent with its day-based IDs. A crossing alert represents a still-valid historical crossing, not an outstanding order or current-low-stock flag. A later receipt does not retract the earlier fact. Corrections can do so.

The (ValidTime, TxnID) traversal remains deterministic, but equal-time order is not load-bearing for additive daily totals. A TxnID-tiebreak mutation need not fail the business-equivalence property.

Review trigger

Change this decision only if intraday crossing behavior or a dense reporting calendar becomes a deliberate new showcase objective, with corresponding changes to the contract, IDs, oracle, and tests.