Use case CORE: Read first, judge second — why the order matters
An inherited codebase, a review report full of findings — and a team that spent more time refuting than fixing.
A team inherited the software of a departed service provider: grown over seven years, thinly documented, in production. Before their first own release they ran a review over it. What came back was a report nobody wanted to read — pages of findings, some real, and among them plenty of places where the reviewer simply did not know why the code does what it does. A deliberately open interface looks like a hole if you do not know the intent behind it. The team started refuting the report instead of improving the software.
The biggest obstacle they identified was not the number of findings but their burden of proof: a false finding costs more than the real one it hides. It occupies the same expert, it ends in a shrug, and it destroys trust in the list. After the third false finding nobody reads the fourth — and the fourth was the right one.
That is exactly why the order is fixed in Aigis. The innermost layer, CORE, first records what is there: intent, callers, inheritance, dependencies. It is expressly not allowed to judge — no finding, no verdict, no thumb. Only then do the layers for function and security look, and neither may report documented intent as an error. The open interface still appears in the report, but as what it is: a deliberate decision with a citation that someone can confirm or withdraw.
The list did not get shorter because findings had disappeared. It got shorter because the refuting fell away. What remained was work instead of litigation.
The situation described is composed, not that of a specific customer. The mechanism described is the one Aigis actually applies.