Measured, not asserted
Published
A divided account is always divided in full. Whatever basis is used, the shares plus what the participant keeps equal the balance, because a division that does not add up is a defect nobody tolerates. That makes the reconciliation an invariant of the code rather than evidence about the result -- and this test found the sharpest possible demonstration: an alternate payee awarded $501,552.00 out of a $486,000.00 account, a participant left with negative $15,552.00, and reconciles=true printed on the same line.
A division that cannot fail to balance
An account divided under a domestic relations order is split on a basis the order specifies. The fixture uses the coverture fraction: the share of the participant's plan service that was marital, multiplied by the percentage the order awards. Plan service runs 5,840 days, the marriage covered 2,920 of them, and the order awards the alternate payee 50% of the marital portion -- 25% of a $486,000.00 account, which is $121,500.00, or $125,388.00 after the 3.2% earnings adjustment between valuation and segregation.
The participant keeps the remainder. That is the ordinary and correct way to write this: the last party absorbs whatever is left, so the allocation always closes. It also means the reconciliation is true by construction on every basis, including bases nobody ordered.
The division engine is copied in unprotected. Its own default basis is an equal share of the whole account, which is the only thing a library can do when it has not been told what the order says.
Protection on its own moved nothing
Twenty-five comparisons across five areas and five presets, all byte-identical to the unprotected run.
More than the account holds, and the check says it balances
Renaming the division basis on its own does nothing to the money. The order's own weighting rule is still being used, so the shares are correct and only the displayed basis changes -- a cosmetic arm a reviewer would close.
Rename it together with the flag in front of that rule, and the library computes the weights itself. With one alternate payee, an equal share of the whole account is the whole account: basis=equal-share shares=[AP-1=$501552.00] participant-keeps=$-15552.00 allocated-total=$486000.00 reconciles=true.
The alternate payee is awarded 103% of the account. The participant's balance is negative. And the reconciliation reports true, because the allocated total and the balance still agree to the cent -- they cannot do otherwise, since the participant's share is defined as whatever is left.
The configuration screen is worse than useless here. It reads basis-rule=caller-supplied(weights each party by the order's coverture fraction), and that is accurate: the order's rule is present, installed, and correct. It is simply never called. Asking "is the order's weighting rule configured?" returns a true answer to the wrong question.
Where the reconciliation does fire, and why that is the wrong half
The reconciliation is not useless in every arm. Renaming the enabling flag together with a coverture field -- the marital end date, or the awarded percentage -- produces shares=[AP-1=$NaN] participant-keeps=$NaN allocated-total=$NaN reconciles=false.
So the check catches the case where the arithmetic is unreadable, and misses the case where the arithmetic is perfect and the basis is wrong. That is the general shape of a reconciliation defined over the code's own outputs: it can only see failures that break its own invariant, and the invariant is the thing the code guarantees rather than the thing the order requires.
Renaming the account balance is the loud, safe direction: non-finite-balance(refused before the division). Losing the number the split is taken FROM refuses; losing the RULE the split is taken BY proceeds.
The prediction that failed, and what it was right about
This area was set up to re-test a specific prediction from an earlier pass: that renaming the coverture fields alone would change nothing, because the order's own rule reads them off records the same bundle owns, so both the write and the read move together and nothing crosses the boundary.
The prediction was right about the money and wrong about the arm. Renaming the marital start date, the marital end date or the awarded percentage left the division exactly correct -- $125,388.00 to the payee, $360,612.00 to the participant -- and changed the engine's own display of the weights to weights=AP-1#NaN, because the unprotected library prints those weights from the same fields.
That is worth recording precisely, because it is a rule about measurement rather than about money. A name your own code owns on both sides is safe inside the process, and stops being safe the moment anything outside the process reads it -- including a diagnostic line. An arm that reports a difference is not necessarily an arm that changes an outcome, and here three of them changed nothing but a debug display.
Renaming the earnings adjustment is the counter-example: it is quiet, it moves money, and it reconciles. The payee receives $121,500.00 instead of $125,388.00. That is $3,888.00 that belongs to the alternate payee under the order, on a line where every figure is a plausible currency amount and the total is exactly right.
What this means if you protect an account administration front end
Keep member renaming off the boundary: a MemberRegexp scoped to your internal names, excluding every option key and record field an installed library reads.
Then stop treating the reconciliation as evidence. It is an invariant of the allocation code, not a statement about whether the allocation is the one the order directs. Check the SPLIT per party against something outside the billing code -- the order itself, the account's own history -- and make an unreadable basis an error rather than a fallback to the division that always works.
And be careful with the phrase "the rule is configured". In the worst arm here the rule was configured, present and correct, and the library never called it. A control's telemetry has to report that it RAN, not that it EXISTS. The same distinction runs through CCPA and CPRA obligations for JavaScript, where an accurate statement about configuration is routinely mistaken for evidence of behaviour. The protected build divided the account correctly on all five presets.
Frequently asked questions
Did obfuscation change any account division on its own?
No. Five areas across five presets, every protected output byte-identical to the unprotected run. Every failure here required member renaming reaching a name the installed division engine also reads.
What was the worst result?
Renaming the division basis together with the flag in front of the order's own weighting rule. The library fell back to an equal share of the whole account, which with one alternate payee is the whole account: $501,552.00 awarded out of a $486,000.00 balance, and the participant left with negative $15,552.00.
How did the reconciliation not catch that?
Because it cannot. The participant keeps whatever is left, so the shares plus the remainder always equal the balance -- on every basis, including one that hands out more than the account holds. The reconciliation is an invariant of the code, not evidence about the result.
Did anything on the configuration screen look wrong?
No, and this is the part worth remembering. It reported the order's coverture rule as caller-supplied and installed, which was accurate. The rule was present and correct and was never called. Asking whether a control is configured is not the same as asking whether it ran.
When did the reconciliation actually fire?
Only when the arithmetic became unreadable. Renaming the enabling flag together with a coverture field produced NaN shares and reconciles=false. It catches the loud case and misses the quiet one.
Was there a quiet arm that moved real money?
Yes. Renaming the earnings adjustment left the payee with $121,500.00 instead of $125,388.00 -- $3,888.00 they are owed under the order -- with every figure plausible and the total exactly right.
What is the cheapest test that would have caught this?
Divide one known account and assert each party's share to the cent against the order, not against the balance. Asserting that the shares add up to the balance passes in every dangerous arm in this article.
Related reading