參考
錯誤
本頁存在的目的在於一個區別：失敗的執行與出錯的執行是兩回事，把其中一種呈現為另一種，就等於告訴開發者他們的變更不好，而實際上是測試工具倒了。
失敗是一種結果，錯誤不是。
FAIL 表示閘門已經評估過，而證據低於門檻值。這是關於這項變更的品質結果。
RUN_ERROR 表示執行沒有完成。沒有任何閘門被評估，關於這項變更也沒有任何東西被量測。它不是決策狀態，PARTIAL 和 CANCELLED 也都不是——它們描述的是一次執行發生了什麼，而不是對一個系統做出了什麼決定。
未完成的執行會回報什麼
針對未完成執行的閘門會以 5 結束，而不是 1。證據是缺少了，而不是不好，這兩者需要不同的回應：失敗的閘門要你去檢查你的變更，未完成的閘門則要你去檢查你的基礎設施。
無法量測的案例
出錯的案例會被納入區間界限，而不是被丟棄。每個指標都記錄四個計數——總數、符合資格、已觀察與缺失——而區間會把它無法看到的案例考慮進去。
這件事比聽起來更重要。把未評分案例算成零的指標，會把系統本身的停機當成模型的品質失敗記在模型頭上；而一個在系統開始失敗時悄悄縮小的分母，正是讓失敗中的系統回報分數上升的原因。這兩種情況都曾在一個線上助理上觀察到，當時有 13.8% 的呼叫回傳 HTTP 500。
暫時性失敗
系統可以宣告某次失敗是暫時性的，而暫時性失敗會被重試，而不是被記錄為品質結果。供應商逾時並不是關於提示詞的證據。
這項宣告是明確的：可呼叫系統會以 retryable=True 拋出 TransientError。retryable 預設為 False，沒有設定它的 TransientError 會像其他例外一樣記錄在案例上，因此該案例會是缺失，而不是被重試。HTTP 系統與評審供應商不需要宣告：逾時、連線中斷、429 或 5xx 都會為它們自動重試。無論哪種情況，一次呼叫最多嘗試四次，並有退避機制，仍然失敗的案例則視為缺失。進度與並行 展示了這兩種情況。
設定錯誤
結束代碼 2 表示呼叫方式或設定有誤，而且什麼都沒有執行。配額拒絕就是其中一種：它是一個附有具名理由的設定錯誤，在第一個案例執行之前就被拒絕，而且絕不是決策狀態。商業上的事實不應該披著品質判定的外衣出現。
診斷確實失敗的部分
oloproof diagnose RUN_ID --intervention gold-context --criterion answer_correct介入是它在重新執行失敗案例時所套用的條件——gold-context、top-k 或 reranker——而 criterion 說明要取哪個評估器的失敗。診斷會回報失敗因素及其計數、背後的情境 ID，以及它所做的假設。它指出的是一個因素，而不是原因：引擎不會斷言某件事造成了另一件事，呈現它的任何畫面也不會。