Some values record a decision. Others answer a question about current data. Treating both as a single status makes it unclear what a refund, correction or period change should update.
In the commerce platform, I keep an assigned partner level separate from transaction-based eligibility. The labels and business thresholds are omitted here; the useful engineering question is what each value means over time.
Store a decision; derive a current answer
| Value | Source of truth | Effect of a later correction |
|---|---|---|
| Assigned level | The recorded business decision | Apply the defined review or adjustment process |
| Current eligibility | Period totals and configured rules | Recompute from corrected inputs |
| Completed payout | The recorded financial event | Preserve the event and apply an adjustment |
Recomputing a past decision from today’s data can erase why it was made. Storing a copy of current eligibility creates a different problem: every refund, correction and period boundary must remember to refresh it.
The implementation uses a shared qualification calculation for the current answer. Consumers supply an explicit period, rather than inferring it from a process’s local clock.
Keep eligibility separate from money movement
Recording a commission and deciding whether it may be paid are separate operations. Eligibility can change after accrual. A payout therefore checks the applicable conditions and claims a payable record before crediting the account.
A refund also needs the original calculation basis. Applying today’s rate to yesterday’s event would produce a different reversal, even if both calculations were individually valid.
Keep aggregate and individual views consistent
An administrative summary should count the same qualifications that an individual query returns. The implementation has both individual and aggregate paths; tests check their agreement, empty inputs and period selection.
This is an easy place to introduce drift. A dashboard query may look like harmless reporting, yet become a second interpretation of the business rule. Shared semantics and boundary tests matter more than whether the code uses one query or several.
A derived value is appropriate when its inputs and period are explicit. A stored record is appropriate when the fact that a decision occurred must survive later changes.