Five Recipient Checks Before a Technical Result Can Be Accepted

A technical result can be authentic, internally consistent, and policy-passing without being ready for use.

That is not a contradiction. The producer can supply evidence for one recorded comparison. A verifier can check that evidence against approved inputs and issue a receipt. Neither action decides whether the recipient should rely on the result, release an artifact, or deploy a system.

The handoff becomes clearer when a recipient asks five questions in order. Each question has a different input, catches a different failure, and leaves a different decision behind.

Scroll horizontally to see every column.

The order matters. A later check cannot repair a failure in an earlier one, and an earlier pass cannot answer a later question.

1. Is this the comparison we intended to review?

Begin with the question, not the score. Identify the expected baseline, proposed change, evaluated artifacts or services, runtime or capture conditions, ordered cases, scorer, policy, and retained outputs. These fields describe the transaction the evidence can support.

For a model deployment comparison, “the quantized model passed” is not enough. The recipient needs to know which baseline artifact was used, which subject artifact was produced, how each side ran, which inputs were paired, what metric was computed, and which policy produced the verdict. A different conversion, prompt template, runtime image, schedule, or policy is a different review question.

The same discipline applies when no local model artifact exists. A hosted-service record may retain the provider, requested model, observed model or revision, configuration, harness, and observation window. Those fields identify the captured service interaction. A revision returned by the service is still a source claim; it does not prove which hidden weights ran. The recipient should not turn an unavailable artifact identity into an invented one.

This first check also inventories what arrived. An evidence pack, a verifier receipt, and an HTML report have different roles. The evidence is the signed machine record. The receipt states what a verifier checked. The report is a readable rendering. A polished report cannot substitute for missing evidence or silently inherit the authority of a nearby receipt.

2. Did verification use expectations we approved independently?

Evidence can agree perfectly with itself and still describe the wrong transaction. The recipient therefore supplies trust inputs from outside the submission: expected artifact or complete-run identities, schedule or case-set identity, policy bytes, runtime or request identities where applicable, and authorized signer fingerprints.

“Independent” refers to control, not necessarily a different company or storage system. The important condition is that the submitter cannot rewrite both the evidence and the values meant to check it in one action. Copying the expected subject digest or signer key out of the submitted bundle creates a circular check.

Signature validity and signer authorization are also separate. A valid signature answers which key signed these bytes. The recipient’s trust registry answers whether that identity and fingerprint were authorized for this purpose, at this time, under the relevant revocation and freshness rules. The verifier should use its own identity and signing key when it issues a receipt.

The released acceptance-handoff fixture makes these distinctions concrete. Its successful path binds the expected artifacts, schedule, runtimes, evidence signer, receipt verifier, envelope signer, and recipient policy. The same fixture rejects a wrong artifact, unknown or revoked signers, an unknown receipt verifier, stale transport, tampered evidence, and a receipt that contradicts its envelope. Those rejections are successful checks, not evidence that every submitted result should pass.

Verification establishes integrity and supported replay against the supplied trust inputs. It does not establish that the trust inputs were wisely chosen, that a captured execution happened as claimed, or that the result is suitable for the recipient’s use.

3. Did the recorded result meet the agreed policy?

After identity and trust come the requirements that governed the comparison. Inspect the policy itself, not only the word “pass.” A useful review can name the metric, threshold direction, uncertainty rule, sample or completeness requirement, absolute quality floor where one is needed, and the exact policy revision that was applied.

Keep evidence integrity and policy outcome on separate axes. Authentic, replayable evidence can correctly fail its policy. Conversely, a policy pass is meaningful only for the authenticated transaction and the requirements the policy actually contains.

The acceptance-handoff fixture deliberately preserves this distinction. Its retained technical receipt records integrity_ok: true and policy_verdict: pass. A stricter current recipient policy can still reject that authentic historical pass. The old receipt has not become false; the present recipient has declined to accept it under a different rule.

Judge evidence needs the same care. Replay can authenticate retained calls, check admitted trials, and recompute aggregation and policy arithmetic. It does not establish that the ratings are correct. Rubric suitability, reference quality, and the validity of the judge’s assessments remain separate review questions. An advisory judge result also cannot be promoted into a required acceptance decision merely because its arithmetic replayed successfully.

Finally, a technical policy pass is not deployment approval. It says the recorded comparison met the named requirements. It does not silently add security review, operational readiness, legal approval, product fitness, rollback planning, or authorization to release.

4. What remains uncertain, missing, or stale?

A reviewer should be able to state the result and its boundary in the same breath.

For the retained GGUF comparisons discussed in the shared review-standard article, a pass means that each 400-record comparison met its declared exact-match policy. The intervals include zero, so the positive point estimates do not demonstrate improvement or establish equivalence. The evidence contains no latency, memory, throughput, energy, or cost measurement. Those absences matter to a deployment decision even though they do not invalidate the recorded policy result.

Different evidence families leave different gaps:

• Captured replay checks the supplied records, bindings, and supported arithmetic. It does not prove the original execution occurred as claimed.
• Judge replay checks the retained rating process and aggregation. It does not establish that the ratings are correct.
• A hosted service’s observed model or revision is retained context from that service. It is not proof of the hidden weights, and verifying old evidence does not measure the service again.
• A finite schedule supports claims about the recorded cases, measurements, and policy. It does not establish population representativeness, broad safety, or fitness for every downstream task.

Freshness belongs here too. An old result may remain cryptographically valid while no longer answering the present question. If the artifact, service, prompt, retrieval corpus, tool set, runtime, case set, scorer, or policy changed, the organization needs a new record or an explicit reason the old one remains relevant. Rewrapping an old receipt does not create a new observation window.

The output of this check is not a generic disclaimer. It is a concrete list of unresolved questions, missing measurements, source-asserted context, and triggers for re-evaluation.

5. What decision does our organization own?

Only after the first four checks should the recipient decide what happens next. That decision may be accept, reject, defer, request more evidence, limit use to a narrower scope, or authorize a staged rollout. It belongs to the organization that bears the consequences.

A practical decision record names the evidence and receipt, approved policy, exact subject and baseline, material limitations, decision owner, time, exceptions, scope, and expiry or re-evaluation trigger. Operational requirements can sit beside the evidence without modifying the signed pack. If an exception is granted, record it as an organizational exception rather than editing the report or suppressing a verifier failure.

The released handoff fixture ends at recipient acceptance and explicitly does not authorize production deployment. A real organization may still require security, privacy, safety, compliance, change-management, capacity, rollback, monitoring, or customer-approval gates. Those controls should consume the technical result without pretending they were already encoded in it.

This separation protects both sides of the handoff. Producers can make precise claims about what their evidence establishes. Recipients can preserve their own trust inputs, policy, risk tolerance, and release authority. The result is not weaker because acceptance remains local; it is more useful because no layer claims authority it does not have.

Limitations

• The acceptance-handoff example is a deterministic release fixture, not evidence of organizational independence or a production deployment process.
• The five checks organize recipient review across several evidence families; each contract still has its own required identities, policies, receipts, and replay semantics.
• Verification depends on the correctness and governance of recipient-supplied trust inputs. Cryptography cannot repair an approved anchor that identifies the wrong subject or signer.
• Acceptance remains scoped to the recorded comparison, cases, measurements, policy, time, and organizational decision. It does not establish general model quality or safety.

Sources

Website documentation explains the maintained workflow. The acceptance behavior and examples discussed here were checked against InvarLock v0.16.1, commit 80b5de10832cd89e9561b06e995d5d71d4eff108; the tagged contracts, fixture inputs, technical receipt, recipient policy, and expected rejection cases preserve that evidence basis.

• Acceptance checklist
• Evidence and verification
• Trust model
• Reports and receipts
• Judge measurements
• Hosted-service requalification
• Three GGUF Deployment Comparisons Under One Review Standard
• Which Answers Changed Behind the Score?
• Tagged acceptance-handoff guide
• Tagged acceptance scenario results
• Tagged recipient policy
• Tagged technical trust anchors
• Tagged verification receipt