Wages That Survive a Retry
Why a failed wage attempt must preserve the original pay period instead of quietly becoming a new one.
Recurring wages look simple until a payment does not settle on time.
An employee has an agreement. A pay period becomes due. The employer cannot fund it, the evidence is incomplete, or the settlement needs to be reconsidered. The system must remember what was owed while still allowing a later retry. If the retry is treated as a brand-new period, the simulation can drift: the same work may receive two entitlements, the next pay date may move, or a save and reload may produce a different history from the one the player saw before.
For Statecraft, the durable rule is that contractual period identity and retry execution are separate things.
The identity of the period
For an agreement A and a contractual period P1, the entitlement is W(A, P1) at the original contractual boundary T1. That identity is not redefined by the moment at which the system retries the work.
The retry is a distinct execution item. It can have its own execution history and its own later timestamp, but it retains the original agreement, pay period, entitlement, liability, and transfer identity. When the retry settles, the next contractual period is scheduled from the agreement's cadence—not from the retry's wall-clock moment.
This sounds like a naming rule. It is actually an economic invariant. The player should be able to inspect a wage residue and know which period it belongs to, why it is still outstanding, and whether the later transfer is the one legitimate settlement for that period.
Persistence is part of the economy
The difficult case is not the first payment. It is the boundary after the first payment, after the retry, and before the next period.
The F11 regression surface now covers scheduled periods P1 through P4, save and restore after settlement, an outstanding P1 save, employer funding, exactly-once retry settlement, and a second save and restore before P2. The restore path rejects forged wage WorkId, DueAt, pay-period, retry, liability, transfer, and transition provenance rather than accepting a plausible-looking payload.
The same discipline applies when the employer remains insolvent across multiple contractual boundaries. P1, P2, and P3 obligations remain distinct, and recovery does not create duplicate entitlements, liabilities, or transfers. A missing attendance record can lead to typed reconsideration without inventing a false entitlement, while a later legitimate resolution still leaves P2 on the original cadence.
That is the difference between a retry and a rewrite of history.
Why the player should care
Players do not need to know the internal names of the records. They do need the world to behave consistently.
If a wage retry quietly changes the pay period, Finance can show a balance that cannot be explained. Employment history can appear to skip or repeat a month. A save made before the retry can load into a different obligation. A later job change can inherit a liability that belongs to an earlier agreement.
Preserving period identity keeps those consequences connected. The player can see a late payment as a late payment, not as a mysterious new income event. The ledger remains causal, and the next period remains predictable even when the current one needs recovery.
The current evidence is bounded to the F11 foundation surface, not a claim that every future economic system is complete. But the rule gives later systems a stable contract to build on: retries may change execution, never the identity of the obligation they are retrying.