What is a verification record?
A verification record is the saved evidence produced from one exclusion check. It records what was searched, what the cited source data returned, when the check ran, which source snapshot the result covered, and the source's as-of and retrieval times.
In federal.contractors, format 2 records have a permanent identifier and an RFC 8785 canonical JSON payload. Anyone with the record can recompute its SHA-256 hash and compare it with the printed seal. A mismatch detects changed canonical bytes. New production records also carry an RFC 9943 PS256 issuer signature over the exact format 2 bytes and a DigiCert RFC 3161 timestamp over the RFC 9921 signature imprint.
What the record contains
A format 2 record contains the original query, any resolved UEI, identity basis, matching and normalization versions, check time, result details, candidate count and truncation, source artifact, source as-of and retrieval times, completeness facts, source digest, and record seal. Identifier and name-only results remain distinguishable.
The saved canonical payload has no application update path. Corrections and later checks create new records rather than rewriting what an earlier check observed.
Why source dates matter
A check can only describe the data it actually covered. The check timestamp says when the operation ran. The source as-of time says when the underlying data was reported or extracted. The retrieval time says when federal.contractors obtained the artifact or API response. Those times may differ.
A verification record must not assign the check timestamp to registration, award, or exclusion data that the check did not refresh. Each source retains its own provenance.
What the SHA-256 seal shows
Recomputing the hash and matching the stored value shows that the canonical payload bytes hash to the printed seal. A mismatch detects changed canonical bytes.
The checksum alone does not authenticate federal.contractors as issuer, prove that the check executed at the stated time, or establish independent time. A SCITT issuer signature prevents replacement without the issuer key and authenticates the exact evidence bytes. For new production records, the RFC 3161 timestamp proves that signature existed no later than the Timestamp Authority's time.
The seal does not prove that the government source was correct, that the searched party was identified correctly, or that a transaction complied with every applicable rule. Those questions depend on source quality, identity evidence, and legal context.
What the issuer signature and timestamp show
An RFC 9943 SCITT Signed Statement binds federal.contractors as issuer, the opaque record URL as subject, an SPKI-derived public key id, an issuer-asserted issuance time, and the SHA-256 commitment to the exact format 2 evidence bytes. Under RFC 9921 COSE-then-Timestamp, the timestamp request covers the CBOR-encoded COSE_Sign1 signature field, not the full statement file. The returned RFC 3161 token is carried under COSE label 270.
The offline bundle includes the exact evidence, bare and timestamped .scitt statements, timestamp request and response, issuer-key history, verification policy, Timestamp Authority trust anchor, and retained revocation lists. The verifier requires issuer-key history fetched separately from the bundle so the bundle cannot appoint its own issuer key.
The issuer signature authenticates the evidence bytes under that trusted key. The DigiCert timestamp proves that signature existed no later than its independent time. Neither proves check execution time, government source truth, matching correctness, identity, or legal compliance. No independent Transparency Service receipt is attached.
Format 1 and earlier unsigned or untimestamped format 2 records retain their original verification rules and claims.
Evidence of diligence, not a verdict
A verification record documents the check, method, source, date, and result. The person responsible for the transaction uses that evidence to verify the party and apply the relevant award terms or regulation.
The record does not promise an audit outcome, guarantee compliance, or make a responsibility determination. It preserves evidence of diligence in a form that can be retrieved and shared, with a canonical seal that can be recomputed.
Primary sources
Related terms
SCITT · Exclusion check · Suspension and debarment verification · Exclusion