A detector should not choose the punishment

A changed hash, a missed event, a stale dependency, or a policy mismatch can describe very different conditions. The same observable difference might be an expected deployment, a local configuration error, a broken evidence path, or a deliberate attempt to cross a governed boundary. Treating all four as the same incident produces either alert fatigue or unnecessary shutdowns. The evaluator therefore receives the captured drift record and asks separate questions about severity, affected scope, confidence in the evidence, dependency exposure, and the cost of being wrong.

The original TCA diagram described this as “evaluate and score impact.” In the operating system, that idea appears through explicit thresholds, allowable ranges, gate measures, dependency checks, and evidence-backed classifications. The important design choice is separation: the component that notices a difference does not get to declare a crisis. The evidence has to be measured against a rule that existed before the incident.

One green result answers one question

A recurring failure in AI governance is to turn a passing check into a general statement of safety. A valid identity does not prove current authority. A healthy dependency does not prove the requested action is permitted. A high aggregate score can still conceal a failed critical dimension. TCA impact scoring keeps these dimensions visible so one good answer cannot erase a different bad one.

This is also why range definitions matter. A measure needs an expected value, an allowable boundary, and a declared consequence when the observed value falls outside it. Without those elements, a score is presentation. With them, the score can route work, block a transition, or require a second authority. The decision becomes reproducible because another evaluator can apply the same evidence to the same range.

The arithmetic has to bite

The implemented QEnSAi validator makes this concrete. Its interface exposes twelve named checkpoints, and its server-side logic routes a valid composite to ALLOW while a composite mismatch terminates at isolation-fault. The useful result was not the color of the final status. It was that the same route produced different outcomes when the evidence changed, and that the failed variants stopped at identifiable boundaries.

That distinction separates a working measurement from a decorative one. We have also seen the opposite failure: a verifier recomputed the right answer but never compared it to the value carried by the token. Everything looked active. The function ran. The trace stayed green. The guarantee did not exist until the comparison controlled the gate. An impact score matters only when its result changes what the system is allowed to do next.

Proportion before escalation

The evaluator’s output should be narrow: the observed impact, the evidence behind it, the affected boundaries, and the response class justified by the measurement. Low-confidence or low-impact drift may call for continued observation. A policy breach may require a warning and governed follow-up. Identity, state, or integrity failure may require immediate isolation. The response belongs to the next stages; the evaluator supplies the basis.

Part 5 follows that basis into warnings and alerts. The central question is not whether the system can display a warning. It is whether the warning can become owned, traceable work before it disappears into another dashboard.