What a Score Can and Cannot Tell You
This chapter interprets iFixAi results in the situations where overclaiming is most tempting: case studies built from public reports, live-model runs that cannot replay byte for byte, and repositories whose documentation changes faster than every comment. The practical task is to separate a configuration finding from a production claim, use run metadata as traceability rather than proof of determinism, and protect the evidence that the audit creates.
A score is useful only when its boundary travels with it. The fixture, provider surface, judge path, release, and run conditions determine what the result describes. The repository's case studies are valuable precisely because their disclaimers show how much a responsible reader must keep separate.
Case studies are bounded reconstructions
The Instagram support scorecard is explicit that iFixAi did not test Meta's production system. It grades an illustrative reconstruction of the recovery-flow authorization described in public reporting. Its load-bearing claim is about the reported permission topology: an unverified requester was modeled as having account-changing tools without an ownership check. That is a configuration-level finding. It does not establish that iFixAi observed the shipped assistant, nor that the modeled defect caused or would have prevented the reported takeovers.
The Dragontail case study applies the same discipline to allegations about a delivery-dispatch permission topology. The scorecard states that the fixture was reconstructed from a legal complaint and was not derived from the product's source code. Its structural findings concern the topology as described; its judge-scored rows concern a stand-in model governed by that reconstructed topology. A missing live control plane limits what can be concluded. A selected-inspection aggregate is also not comparable with a full-suite grade merely because both are printed as percentages.
The AISI cyber-range reconstruction makes a different boundary visible. It separates a simulated environment, a stand-in model, and the configuration conditions described in a public incident. Some structural checks describe the reconstructed environment; other results describe how the reachable model responded to probes. The scorecard also reports that a platform classifier blocked one of the intended probes, so the absence of a result is part of the case's evidence boundary. The reconstruction can illustrate how iFixAi would expose certain governance weaknesses. It cannot stand in for a test of the original harness or implicated production configuration.
These examples are not independent validation of iFixAi's claims about the world. They are demonstrations of the reasoning the project wants readers to apply. Each asks the same questions: What was directly observed? What was reconstructed? Which actor or model produced the behavior? Which conditions were unavailable? What conclusion remains after those qualifications are restored?
That reading method changes how a scorecard should be used in a review meeting. Start with the inspection's subject, not the grade. If the result is B01, look at the role/tool topology and ask whether the tested permission cell belongs to the real deployment. If it is B08 or B12, inspect the prompts, the response path, and the judge conditions before treating the percentage as a stable property of the model. If it is an escalation finding, ask whether the fixture actually declared a channel and case convention that the agent could use. A low number may reveal a governance defect, a behavior defect, or an under-specified environment; the per-inspection evidence tells those apart.
The distinction between configuration and behavior is especially important in a reconstructed case.