Forensic audit of a scoring engine (cyber-resilience)
Context
Ascend Partners engagement: at a client engaged in an investment arbitrage over several infrastructure assets, the cyber-resilience scores of those assets had dropped with no explanation.
The tool behind these scores was a legacy scoring engine, written in VBA, with three successive versions.
Before the drop could be explained, it first had to be reproduced: the method constraint was to rebuild these engines until the scores matched to the hundredth, and only then look for the cause.
The stakes went beyond a technical diagnosis: the scoring method itself was contested internally, and the conclusion had to be presented to the client's executive committee for an investment decision.
The system
I rebuilt the three successive scoring engines in Python from the code and the real data, until the scores matched to the hundredth.
The rebuild was validated by 304 tests, then turned into visuals for the board.
A governance note accompanied the delivery, to align teams on a scoring method contested internally.
Decisions & trade-offs
Rebuild the three scoring engines in Python from the code and the real data, until the scores match to the hundredth.
Reproduce first, conclude second. Cause found: response requalification by coefficient plus a switch to a geometric mean at the pillar level.
Eight pillars with fixed weights: that is the level at which the geometric mean applies, on responses already requalified by coefficient.
Result
304 tests, score reproduced to the hundredth. Presented to the client's executive committee for an investment decision.
What it shows
Reverse-engineering legacy code, a root-cause method, and settling a methodological disagreement with proof.