Measured Behaviour
Published
A vehicle warranty is two ceilings and a lookup. The ceilings - months in service and miles on the odometer - are the part everybody tests. The lookup, which decides whether a repair falls under the three-year term or the five-year one, is the part that decides the money, and we measured what happens when a rename reaches it.
Two ceilings and a lookup
We built a claim batch the way a real one arrives: eighteen repair orders against a programme with a basic term of 36 months or 36,000 miles, a powertrain term of 60 months or 60,000 miles, a table mapping each labour operation code to one of those two terms, an exclusion list for wear items, and coverage that is original-owner-only so it does not follow the vehicle on sale.
The correct run pays 13,047.00 dollars of manufacturer warranty and bills the customer 7,920.00. Three repairs are declined as beyond every term, two are declined as wear items, and three are declined because the vehicle has been sold on. Four expensive repairs between three and five years old - a transmission valve body, a head gasket, a timing chain and a final drive - are paid, and they are paid for exactly one reason: the group table says they are powertrain.
We then protected the file with default settings on five profiles: the ES5 target, the modern target, both emit-gate configurations and the string-encoding profile. All five produced identical behaviour. That is the first result and it is worth stating plainly - protection on its own did not change a single coverage decision.
The failures start when member renaming is pointed at the names on the programme object, which is what a regexp like ^(componentGroups)$ or a broad RenameMembers pattern over a configuration literal actually does. If you have not yet decided how far your member pattern reaches, the mechanics are in Protect Members.
Losing the group table declines the repairs that are covered
The group table is a lookup, and a repair the lookup cannot name is not an error. It falls to the basic term, because that is the only term a library that knows nothing about your programme can offer.
Measured: manufacturer-paid warranty fell from 13,047.00 to 6,152.00 and the customer's share rose from 7,920.00 to 14,815.00. Claims declined as out of term went from three to eight. Every powertrain repair between 36 and 60 months - the transmission, the head gasket, the timing chain, the final drive - was declined to a customer holding a five-year powertrain warranty. The powertrain column of the payment breakdown reads 0.00.
This arm is loud, and it is loud in the only way that reliably gets attention: a customer with a written warranty is standing at a service desk being handed a bill. It will be found. That is not a compliment to the failure mode; it is the reason the next two arms matter more.
Note also what the run still prints. The configuration line still reads powertrain 60.00mo/60000.00mi, correctly, because the term itself is intact. It is the mapping from repair to term that is gone, and nothing on the screen says so.
Three different names produce the same headline number
We renamed the two halves of the powertrain term independently. Renaming the month limit reverts it to the library's 36 and manufacturer-paid falls to 6,152.00. Renaming the mile limit reverts it to 36,000 and manufacturer-paid falls to 6,152.00. Renaming the group table, as above, gives 6,152.00.
Three unrelated names, three unrelated mechanisms, one identical headline figure. The breakdown underneath does differ - the group table sends the whole 6,152.00 to the basic column, while the term arms split it 3,462.00 basic and 2,690.00 powertrain - but nobody reconciles a payment breakdown by column.
The practical consequence is about diagnosis rather than detection. When somebody does notice that warranty spend has halved, the total tells them nothing about which of three names moved, and two of the three leave the printed term looking perfectly correct.
For teams shipping software into vehicles, the surrounding control expectations are set out in ISO 21434, Type Approval and Your Vehicle Interface JavaScript.
The quiet arm pays claims that should have been declined
Coverage on this programme does not transfer to a second owner. Renaming the transfer flag reverts it to the library's permissive default, and coverage follows the vehicle.
Measured: manufacturer-paid warranty went from 13,047.00 to 16,809.00 - 3,762.00 dollars paid on three repairs to vehicles that had been sold on. The not-transferred counter went from three to zero. The out-of-term count did not move. Nobody complained, because in this arm every customer got more than they were entitled to.
Renaming the exclusion list does the same thing on a smaller scale: manufacturer-paid went to 13,630.00 and two sets of brake pads were paid as warranty repairs.
Both of these are silent by construction. A warranty programme has a queue for customers who were charged and should not have been. It has no queue at all for customers who were paid and should not have been.
The record field and the option are the same failure
The exclusion list matches the component name written on the claim. Two different names can break that match: the option carrying the list, and the field on the claim carrying the name.
We measured both. Renaming the option gives manufacturer-paid 13,630.00. Renaming the claim field gives manufacturer-paid 13,630.00. Byte-identical outcomes from two names on opposite sides of the boundary. The same held for the transfer rule: the option and the second-owner field on the claim both produce 16,809.00 exactly.
This matters for how you scope a member pattern. A team that carefully excludes its configuration object from renaming, and leaves its data records in, has not avoided the failure - it has reached it by the other route. Both halves have to be out.
The values behave differently from the meanings, as they have in every measurement in this series. Renaming the odometer field or the in-service field produces no readable age on any claim, and the programme's own rule refuses the whole batch: eighteen of eighteen claims have no readable age or odometer. Renaming the claim amount refuses before adjudicating anything. Lose a number and the system stops; lose what a number means and it carries on.
What to do about it
None of this is an argument against protecting the code. The engine's default profiles moved nothing at all in this file - the damage came entirely from a member-renaming pattern reaching a configuration object or a claim record, and that pattern is something you choose.
Keep both the programme literal and the claim record out of the member pattern. A warranty term object is not where obfuscation earns anything: an attacker who reads your powertrain term has learned a number printed in the owner's manual. Point the pattern at the logic and exclude the settings and the record shapes by name.
Assert the split, not the total. The correct run prints manufacturer-paid broken into 3,462.00 basic and 9,585.00 powertrain. A test pinning those two figures fails on every arm above. A test pinning only the total fails on the loud ones and misses both quiet ones.
And put a second owner and an excluded wear item in the fixture. A claim batch where every vehicle is nearly new and every repair is covered has nothing for a term, a group table or a transfer rule to decide - we ran exactly that batch as a control and every arm above is invisible in it.
Frequently asked questions
Did obfuscation change any coverage decision 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 in this article came from member renaming reaching the names on a configuration object or a claim record, which is a pattern you choose rather than a default.
Which rename cost the manufacturer money?
Renaming the transfer rule, which paid 3,762.00 dollars on three repairs to vehicles that had been sold on, and renaming the exclusion list, which paid two sets of brake pads. Manufacturer-paid warranty went from 13,047.00 to 16,809.00 and 13,630.00 respectively.
Which rename cost the customer money?
Renaming the component group table. Manufacturer-paid warranty fell from 13,047.00 to 6,152.00 and the customer's share rose from 7,920.00 to 14,815.00, because every powertrain repair between three and five years old fell back to the three-year basic term and was declined.
Does the printed warranty term ever look wrong?
Only in the two arms where a term limit is itself the name renamed. In the group-table arm the configuration still prints the correct 60 months and 60,000 miles, because the term is intact and it is the mapping from repair to term that is gone.
Would our own coverage check have caught it?
It caught the value failures and none of the meaning failures. Renaming the odometer or the in-service field made it refuse the whole batch, reporting eighteen of eighteen claims with no readable age. Renaming the transfer rule left it passing and reporting three of eighteen declined out of term, which was true.
Is renaming the claim record safer than renaming the settings?
No. We measured both and they are byte-identical on the money. The exclusion list and the component name field both produce 13,630.00; the transfer flag and the second-owner field both produce 16,809.00. Excluding one and not the other reaches the same failure by the other route.
What should we pin in a test?
The payment split by term - 3,462.00 basic and 9,585.00 powertrain in the correct run - rather than the total alone, and the counts of claims declined for each distinct reason. Include a second owner and an excluded wear item in the fixture, or the whole class is invisible. The scoping mechanics are in Protect Members.
Related reading