Skip to main content

Methodology

What a verification record documents depends on its provenance. This page states exactly how checks work and where their limits are.

Why prove you asked

A SAM.gov search is free. The separate documentation problem starts after the result leaves the screen. The duty is to verify before making a subaward, and before a covered transaction when 2 CFR 180.300 applies. A retained record should show the query, the dated source, the candidates returned, and how identity ambiguity was handled.

A federal.contractors verification record preserves those facts for one check. Monitoring adds dated re-checks for the period the customer says the relationship remains active. A packet gathers the period's records, source facts, changes, and cadence gaps. It is evidence of diligence, not a verdict about eligibility or legal compliance.

Sources and provenance

Every verification record names its own sources, each with the date or time it is current as of. Exclusion checks run against the SAM.gov Exclusions daily extract loaded into our database, and each record cites the exact extract: its source as-of date, retrieval time, exclusion-record count, invalid-row count, and SHA-256 hash. Registration re-checks read SAM entity registration data and carry that entity's own as-of date. Single Audit filing checks query the Federal Audit Clearinghouse and record the API retrieval time. Every record stores the check time separately from source provenance. No check includes state debarment lists.

Exclusion matching

Each check records exclusion-match-v1 and legal-name-nfkc-v1. A UEI query returns exact UEI matches first, then potential candidates found by the registry CAGE or exact normalized legal name when an exclusion has no UEI or a contradictory UEI. A CAGE query records registry field agreements and contradictions. Name queries use normalized substring discovery only. Non-UEI candidates remain potential matches, candidate truncation is explicit, and parent or affiliate relationships never propagate exclusion status.

Timestamps and sealing

Checks are timestamped in UTC at execution. New record format 2 includes the record id, checked input, identity basis, customer confirmation when present, candidate-set completeness, method versions, results, limitations, and source publication, retrieval, artifact, digest, and completeness facts. Those fields are serialized with RFC 8785 JSON Canonicalization Scheme, stored as exact UTF-8 bytes, and hashed with SHA-256. Existing format 1 records retain their frozen historical serialization.

To verify a format 2 seal yourself: open the record, download the JSON, canonicalize the record field with RFC 8785, compute SHA-256 over those UTF-8 bytes, and compare it to the printed seal. A mismatch shows that covered bytes changed. A matching checksum alone shows byte consistency; it does not authenticate the issuer or establish independent time.

Issuer signatures

A format 2 record with a SCITT Signed Statement has an RFC 9943 PS256 issuer signature over the SHA-256 commitment to its exact stored bytes. The protected RFC 9995 Hash Envelope names federal.contractors as issuer, the opaque record URL as subject, an SPKI-derived key id, PS256, SHA-256, and the issuer-asserted issuance time. Production SCITT signing requires a dedicated non-exportable Google Cloud KMS key. Signing failure prevents record creation. Public key history retains activation, retirement, and compromise states. Format 1 and earlier unsigned format 2 records remain labeled under their original formats.

Download the .scitt file or offline bundle from the record. The browser and CLI use the same verifier core and issuer-key history fetched separately from the bundle from federal.contractors. For long-term offline verification, retain issuer-key history obtained through a trusted channel. They report the issuer signature, evidence digest, independent timestamp, source digests, and matching reproducibility separately. The issuer signature authenticates the evidence bytes under that trusted key. By itself, it does not establish independent time, source truth, matching correctness, or a legal outcome.

Independent timestamps

Each new production SCITT Signed Statement must receive a DigiCert RFC 3161 timestamp before the verification record is committed. Under RFC 9921 COSE-then-Timestamp, SHA-256 covers the CBOR-encoded COSE_Sign1 signature field, and the returned token is carried under unprotected COSE label 270 without changing the issuer-signed fields. The application stores the token, request, certificate chain, trust anchor, current revocation lists, and exact timestamped statement as separate attachments with no update path. A Timestamp Authority outage or invalid response prevents record creation.

The browser and offline CLI validate the accepted policy, nonce, signature imprint, timestamp token signature, critical timestamp-only certificate use, certificate chain, certificate validity at the timestamp time, and retained revocation material. The timestamp proves that the issuer signature existed no later than DigiCert's time. It does not prove the check execution time, source truth, matching correctness, identity, or a legal outcome. Checked at, issuer-issued at, Timestamp Authority time, source retrieval time, and source as-of time remain separate.

What we do not do

We document each check and its contents. We do not determine eligibility, provide legal advice, or certify a legal outcome. A checksum alone does not authenticate issuance. An issuer signature and its independent timestamp do not prove source truth, matching correctness, check execution time, identity, or compliance. A state debarment listing does not by itself bar a federal subaward; a clear result does not guarantee an entity is reputable. The record is evidence of diligence, not a verdict.

For the standards and assurance layers behind issuer signatures, read What is SCITT?

Coverage map

The map states what a packet contains for common test areas. It does not state how an auditor will judge the evidence.

2 CFR 200.332(a) and 2 CFR 180.300

Packets identify each monitored subrecipient, list dated checks across the selected period, show gaps longer than the one-day monitoring cadence, and preserve customer-recorded certification or clause dates.

2 CFR 200.318(h) with 2 CFR 180.300

Packets identify monitored vendors and subcontractors, list dated checks across the selected period, show cadence gaps, and preserve customer-recorded certification or clause dates.

Compliance Supplement Part 3, section I, Procurement and Suspension and Debarment

Packets enumerate the monitored entities, sealed verification records, detected changes, and source snapshots for the selected period.

Affiliation

federal.contractors is a private service with no affiliation to SAM.gov, the General Services Administration, or any government body. All underlying data is public government data, drawn from SAM.gov public extracts, the Federal Audit Clearinghouse, and USAspending.gov as reported by federal agencies; our product is the checking, documentation, and retention layer built on top of it.

Reviewed 2026-08-27.