Verify a RevUp Render receipt

How to read the report

Three headline outcomes, then one line per check.

VERIFIED

Every check passed. Outside the approved mask the output is byte-identical to the input, and the receipt chain is intact.

VERIFICATION FAILED

At least one check failed. Something in the bundle does not match what the receipt claims. Do not rely on the render.

RECEIPT MATH VALID

You dropped a bare receipt or worldline without the images, so only the receipt arithmetic could be checked, not the pixels.

bundle contents

receipt.json, input.png, mask.png and output.png are all present.

receipt format

The receipt uses a spec this verifier understands. The report names the profile: masked-inpaint means a diffusion model made the pixels inside the mask; deterministic-recolour means they are integer arithmetic on the input and the receipt re-executes to the same bytes with no model or GPU, measured identical on x86-64 and Arm machines. An unfamiliar profile is named, not failed, because the pixel and chain checks do not depend on it.

receipt certificate

Hashing the receipt's manifest reproduces its certificate, so the receipt was not edited after signing.

input / mask / output file digest

Each file's hash equals the one named in the receipt, so the files are the ones the receipt describes.

dimensions consistent

Input, mask and output decode to the same width and height.

locked digest matches receipt (input / output)

The pixels outside the mask, hashed from the decoded images, equal the receipt's locked-region digests. Equal on both sides means byte-identical outside the mask. This is the guarantee.

worldline chain intact / chain links intact

Every revision in the project's history points at the certificate of an earlier revision, with no gaps and no rewrites. A project may branch (several revisions can share a parent when you render variants) and each branch is checked the same way.

receipt is on the chain

This receipt is one of the links in that history, not a stray.

client review / comment n / approval n

When the bundle carries review.jsonl, each client comment and approval is checked on its own line: its certificate re-derives (the text was not edited), it names this project and this render’s output by digest (V1; entries written before 2026-09-24 carry no project name and say so), the pixels under a comment’s rectangle still hash to what it recorded (V2), and an approved frame is every pixel of this output (V3). An approval names pixels, not a person: the author field is a claim that cannot be edited unnoticed, not a signature. When the reviewer’s browser holds a signing key, a fourth line (V4) checks an Ed25519 signature over the entry’s canonical bytes; that key identifies a browser profile, not a person, and an unsigned entry is reported as unsigned rather than failed.

verification run

The verifier itself finished without an internal error.

What the verifier checks

1. Every file in the bundle re-hashes to the digest named in the receipt.
2. The PNGs are decoded with our own decoder, not the browser canvas, and the locked-region digest of the output equals the locked-region digest of the input.
3. The receipt’s certificate re-derives from its canonical bytes, and every link in the project’s worldline chains to an earlier entry, branches included.
4. If a client commented on or approved this render, each comment’s rectangle and each approval’s frame is re-hashed from the same decoded output and compared with what the client’s entry recorded.

The same check runs offline with our command-line verifier, available to customers on request, and the receipt format is the open INVAR format. Get a bundle from any project at app.revuprender.com.