Balances as of any date

Two screens show two balances for the same worker, and both are recomputations: same events, different rule contexts. Ask what the balance was last March and there is nothing stored to answer from. This is the as-of problem again, in hours.

RuleStore the balance daily, per worker, per plan. A stored number ends the argument a recomputed one starts.

Neverbackfill balance history by rerunning today’s rules over old events. Plan rules changed; yesterday’s balance under today’s rules is fiction.

◆ Why screens disagreerecomputation with different inputs.

A delivered balance is a calculation: events to date, run through plan rules, at request time. Different screens ask with different as-of assumptions, in-flight requests count on one and not another, and imported opening balances from a prior system practitioners report never quite reconciling. Two answers, both derived, neither stored.

History is worse: plan rules change, and recomputing last year under this year’s rules produces a number that never existed. The tenant cannot answer what the balance was; it can only answer what it would compute today for then.

◆ The snapshot answerone row per worker, plan, and day, forever.

The pipeline asks the tenant once a day and stores every answer in the balance fact. From then on the balance for any date is a read, the trend is a filter, and a disagreement between screens is a diff between stored days with the events between them listed. Plan-rule changes stop rewriting the past because the past is no longer derived.

-- one worker's balance history, any range, one read
SELECT snapshot_date, plan_name, balance_hours
FROM fct_balance_day b
JOIN dim_absence_plan p ON b.plan_key = p.plan_key
WHERE b.worker_key = 4117
  AND snapshot_date BETWEEN DATE '2026-01-01' AND DATE '2026-05-31'
ORDER BY 1, 2

◆ The family this belongs tothe same absence, everywhere.

This is the catalog’s recurring finding wearing an absence costume: headcount, receivables, stock, and now hours, all overwritten in place, all answerable only by a snapshot you own. The pattern has its own page, the system only knows now, and this module is its newest exhibit.

Use case

Problem

Balance screens disagree, history is unanswerable, and every dispute is refereed by recomputation.

What we build

A daily balance snapshot per worker and plan, stored by the pipeline, immune to later rule changes.

What you get

Any balance, any date, one read, with the events between any two days as the explanation.

What was the balance last March? Exactly.

We ship the snapshot that makes that a query, not a debate.

Talk to us

Terms on this page

recomputation: Deriving the balance again on request. What every delivered screen does.
in-flight request: Time off requested but not yet approved. Counted differently by different screens.
opening balance: The imported starting value from a prior system.
plan rules: Accrual rates, caps, carryover. They change, and recomputed history changes with them.
snapshot: A dated copy of a state, kept so the past stays queryable.
diff: The comparison between two stored days that replaces the argument.
as-of date: The past date a question is asked about, as the data stood then.