What predictability pay actually costs you
Fair-workweek premiums come from events, not policies — which is why reconstructing them from snapshots fails. How an append-only ledger prices a change before you save it.
6 min read
Most managers meet predictability pay the same way: a payroll line item, months after the week it came from, with nobody able to say which change caused it.
This is a walk through the mechanics — how the premium arises, why it is so hard to reconstruct afterwards, and what it takes to know the number while you can still do something about it.
These ordinances differ by city and change over time. Everything here describes the general shape of the rules, not the current text of any specific one. Treat it as background, not legal advice, and confirm the details for your jurisdiction with your own counsel.
The premium is a consequence, not a policy
Fair-workweek laws generally share a structure. You post the schedule some number of days ahead — commonly fourteen. After that, changing a posted shift owes the affected worker a premium. The premium is usually one of:
- a flat amount per change,
- an hour of pay at the worker's rate, or
- a percentage of the hours removed, when a shift is cancelled outright.
The important part is the trigger. The premium does not come from a policy you set; it comes from an event — a specific posted shift changing at a specific moment. Which means the record you need is a record of events.
Why reconstruction fails
The obvious implementation is to snapshot the schedule when it is published, snapshot it again at period end, and diff the two. It is also wrong, in a way that is easy to miss and expensive to discover.
Consider a shift that is moved on Tuesday and moved back on Thursday. The end-of-period diff shows no change at all. The worker was still told twice, and the premium was still owed twice.
Now consider a week that gets re-published. If your record of what is owed is derived from the current state, re-publishing rewrites it. The liability silently drops to whatever the latest snapshot implies.
Both failures share a cause: the current state does not contain the history.
Append-only, or it did not happen
The fix is unglamorous. Record an event the moment a posted shift changes, and never mutate it.
In Sofia, that record is written in the same atomic batch as the change itself. If the write fails, the change fails. If the change lands, the premium is recorded. There is no window in which one exists without the other, and no code path that edits an event after the fact — the only operation is append.
That gives you three properties that matter when someone asks:
- Re-publishing cannot erase liability. The events are already written.
- A move-and-move-back shows as two events, because it was two events.
- The total is auditable, because it is a sum of individual records, each naming a shift, a time, and a reason.
Knowing before you save, not after
Once the events are the source of truth, a second thing becomes possible: you can price a change before it happens.
Editing a posted shift can tell you what the edit would owe, while you still have the option not to make it. Publishing a week can total what the week's changes have accrued, before you commit to it. The number stops being a post-hoc discovery and becomes an input to the decision.
That is the actual argument for doing this properly. Not compliance theatre — just knowing the price of a change at the moment you are deciding whether to make it.
What tends to get missed
Two details cause more trouble than their size suggests.
Drafts are not posted shifts. A shift a worker has never seen owes nothing. If additions accrue at draft-creation rather than at publish, you book phantom premiums for shifts that were created and deleted without anyone being told — and because the ledger is append-only, those phantoms are permanent. Additions should accrue against what is actually being posted.
A voluntary swap is not a manager change. When a worker offers their shift and a teammate picks it up, the hand-off is consensual. Treating that as a reassignment charges a premium nobody owes. The carve-out needs guarding, though: if a stale offer can linger after a shift changes hands, a manager reassignment can be dressed up as a swap and skip the premium. Only the current holder should be able to offer a shift.
The uncomfortable part
Done properly, this makes your liability visible. Some of what surfaces will be changes you were already making and had never priced.
That is the point. A number you cannot see is not a number you are managing — and it does not stop existing because nobody wrote it down.
Related features
Get a store number, or let us show you around.
$200 a store. The line is boarding. Or open a workspace and run the roster today.