A founder saying so, a setting in a configuration file, a check found in the source, and a request the running system refused are four different claims. Two products can both pass a control with very different amounts behind them, and a trust product that hides that difference is withholding the only thing that made the result worth having.
E0Nothing was established. The control is in scope for this product and no evidence was gathered, usually because the validation had no access to the surface that would answer it.
It is not a pass and it is not a failure. Reporting it as either would be the most common way a trust product misleads people.
E1A model read the available material and concluded something. Useful for direction and for knowing where to look next.
It is not a finding. Model confidence is not evidence, and nothing at this grade passes a control on its own.
E2The source says so. A check is present in the code, a setting is configured, a policy exists and scopes what it claims to scope. Findings cite the file.
That a check exists is not that the check works. Code can be correct and unreachable, or present on one route and absent on the sibling.
E3A deterministic test was run and produced a result that is the same every time it runs. A dependency carries a published advisory, or it does not. A credential is in the history, or it is not.
It says nothing about the deployment. A test of the repository is a test of the repository.
E4The running system was asked and this is what it did. A request from the wrong account was refused. The header came back. The redirect happened.
It is a fact about the deployment at the moment it was tested, which is why a validation carries a date and why it can be run again.
E5Reproduced independently of the run that produced it.
It is the top of the scale and it is rare by construction. Most controls have no route to it.
Each control in the pack carries the weakest grade that may pass it, because the right answer is not the same for every question. Whether a check exists in the source is a reasonable way to settle input validation. It is not a reasonable way to settle whether your response headers are set, because the only thing that can answer that is the response.
1 of the 13 controls in the current pack cannot pass below runtime verified: security response headers are present. Source evidence for those is reported as what it is, rather than promoted.
A control with no evidence behind it is reported as uncovered. It is the single most important rule in the model, because the alternative, which is quietly treating an absence of evidence as an absence of problems, is how a clean report gets produced for software nobody examined. Evidence Coverage exists as a separate number for exactly this reason: it says how much of the picture was available, so a high score on thin coverage cannot be mistaken for a high score on deep coverage.