Write the acceptance contract
A proof of concept should answer a concrete operational question, such as whether the proposed workflow can distinguish aligned mail, unaligned legitimate services and unresolved sources while preserving evidence. Define the tested population, allowed actions, input version and responsible operator. Set success criteria before the demonstration, including how incomplete observations and interrupted tasks are counted.
Do not let a supplier select only favorable cases after seeing results. Freeze a small representative pack and retain a withheld negative control if appropriate. Specify whether the goal is documentary review, local simulation or execution inside an authorized tenant. Each mode proves different things. Lack of tenant access is a limitation of execution evidence, not an automatic failure of a documented feature.
Measure the whole workflow
Record expected interpretation, observed interpretation, evidence export and operator effort separately. A correct authentication label does not complete an investigation if the sender owner remains unknown. Time spent cleaning inputs, requesting access or correcting an import should be included in an operational workload measurement rather than removed as setup noise without explanation.
A useful proposed acceptance pack includes one stipulated aligned identity, one unaligned legitimate-service case and one case with insufficient identity evidence. Preserve the last case as unknown. Deliberately relabelling it as aligned must fail the evaluation even if the export still opens. This is a proposed negative control, not an observed product failure.
Close with an accountable decision
For every failed criterion, record whether the issue is a product defect, unsupported capability, test-design error or missing access. Allow a corrected rerun under a new version without deleting the first result. If criteria change, explain why and rerun affected cases; do not move the gate merely to obtain a favorable score.
Set an exit meeting that reviews raw evidence, unresolved risks, retained internal effort and change authority. The decision can be proceed, proceed within a narrower scope, extend a specific test or stop. RFC 9989 and RFC 9990 provide protocol and reporting foundations, but do not define a purchasing acceptance threshold. The thresholds in this guide are proposed evaluation controls. A passing simulation cannot authorize production DNS changes or establish delivery, legal compliance or guaranteed inbox placement.
Use an explicit acceptance ledger
For every case record input version, expected label, observed label, next evidence request, required owner, change permission and export location. A correct unknown label paired with an automatic DNS change still fails the authority criterion. An export that drops the unknown row fails evidence preservation. A missing tenant connection leaves that execution criterion untested, not passed or diagnosed as a product defect.
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.
Protocol scope and evaluation limits
RFC 9989 Sections 4.4, 5.3.5 and 5.4 distinguish authenticated identifiers, alignment and receiver handling. A valid signature alone is not a complete DMARC verdict, and a pass does not validate business content. RFC 9990 Sections 3.1, 3.5.1, 3.5.4 and 7 describe aggregate evidence, report identity, duplicates and privacy. Proposed commercial evaluation, staffing and authority gates here are editorial recommendations, not RFC-mandated product features. No absent executable supplement is required to read these written examples; operational claims require separately authorized observed tests.