Measured, not asserted
Published
A tenant's pro-rata share is a ratio, and its two halves come from different places. The numerator is the suite's rentable area, which is on the rent roll. The denominator is the building's rentable area, which is in the lease and does not change when a suite goes dark. Lose the denominator and there is exactly one number left to divide by: the sum of the suites the engine can see. That is the fallback of every allocation routine ever written, and it is correct whenever the building is fully leased. This test renamed it against a real obfuscation engine. Every share stayed between zero and one, every suite was allocated exactly once, the run footed, and the shares now summed to exactly 100.0000% -- which reads better than the truth.
A denominator that is a constant, and a fallback that is a sum
The fixture is a 250,000 square foot building with seven suites totalling 205,500 square feet. The centre is 82.2% leased. The recoverable pool for the year is 1,594,128.78, taken straight from the reconciliation in the companion fixture.
Correct: denominator=250000SF via building(the rentable area stated in the lease), SHARES-SUM=82.2000%, TENANTS-BILLED=1310373.86, OWNER-CARRIES=283754.92. The owner absorbs the vacancy, which is what a share against the building means and what the lease bought.
Rename the option carrying the building area and the engine falls to the only denominator it has left: denominator=205500SF via occupied(the sum of the premises on the rent roll). SHARES-SUM=100.0000%. TENANTS-BILLED=1594128.78. OWNER-CARRIES=0.00. Every dollar of vacancy cost has moved onto the tenants who are still paying, and one 16,050 square foot suite went from 102,343.07 to 124,504.95.
Nothing about that looks like a failure. It is not a missing value, not a NaN, not a fallback to zero and not a refusal. It is a complete, well-formed, fully footed allocation using the standard normalisation.
The failing arm reads BETTER than the correct one
The owner's own allocation rule in the fixture checks the two things anybody would check: every suite must be allocated, and the shares must not sum to more than the whole. It prints share-check(7 of 7 suite(s) allocated, shares within the whole) in both runs, word for word, and foots=true in both.
It could not have caught this. Seven of seven suites are allocated in both. The shares are within the whole in both. And the number a person would actually glance at -- the sum of the shares -- is improved by the failure. 82.2000% looks like something is missing. 100.0000% looks like a clean, complete, fully reconciled allocation.
This series has repeatedly found reconciliations that close by construction, and reconciliations that read better in the failing arm than in the correct one. This is the crispest instance: the metric that would tell you the allocation is wrong is the metric that improves when it goes wrong.
Three names and two guards, all reaching the same answer
The same result arrives from more than one direction and it is worth knowing which. Renaming the building area produced it. Renaming the basis option that selects between building and occupied produced the identical output. Renaming both together produced the identical output again.
So did switching the guard off. ^(requireShareCheck|buildingRentableArea)$ and ^(shareRule|buildingRentableArea)$ were both byte-identical to renaming the denominator alone. The rule was contributing nothing to remove, because it is defined over count and bound, and the normalisation disturbs neither.
Renaming the numeric rentableArea on each suite is the loud direction: the run was refused with share-check(7 suite(s) had no readable area) and nothing was billed. Renaming the identifying suiteId and tenant fields moved only the printed rent roll and left the money correct to the cent. The three pinned control options -- the default share, the minimum share and the area label, all set equal to the library's own defaults -- were inert on both presets, which is the prediction holding rather than a blind arm.
Why nobody catches this one
The party harmed by an over-normalised allocation is the tenant, and the tenant's route to noticing it runs through the landlord's own rent roll. To find it you have to know the building's rentable area independently, compare it against the denominator actually used, and be willing to argue about a figure that is in a lease nobody has opened in three years.
The party who benefits is the landlord, whose statements now foot perfectly and whose recovery ratio has improved. Nothing on their side reads as anomalous, because nothing on their side is anomalous -- the arithmetic is impeccable.
That asymmetry is the general lesson. When a defect improves the numbers on the side that produces the report, the report is not the place it will be found. Reconcile against something written by somebody else: the measurement certificate, the rent roll as filed, the lease exhibit. If you are thinking about where those obligations bite for a data-handling platform, our data residency notes cover the adjacent ground.
What to change, whether or not you obfuscate
Require the denominator explicitly and refuse without it. An allocation library that normalises across the population when it cannot read the building area is doing the only sensible thing available to it; the fix is that it should never be in that position. Make the building's rentable area a required, validated input and make its absence an error.
Assert the operation, not the population. The check that would have caught this is one line: the sum of the shares must equal the leased fraction of the building, and the owner's carried amount must be greater than zero whenever the building is not full. Both are facts about the building, and neither is derivable from the allocation itself.
Put a vacancy in the fixture. If the test building is 100% leased, the share and the normalisation are the same number and this entire class is invisible to the suite by construction -- the same trap as testing a capped pipeline in an uncapped year.
And keep member-renaming patterns narrow and explicit, excluding any options object that carries a denominator, a basis or a threshold. Renaming identifiers and control flow is unaffected by all of this.
How this was measured
Five commercial-real-estate areas were driven through the real obfuscation engine on five presets -- the ES5 default, the modern target, the emit gate's option set on both targets, and the string transforms. All five produced output byte-identical to the unprotected run on all five presets, twenty-five for twenty-five.
The member-renaming column is sixty-nine patterns on two presets, one hundred and thirty-eight verdicts: one hundred and twenty-eight moved the output, ten did not, and all ten are the pinned control arms. Nothing threw, nothing was vacuous, ES5 and modern agreed on every arm.
Before any of that, every option key and every record field was deleted in the unprotected world to confirm it changes the answer at all -- ninety arms plus a union arm, zero structurally blind on the first run.
Every figure quoted above came from executing the protected artifact and reading the fields that decide the outcome, not from a diff summary.
Frequently asked questions
Did obfuscation on its own break pro-rata allocation?
No. All five presets produced output byte-identical to the unprotected run across all five areas measured this pass.
What actually broke it?
Member renaming reaching the option that carries the building's rentable area, or the basis option that selects between a building denominator and an occupied one. Both produced the identical result.
Why is normalising across the occupied premises wrong?
Because a pro-rata share against the building leaves the owner carrying the vacancy, which is what the lease bought. Normalising across the suites that remain hands the vacancy to whoever is still paying.
Why did the allocation check not catch it?
It checks that every suite is allocated and that the shares do not exceed the whole. Both are true in both runs. The shares summing to exactly 100% instead of 82.2% reads as an improvement, not an anomaly.
Which arm failed loudly?
Renaming the numeric rentable area on each suite. The areas became unreadable, the run was refused, and nothing was billed. Losing a value fails closed; losing a denominator fails open.
Would a full building have shown this?
No. In a 100% leased building the share and the normalisation are the same number, so a fixture without vacancy is blind to this class by construction.
What is the safest way to use member renaming here?
Keep the pattern narrow and explicit and exclude any options object carrying a denominator, a basis or a threshold. Renaming identifiers and control flow is unaffected.
Related reading