撰寫驗收合約
概念驗證應回答特定的操作問題，例如提議的工作流程是否可以在保留證據的同時區分對齊的郵件、未對齊的合法服務和未解決的來源。定义测试人群、允许的操作、输入版本和负责的操作员。在演示之前设定成功标准，包括如何计算不完整的观察和中断的任务。
不要讓供應商看到結果後只選擇有利的案例。冷凍一小份代表性包裝，並保留保留的陰性對照（如果適用）。指定目標是文件審查、本地模擬或在授權租用戶內執行。每種模式都證明了不同的事情。缺乏租戶存取是執行證據的限制，而不是記錄功能的自動失敗。
測量整個工作流程
分別記錄預期的解釋、觀察到的解釋、證據輸出和操作員的努力。如果寄件者所有者仍然未知，則正確的身份驗證標籤無法完成調查。清理輸入、請求存取或修正導入所花費的時間應包含在操作工作負載測量中，而不是在沒有解釋的情況下作為設定雜訊被刪除。
一個有用的擬議驗收包包括一個規定的一致身份、一個未一致的合法服務案例和一個身份證據不足的案例。将最后一个案例保留为未知。即使导出仍然打开，故意将其重新标记为对齐也必须使评估失败。这是建议的阴性对照，而不是观察到的产品故障。
Close with an accountable decision
對於每個失敗的標準，記錄問題是否為產品缺陷、不受支援的功能、測試設計錯誤或缺少存取。允許在新版本下進行更正後的重新運行，而不刪除第一個結果。如果標準發生變化，請解釋原因並重新運行受影響的案例；不要僅僅為了獲得有利的分數而移動大門。
召開退出會議，審查原始證據、未解決的風險、保留的內部努力和變更權限。該決定可以是繼續、在較小範圍內繼續、延長特定測試或停止。 RFC 9989 和 RFC 9990 提供協議和報告基礎，但不定義購買接受閾值。本指南中的閾值是建議的評估控制。通過的模擬無法授權生產DNS更改或建立交付、法律合規性或保證收件匣放置。
Use an explicit acceptance ledger
對於每個案例，記錄輸入版本、預期標籤、觀察到的標籤、下一個證據請求、所需所有者、更改權限和匯出位置。正確的未知標籤與自動DNS更改配對仍然不符合權威標準。刪除未知行的導出無法儲存證據。缺少租戶連線會使執行標準未經測試、無法通過或診斷為產品缺陷。
Suppose all classification checks pass but the exported file omits its input references. Hold the evidence-export criterion, retain the first run and retest the corrected version. Do not average away that failed mandatory gate with a high presentation score. The acceptance contract must identify which criteria are mandatory and which permit a scoped exception. No local workflow, tenant trial or mutated execution was run for this written example.
協議範圍和評估限制
RFC 9989第 4.4、5.3.5 和 5.4 節 區分經過身份驗證的標識符， 結盟 和接收器處理。單獨有效的簽名並不完整 DMARC 判決，而通行證並不驗證業務內容。 RFC 9990第 3.1、3.5.1、3.5.4 及 7 節 描述匯總證據、報告身分、副本和隱私。這裡提議的商業評估、人員配置和權限門限是編輯建議，而不是 RFC 規定的產品功能。閱讀這些書面範例不需要缺少可執行補充；操作聲明需要單獨授權的觀察測試。