8 Checks Before Trusting a Supplier’s Private Calculation

1. What exact commercial claim needs verification?

The first check is the sentence the buyer needs established. “The supplier’s calculation is verified” is too broad. A useful claim might be that a specified pricing formula applied to a defined input record produces an amount no greater than an agreed limit, using a stated version and period.

For a synthetic invoice, distinguish “these100 line items sum to this total” from “these are all the billable line items for this customer.” The first is a computational statement. The second includes completeness and eligibility. A supplier can satisfy the arithmetic while omitting a credit unless the agreed claim also binds the relevant input set.

Write the allowed uncertainty into the result. If exchange rates, rounding or an estimated quantity affect the answer, the verifier needs the applicable rule. A private calculation cannot be assessed against a formula the buyer has never defined. The first deliverable is therefore a claim specification with inputs, output, version, period and permitted tolerance.

2. Are the inputs authentic, complete and in scope?

The second check is input provenance. Correct arithmetic over the wrong records can still produce an unusable answer. Identify where the inputs originate, who can change them, how the selected period is fixed and what evidence binds them to the commercial task. A computation proof does not automatically establish that a sensor reading, invoice or customer roster reflects the real world.

Test the boundary: identify who supplied the records, what population they represent and which exclusions are permitted. A sound proof or recomputation over an incomplete input set does not establish that the omitted obligations never existed. Preserve that residual trust explicitly.

3. Can the buyer inspect enough information to recompute?

The third check is whether the buyer can receive enough information to recompute the result directly. Full disclosure is often conceptually simple, but it may reveal confidential costs, customer records or proprietary parameters. Decide what the buyer actually needs before asking for the entire dataset.

A limited disclosure can be appropriate for a narrow claim. For example, a supplier might reveal eligible invoice lines while withholding unrelated customers. The buyer can then recompute the total and inspect the completeness condition for its own scope. That arrangement still depends on the agreement defining which records belong in the scope.

4. Is the recomputation independent of the original result?

The fourth check is independence. A second service returning the same answer is weak evidence if it uses the same unexamined intermediate result or follows the first verdict. Independent recomputation needs the agreed formula and a separately controlled execution path, with the required input evidence.

Document what the method exposes and what it leaves trusted. “The buyer can recompute” is not the same as “the buyer has verified the input source.” A successful arithmetic comparison should retain its exact boundary instead of becoming a general endorsement of the supplier.

Use deliberately changed synthetic cases when testing the procedure: a wrong rate, an omitted credit, a stale period or a different customer identifier. Each case should have an expected outcome. This article proposes those fixtures; it does not report that a named provider passed them.

5. What did a trusted reviewer actually examine?

The fifth check is whether a trusted reviewer can inspect the calculation under a bounded mandate. The report should identify the records, period, procedure, exceptions and reliance conditions. “Audited” without that scope does not tell the buyer whether the disputed calculation was examined.

A reviewer may inspect a sample, recompute every item or examine a control process. Those are different forms of evidence. Record which one was performed and whether the reviewer relied on supplier-selected records. Independence, access and reporting obligations belong in the purchase decision alongside the fee.

6. What does the execution attestation bind?

The sixth check concerns a trusted execution environment. AWS Nitro Enclaves documentation describes signed attestation documents containing measurements that an external service can compare with its access policy. It also documents different measurement behaviour for debug or attached-console modes. This supports checking the expected environment; it is not a universal certificate that the commercial result is correct.

The verifier must know which measurements and program are acceptable, validate the relevant attestation and bind the request and result to that environment. An attestation for an approved image does not help if the displayed invoice was calculated elsewhere or if the wrong input set was accepted.

Document the trust assumptions: hardware and platform roots, software review, key or policy administration, input supply and output binding. A trusted execution design can reduce some disclosure or operator-access concerns while retaining dependencies that must be understood. Its measured cost and reliability need an actual scoped test.

7. Which statement does the cryptographic receipt prove?

The seventh check is the statement proved by a cryptographic receipt. RISC Zero’s version 3.1 receipt documentation distinguishes the journal of public outputs from the proof seal and describes verification against the expected guest-program image identifier. The expected program is part of the claim, not a detail the supplier can substitute unnoticed.

In the invoice example, the buyer needs an agreed calculation program and an output linked to the specific invoice, input commitment and period. A proof for another customer, an old price table or a trivial program that prints a number does not establish the intended claim merely because its cryptography verifies.

Record the verifier implementation and version, expected program identity, public input or commitment bindings, output meaning and freshness or challenge mechanism where required. A cryptographic success should be interpreted only after these conditions match the decision.

Privacy also depends on what is disclosed. A system can prove a narrow result while revealing it as a public output; repeated outputs may expose more than one isolated answer suggests. The buyer and supplier should agree the permitted output and disclosure scope rather than treating the term “zero knowledge” as a complete commercial confidentiality policy.

Separate test mode from production verification. A development artifact or unchecked receipt should not be promoted to verified evidence. The DN instrument asks whether the selected verification was actually run and how input and output bindings are documented. It does not verify a proof, validate an enclave or audit a supplier in the browser.

8. What does the complete check cost after exceptions?

The eighth check is operating cost. A cheap verification step can be expensive if preparing evidence, resolving mismatches and maintaining the verifier consume substantial work. Compare methods against the same claim and error-handling obligations.

Use a hypothetical setup cost of1,000,1,000 claims, a0.10 per-claim check and a5% exception rate. If each exception takes ten minutes at60 per hour, exception work costs500. Total scenario cost is1,600, or1.60 per claim. At10,000 claims with the same assumptions and setup cost, the unit cost falls to0.70. These are illustrative inputs, not measurements of any proof system or auditor.

The tool preserves evidence gaps alongside cost. A lower cost does not make an unbound or untested result acceptable. Compare a deliberate failure case, a stale result and a mismatched input as part of an authorised evaluation. Retain the exact evidence produced and the work needed to resolve each exception.

The purchasing decision should name one claim, one chosen evidence method and one residual trust assumption the buyer accepts. A supplier’s private calculation becomes commercially useful when the buyer knows both what has been established and what remains outside the check.

Frequently asked questions

Primary sources

1. RISC Zero Receipts 101. Version 3.1 receipt journal, seal, expected guest image and verification boundaries. Reviewed 2026-11-11.
2. AWS Nitro Enclaves cryptographic attestation. Signed enclave measurements, policy comparison and debug-mode PCR behaviour. Reviewed 2026-11-11.

Related DN research

• AI Agent Outcome Receipts