Measured Behaviour
Published
Goodwill exists to pay repairs the warranty does not cover, on purpose. So the assertion anybody would write without reading the configuration - nothing was paid outside the term - is false on the correct run. The alarm is a dial, and every mark on the dial is a name.
A control whose correct operation is a deliberate breach
We built a queue of twenty-two customer assistance requests against a delegation ladder - 250 dollars for a service advisor, 1,200 for a service manager, 4,000 for a district manager, with a 600 dollar fallback for any role the ladder does not name - an annual envelope of 30,000, an eligibility window of 18 months or 20,000 miles past the term, and a loyalty weighting.
The correct run authorises 27,414.00 dollars and refuses 8,315.00. Five requests are refused as too far past the term, ten are trimmed to whatever the person raising them may authorise, and seventeen of the twenty-two authorisations are for vehicles outside their warranty. That last figure is not a defect. It is the programme working.
Which is what makes this area awkward to test. There is no assertion that needs no configuration to state: paid-outside-term reads seventeen when everything is right. The only reference marks are the ladder and the envelope, and both are options a rename can move.
Protection on its own moved nothing. All five profiles - the ES5 target, the modern target, both emit-gate configurations and the string-encoding profile - produced identical behaviour.
Losing the ladder fails closed; losing the ladder and its fallback fails open
Renaming the ladder alone drops every approver to the 600 dollar fallback. Authorised fell from 27,414.00 to 19,075.00 and refused rose from 8,315.00 to 16,275.00. Every ceiling on every line printed 600.00, including for district managers who may authorise 4,000. Customers were under-compensated by 8,339.00 dollars.
Renaming the fallback alone moves almost nothing: 27,414.00 to 27,819.00, and only for the one role the ladder does not name.
Renaming both is the arm that matters. With no ladder and no fallback there is no ceiling at all: every line printed a ceiling of Infinity, the trimmed-by-authority count went from ten to zero, and the run authorised 30,000.00 dollars - which is not the requested total but the annual envelope, because the envelope is the only thing left standing.
So the two halves point in opposite directions and the union is the giveaway. A member pattern narrow enough to catch only the ladder produces a stream of under-compensated customers, which somebody complains about. A pattern wide enough to catch both produces a service department that can authorise anything, which nobody complains about.
The check passed in all three, and its sentence was true
The programme's own rule is the one an aftersales organisation really writes: no authorisation may exceed the approver's authority. In the uncapped arm it passed, printing 22 request(s), 30000.00 authorised, every one inside a ceiling.
That sentence is true. When the ceiling is infinity, every amount is inside it. The rule is present, correctly implemented, invoked, and answering a question that has stopped meaning anything.
The counters behave the same way. Trimmed-by-authority is the number the engine computed using the ladder that went missing, so it reads zero in exactly the arm where nothing was limited. A counter defined over the control it monitors is not a second opinion, and this is the second area in this pass where that held exactly.
The one thing that did catch something cold is worth naming. Two requests carry a regional pre-approval that legitimately bypasses the ladder. Renaming the reference field that makes those legitimate caused the rule to reject the batch outright: two of twenty-two requests bypassed the ladder with no regional reference. A guard written over a fact from outside the configuration works; a guard written over the configuration does not.
Four names on the options object and four on the records, pairwise identical
This file gave the cleanest instance we have measured of a pattern that keeps appearing: for four separate controls, renaming the option and renaming the record field it reads produce byte-identical money.
The ladder and the approver role on the request: both 19,075.00. The month window and the months-past-term field: both 28,819.00. The mile window and the miles-past-term field: both 30,000.00. The loyalty table and the loyalty tier on the request: both 25,540.00.
The practical reading is that scoping a member pattern to spare the configuration object buys nothing if the record shapes are still in it. The failure is the same failure, reached from the other end, and it produces the same number to the cent.
The two mile and month windows also demonstrate why we had to fix our own fixture before measuring. In the first version every refused request breached both limits, so each limit masked the other and both arms measured inert. That is not evidence of safety - it is a fixture that cannot distinguish them.
What the envelope actually bought
The annual envelope is the only control in the file that limited the uncapped arm, and it is worth being precise about what it did. It capped the damage at 30,000.00 dollars. It did not report anything unusual: the run prints trimmed-by-budget as two, which on any other day means a busy quarter.
Renaming the envelope on its own is inert on the money, because it does not bind in the correct run. It changes one printed line from envelope=30000.00 to envelope=none and nothing else. That is the whole visible trace of removing the last backstop in the system.
So the envelope is an amplifier of silence as much as a control. It bounded the loss in the arm where every ceiling was gone, and in doing so it made that arm look like an ordinary year in which the budget ran a little tight.
The wider architectural point about ceilings that live in the same configuration as the thing they bound is set out in Zero Trust and Client-Side JavaScript.
What to do about it
None of this is an argument against protecting the code. The engine's default profiles moved nothing in this file. Every difference came from a member-renaming pattern reaching an options object or a request record, and that pattern is something you choose. The mechanics are in Protect Members.
Assert the ceiling that was applied, not the amount authorised. The correct run prints a ceiling on every line - 250.00, 1200.00, 600.00. A test that pins those fails on the ladder arm and on the uncapped arm, where they read Infinity. A test that pins the total passes on the uncapped arm until the envelope moves.
Check the authority ladder against a source outside the configuration that derives it - the delegation schedule the organisation actually signed - rather than against the engine's own report of what it permitted.
And keep a queue that exercises the limits. We ran the same twenty-two requests with every vehicle still in warranty and every amount small: nothing is trimmed, nothing is refused, and every arm in this article is inert. Whether an authority error is visible is a property of the queue, not of the code.
Frequently asked questions
Did obfuscation change what was authorised on its own?
No. On all five profiles we tried - the ES5 target, the modern target, both emit-gate configurations and the string-encoding profile - the protected bundle produced identical behaviour to the original. Every difference came from member renaming reaching an options object or a request record.
What did renaming the authority ladder do?
It dropped every approver to the 600 dollar fallback. Authorised fell from 27,414.00 to 19,075.00 and refused rose to 16,275.00, so customers were under-compensated by 8,339.00 dollars while district managers entitled to authorise 4,000 saw a ceiling of 600.
What did renaming the ladder and the fallback together do?
It removed every ceiling. Each line printed a ceiling of Infinity, the trimmed-by-authority count fell from ten to zero, and the run authorised 30,000.00 dollars - the annual envelope, which was the only limit still standing.
Did the authority check catch any of it?
Not the ceilings. It passed in every arm, printing that all twenty-two requests were inside a ceiling - which is true when the ceiling is infinity. It did catch a different loss cold: renaming the regional approval reference made it reject the batch, because that fact comes from outside the configuration.
Is renaming the request records safer than the settings object?
No. Four controls in this file produce byte-identical money either way: the ladder and the approver role both give 19,075.00, the month window and months-past-term both give 28,819.00, the mile window and miles-past-term both give 30,000.00, and the loyalty table and loyalty tier both give 25,540.00.
Why can we not just assert that nothing was paid outside the term?
Because that is false on the correct run. Seventeen of twenty-two authorisations are for vehicles outside their warranty, which is what a goodwill programme is for. The control permits a bounded breach, so the obvious assertion is not merely blind but wrong.
What should we pin in a test?
The ceiling applied to each request - 250.00, 1200.00 and 600.00 in the correct run - rather than the amount authorised, and the count of requests trimmed by authority. Both fail on the ladder arm and on the uncapped arm; the authorised total does not. Scoping the pattern away from the options object is covered in Protect Members.
Related reading