Five Recipient Checks Before a Technical Result Can Be Accepted

A saved comparison passes its technical policy. The receiving team applies a stricter rule and rejects the handoff. Both results can be correct: the earlier receipt records what passed then; the recipient decides what it accepts now.

InvarLock's released acceptance-handoff example preserves exactly this distinction. Its technical receipt records valid evidence and a policy pass. The example accepts the intended handoff, but rejects variants with the wrong artifact, an unauthorized signer or a stricter recipient requirement. These are controlled software checks, not customer deployment results.

Diagram

A retained technical receipt records valid evidence and a policy pass. The intended handoff is accepted, while a wrong supplied artifact and a stricter recipient policy each cause rejection.

One historical pass, different handoffs

Same technical receipt

The retained receipt records valid integrity and a historical policy pass.

Reference handoff: accepted

The intended artifact and recipient checks match.

Wrong artifact: rejected

The supplied artifact differs from the one the recipient approved.

Stricter policy: rejected

The current recipient requirements are not met. The historical pass keeps its original meaning.

Three controlled scenarios from the v0.16.1 acceptance-handoff fixture, not customer outcomes or deployment authorization.

Five questions turn that example into a practical review. Establish the intended comparison and trusted inputs before interpreting its policy result; then decide whether the evidence answers the receiving team's question.

1. Is this the comparison we intended to review?

Begin with what changed. Which original model is the baseline, which candidate is under review, and which cases, prompts, scoring rules and requirements were used? The evidence, verification receipt and supplied candidate must identify that comparison.

The fixture's wrong-artifact case shows why a model name is insufficient. A receipt about artifact A cannot support a handoff of artifact B. Correcting the handoff means supplying the intended artifact or evaluating the new one, not editing the receipt to match whatever arrived.

For a hosted service, record the provider, requested model, returned model or revision, settings, evaluation software and observation window. A service-reported revision is useful context, not proof of hidden model weights. Keep that distinction in the record instead of inventing an immutable artifact identity.

2. Did verification use expectations we approved independently?

A bundle can agree with itself while describing the wrong comparison. The receiving team therefore supplies its expected identities, cases, policy and authorized signing keys from outside the submission.

“Independent” refers to control. The submitter must not be able to rewrite both the evidence and the values used to check it in one action. Copying an expected artifact digest or signer key from the submitted bundle makes the check circular.

The fixture separately rejects unknown or revoked signers, an unknown receipt verifier, tampered evidence and a receipt that contradicts its envelope. A valid signature identifies the signing key; the recipient's trust rules establish whether that key is authorized. The envelope signer and technical verifier have separate responsibilities and must both be checked.

Ask for the signed evidence, the verification receipt and the separately approved checking inputs. The HTML report helps you read the result; it does not replace those materials.

3. Did the recorded result meet the agreed policy?

Inspect the actual rule behind “pass”: the metric, allowed change, uncertainty requirement, required cases and any minimum quality on each side. A correct calculation can produce a policy rejection, so keep evidence validity and policy outcome separate.

In the fixture, the historical receipt records integrity_ok: true and policy_verdict: pass. Applying the stricter current recipient policy rejects that authentic pass. The old receipt has not become false, and the recipient has not discovered a new model failure. It has declined the handoff under a different requirement.

Record both rules and both outcomes. If the technical comparison itself needs a revised threshold, create a separate analysis and preserve the earlier one. The recheck-or-rerun example shows when saved answers can support that work.

4. What remains uncertain, missing, or stale?

A passing result may leave a question that matters to your use unanswered. The GGUF comparisons record accuracy and uncertainty, but no latency, memory, throughput, energy or cost measurements. A team choosing a deployment for speed would still need timing evidence.

Likewise, replaying saved judge ratings checks their recorded aggregation; it does not establish that the ratings are correct. Review the rubric and assessments when the decision depends on them. Captured replay also does not independently prove that the original execution occurred.

Freshness needs its own check. The fixture rejects a stale envelope and missing evidence timing information. A new envelope around old results does not measure a service again. If the model, prompts, retrieved material, tools or runtime changed, state why the old evidence still applies or collect evidence for the changed setup.

Write the remaining question as a specific next step—such as measuring latency on the intended workload—rather than a general warning that more review is needed.

5. What decision does our organization own?

The receiving team can accept, reject, defer, request more evidence or limit reliance to a narrower use. Record who decided, when, for which comparison, under which policy and with what exceptions or review date.

For the stricter-policy fixture, a useful decision record would say: the historical technical pass verified, the current acceptance requirement was not met, and the handoff was rejected. It would link both policies and the unchanged receipt. That explanation is more useful than replacing the old pass with a single unexplained failure label.

The fixture ends at technical acceptance. Production authorization may still require the organization's security, operational and release controls. Keep those decisions in their own records, linked to the evidence they used.

Limitations

• The acceptance-handoff example is a deterministic release fixture, not evidence of organizational independence or a production deployment process.
• Each evidence format has its own required identities and replay rules. Hosted revisions and saved judge ratings retain the specific uncertainties described above.
• Verification depends on the correctness and governance of recipient-supplied expectations. Cryptography cannot repair an approved input that identifies the wrong artifact or signer.
• Acceptance covers the recorded comparison and intended use; the fixture does not establish model quality on other workloads or authorize deployment.