Job Receipt

The full execution-proof receipt for a single job. It shows the four canonical hashes (target spec, port spec, baseline, and result), the probe coverage (attempted versus planned), the final status, the scanner binary and protocol versions, the start and completion timestamps, and the verbatim receiptJson the scanner submitted or the server synthesized. The result hash is recomputed server-side over the sorted observed-open set, so a receipt you can read is one the server has already verified. Use this view as the forensic anchor when reconciling a recorded port-state change against the run that produced it.

Fields & columns

Name	Description
`Status`	Final job status the receipt was written for (completed, failed, partial, cancelled, timed_out). Only completed jobs can assert no-change.
`No change vs baseline`	True when verified full coverage produced an observed-open set byte-identical to the baseline (result hash equals baseline hash).
`Target spec hash`	SHA-256 over the normalized, sorted target specifications as assigned to the job — proof of WHAT was scanned.
`Port spec hash`	SHA-256 over the expanded, de-duplicated, numerically-sorted port set — proof of WHICH ports were scanned.
`Baseline hash`	SHA-256 over the baseline open set the job was diffed against. Null on the legacy raw path (no baseline was supplied).
`Result hash`	Server-recomputed SHA-256 over the sorted observed-open set. The evidence anchor; matches evidenceHash on any change rows this job produced.
`Probes (attempted / planned)`	Coverage: probes the scanner attempted versus probes the server planned. Equal on a completed receipt; attempted is lower on an incomplete one.
`Open ports / Changes`	Count of open ports observed and port-state transitions recorded by this job.
`Scanner version / Protocol version`	The scanner binary version and wire-protocol version that produced the receipt, for fleet-version auditing.
`Started / Completed`	When the job started and finished — the execution window the receipt attests to.
`Receipt JSON`	The verbatim forensic claim (scanner-submitted or server-synthesized). The raw record an auditor can re-hash independently.

How to

Independently verify a result hash

Open the receipt from the scan execution-proof list or a change row's job link.
Read the observed-open set out of the Receipt JSON.
Recompute the canonical SHA-256 over the sorted set and compare it to the displayed result hash.
Confirm probes attempted equals probes planned for a completed receipt (full coverage).

Gotchas

A null baseline hash is normal for receipts synthesized on the legacy raw path — those jobs were not given a baseline to diff against, so they cannot report "no change vs baseline".
The signature field is reserved for a future signing capability and is always empty in this version. The trust anchor today is the API key, TLS, and the server-recomputed hashes — not a scanner signature.
An incomplete receipt (failed, partial, cancelled, timed_out) carries the partial observed-open set and a result hash over only what was seen; it deliberately records zero changes because partial coverage cannot assert a closed transition.
This view reads from the jobs database. If it is temporarily unreachable, the page shows "execution proof temporarily unavailable" instead of erroring. A receipt that genuinely does not exist (e.g. a pre-scan-proof job, or a wrong id) shows a distinct "receipt not found" state.
The probe counts can differ in their units of measure across scanner versions; the completed-coverage gate compares the scanner's attempted count against the server's planned count for the same job, so a mismatch is what blocks a false "completed" claim.

API calls (1)

Method	Path	Description
GET	`/api/jobs/:jobId/receipt`	The single job receipt detail, including the verbatim forensic receiptJson

Execution Proof — The scan-level list of all job receipts; this detail view opens from one of its rows
Port State Changes — A change row links here by job id; this receipt's result hash is that row's evidence anchor