Tagged ledger
5 pieces
- · 10 min read
The Balance Behind Every Screen: Thirteen Modules of Leave Screens Are One Arithmetic Identity
An entitlement system written up as thirteen modules of screens has one real deliverable, and it is an arithmetic identity: allocated, less used, less pending, equals available. That identity has to stay correct through cancellations after a calendar change, double submissions, administrative adjustments and year-end resets. A click-through acceptance checklist exercises none of those, which is how these systems pass acceptance and then produce balances nobody can defend.
- · 10 min read
Entries Are the Record, the Balance Is a View
A balance held in a column is a cache with no source behind it. Every correction becomes an edit, and nothing in the system can reconstruct how the number reached its current value. Derive the balance from entries instead and it is explainable at any date, while corrections become entries rather than edits. The cost is real: derivation is slower than reading a column, and a stored snapshot is an optimisation of the derivation rather than a replacement for it.
- · 10 min read
A Correction Is An Entry, Never An Edit
An administrative correction applied by editing a figure destroys the ability to reconstruct how that figure reached its value, and it hides the fact that a correction happened at all. Recorded as its own entry, with a reason and an author, the balance still derives from the entries and the correction stays visible to everyone who later asks why the number moved. The hard part is the reason, not the arithmetic.
- · 10 min read
Year-End Is a Rule, Not a Reset
Carry-over, expiry and lapse at a period boundary are derivation rules applied at a date. Implemented as a destructive reset that overwrites the previous period's state, the previous year becomes unreconstructable and any retrospective correction is impossible. The reset version is always the one chosen first, because it is a smaller piece of code and the cost only appears months later when somebody asks a question the system can no longer answer.
- · 11 min read
Phasing Is the Architecture: Lay the Reliability Core at Phase One or Rebuild Four Times
A product that must grow from a seed either lays its reliability core at phase one, or rebuilds at every growth step and re-litigates the same reliability questions four times. The core is deliberately more than phase one needs and exactly what the phases after it require, because some properties can be added later at linear cost and some cannot be added later at all. This gives the filter for what belongs in the core, the mechanical test for whether a phase is additive, and what to do when a phase genuinely changes the core's contract.