Measured Behaviour
Published
A superseded part number is not a broken value. It is a real part - orderable today, correctly priced, physically fitting, sitting on the shelf - that was withdrawn for a reason nothing about the number tells you. That is what makes a supersession chain the hardest kind of table to check.
Every wrong answer here is a real part
We built a catalogue with five supersessions, two of them running two hops: a lower control arm superseded because it cracked in service, whose replacement was superseded again for the wrong bushing durometer; a chain tensioner with the same shape; and a trailer harness with one hop. Sixteen counter and workshop orders, six of which request a number that is one or two hops from current, plus two counter requests for restricted parts.
The correct run walks every requested number to the end of its chain, issues 79 units worth 7,488.20 dollars, refuses the two restricted parts over the counter, and reports zero superseded numbers issued. The programme's own rule - no superseded number is installed and no restricted part is issued - passes.
Protection on its own changed none of it. All five profiles - the ES5 target, the modern target, both emit-gate configurations and the string-encoding profile - produced identical behaviour.
The thing that makes this area different from an ordinary lookup is what a wrong answer looks like. A missing price is a zero and somebody notices. A superseded part number is a part that fits, works, and was withdrawn for a safety reason. A technician holding one has no way to tell, and neither does a range check.
The cracked original went back on the car
Renaming the supersession table leaves the requested number as the current number, because with no chain every number is its own successor.
Measured: six units of the withdrawn control arm, two of its superseded replacement, three of the withdrawn tensioner, one of its replacement and five of the old harness were issued. The orders that should have been filled with the current parts were filled with the parts those current parts exist to replace.
The parts value went from 7,488.20 to 7,335.00. A difference of 153.20 dollars across eighteen orders - about two per cent - because superseded parts and their replacements are priced similarly, which is the whole reason a stock valuation cannot see this.
And the run reported SUPERSEDED-ISSUED=0 with the programme's rule passing and printing 18 order(s), none superseded, none restricted. That sentence is true as far as the software can tell: the table that would say those numbers are superseded is the table that went missing. The guard and the thing it guards were lost in one edit.
The prediction failed, and the failure is the finding
We expected the narrower loss to be the quieter one. The chain is walked to its end only because a flag says to; lose that flag and the catalogue returns the first replacement, which in a two-hop chain is itself superseded. Our prediction was that this would be silent, because the run would still report that a supersession had been applied.
It was not silent. It was the loudest arm in the file. The strict control - a superseded number may not be installed - refused outright: superseded-part(refused to issue LCA-11B for PO-33400). Nothing shipped at all.
The reason is the part worth carrying. That control asks the chain table whether the number about to be issued has a successor. When the flag is lost the table is still there, so the control still works and fires immediately. When the table is lost the control is still running and has nothing left to find.
So the severity did not track how much was renamed. Losing one flag stopped the parts counter within a minute. Losing the whole table shipped withdrawn safety parts silently for as long as anybody cared to run it.
The strict control was contributing nothing to remove
We ran the same table loss with the strict control switched off as well. The output is identical to the table loss alone - same 79 units, same 7,335.00, same superseded-issued count of zero, same passing rule.
That is the signature this series has recorded repeatedly: when a guard is defined over the same data as the thing it guards, removing the guard changes nothing, because the guard had already stopped working. If switching a control off makes no difference to the output, the control was not protecting anything in that arm.
The restricted-parts list behaves the same way and is worth stating separately, because a restraint module is not a warranty question. Renaming that list sold both restricted parts over the counter: units issued went from 79 to 81, parts value from 7,488.20 to 8,984.70, and the refusal counter from two to zero.
The counter reporting restricted parts issued still read zero, because it asks the list that went missing, and the programme's rule still passed printing none restricted. A counter defined over the control it monitors is not a second opinion.
Values fail loudly, meanings fail quietly
The contrast held here as it has in every area we have measured. Renaming the quantity on an order refuses before issuing anything. Renaming the counter-sale flag makes both restricted parts count as issued and the rule rejects the batch outright.
Renaming the price table is the interesting middle case: the same 79 correct units are issued, with the parts value reading 0.00 and sixteen orders reported unpriced. Loud on the invoice, and the parts on the vehicles are all correct.
Renaming the requested-part field collapses every order to one undefined number - 81 units of nothing, valued at zero, with the programme's rule still passing. Visibly broken, which is the good case.
The pattern across all of them: lose a number and the system stops. Lose what a number means - which of several real parts is the current one - and the system carries on and ships.
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 a catalogue object, and that pattern is something you choose. The mechanics of scoping it are in Protect Members.
Assert which part was issued, not what it cost. The correct run prints its issued-parts breakdown by number. Pinning that breakdown fails on every arm above; pinning the parts value fails on the price arm and misses the supersession arm almost entirely, because the difference is 153.20 dollars.
Teams shipping catalogue logic compiled from another language will find the surrounding considerations in Protecting Compiled-to-JavaScript Output.
Make an unresolvable supersession an error rather than a pass-through. A catalogue that cannot find a number should refuse to issue it, not hand back the number it was given. The pass-through is what turns a lookup miss into a withdrawn part on a customer's vehicle.
And check the guard independently of the data. A rule that reads the same table it is protecting will report success in exactly the arm where the table is gone. Reconcile the numbers issued against a current-parts list from somewhere the renaming cannot reach.
Frequently asked questions
Did obfuscation issue the wrong parts 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 a catalogue configuration object.
What actually shipped when the supersession table was renamed?
Six units of a control arm withdrawn because it cracked in service, two of its superseded replacement, three of a withdrawn chain tensioner, one of its replacement and five of an old trailer harness. All of them are real, orderable, correctly priced parts.
Why did the parts value barely move?
Because a superseded part and its replacement are priced similarly. The total went from 7,488.20 to 7,335.00 - about two per cent across eighteen orders - which is why a stock valuation or an invoice reconciliation cannot see this class of failure at all.
Did the check that refuses superseded parts fire?
Not in the arm that mattered. It passed, printing 18 orders, none superseded, none restricted. It asks the supersession table whether a number has a successor, and that table was the thing that went missing, so it had nothing left to find.
Was the narrower rename safer?
No, and we predicted the opposite. Renaming only the walk-to-end flag was the loudest arm in the file: the strict control refused immediately and nothing shipped. Renaming the whole table was silent. Severity did not track how much was renamed.
What happened to the restricted parts?
Renaming the restricted list sold a restraint module and a high-voltage contactor over the counter. Units issued went from 79 to 81 and parts value from 7,488.20 to 8,984.70, while the counter reporting restricted parts issued still read zero because it asks the same list.
What should we pin in a test?
The issued-parts breakdown by part number, and the count of orders refused for each distinct reason. Both fail on every arm here. Pinning the parts value or the unit count misses the supersession arm, which is the one that puts a withdrawn safety part on a vehicle. Scoping the pattern away from the catalogue is covered in Protect Members.
Related reading