How a gate reaches its verdict Diagram

mainworthy gate exits 0 for passed, 1 for failed, 2 for blocked and 3 for pending. An exit code of 4 is not a verdict: the command met an input, connection or operation error.
The Changes screen shows the same verdict and its reason. Reading it computes nothing new: the gate compares counts that Mainworthy keeps up to date.

A report is accepted before it is applied. From that moment the gate reads pending, whatever it read before, so nobody is served a verdict from before the upload.
Pending also means a hold has run out, evidence is missing, or nothing was proven: a report of only skipped results proves nothing. A commit that was never reported reads pending too.

Pending for an unapplied report or an expired hold comes first. Then failed, then blocked. Only then does missing evidence read pending, and passed is what is left.
So one failure judged real fails the gate even while another failure is still unexplained.

Excusing a failure (flaky, infrastructure, already failing where the change started) lets the gate pass with no new upload. Calling it real (a defect, a wrong test, a changed expectation) fails it. Changing an answer later recomputes the gate at once: an excused failure changed to a defect fails it.
Withdrawing an answer undoes only what it did, so the failure counts again and the gate blocks. Results disagree only in a planned run, where one producer passes a case and another fails it. That blocks the run until a person decides, and the answer that the failure was a mistake lets the pass stand.