# Methodology What a verification record documents depends on its provenance. This reference states exactly how exclusion checks work and where their limits are. The canonical HTML version is https://federal.contractors/methodology. ## Why prove you asked A free SAM.gov search is a sufficient method for suspension and debarment verification under 2 CFR 180.300. Subrecipient verification follows 2 CFR 200.332(a); vendor verification applies to covered transactions, not every purchase. The separate documentation problem starts after the result leaves the screen. 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. Three times stay separate in every record: the source as-of time (what the extract is current as of), the retrieval time (when we fetched the artifact), and the check time (when the check executed). No check includes state debarment lists. ## Source freshness A check runs against the latest successfully loaded, dated extract. Two independent rules are recorded with each check. Retrieval age: the extract must have been retrieved within 36 hours of the check, or the record reports `retrieval-stale`. Source-date lag: the extract's as-of date is a whole UTC calendar day that may be the check's own UTC day or lag it by up to 1 UTC day and remain within the warning window. A longer lag is reported as `source-date-delayed`. A recently downloaded file can still carry an old source date, so both rules are assessed and recorded separately. A valid dated check can complete with either warning. Missing, malformed or impossible future provenance cannot produce a healthy assessment. Historical records retain the assessment and policy sealed when their check ran, rather than being reassessed against today's date. ## Timestamps and sealing Checks are timestamped in UTC at execution. 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. ## Exact-check sealing A record seals the exact completed check that produced it. Manual sealing from the browser references a one-time, IP-bound attestation to the finished check; client-supplied evidence is never accepted and sealing never reruns the source query. The record's check time is the time the check executed, kept separate from when the record was written. ## 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. ## 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. ## Separate assurance layers Checksum, issuer signature, and independent timestamp each prove one thing, and nothing more. The SHA-256 seal shows canonical byte consistency. The issuer signature authenticates the evidence bytes under the trusted issuer key. The RFC 3161 timestamp proves that the issuer signature existed no later than the Timestamp Authority's time. No layer proves check execution time, source truth, matching correctness, identity, or a legal outcome. Which layers a given record carries is read from that record's own seal, signature, and timestamp fields, not from this page. ## 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; they never become UEI matches without an exact identifier match. Up to 200 candidate rows are returned and the record states explicitly whether that list is truncated, so an incomplete candidate review is never presented as complete. Parent or affiliate relationships never propagate exclusion status. ## Records versus packets A verification record (format 2) documents one check. An audit packet is a separate sealed document that gathers a monitoring period's records, source facts, detected changes, and cadence gaps. Newly issued packets use packet-result version 6 and the construction method `audit-packet-result-v6-no-account-identity`. This is separate from record format 2. They omit automatic login name and email. Historical packets through packet-result version 5 retain the attribution sealed at issuance. Packets record monitoring as dated intervals with recorded start and end reasons; spans between intervals are recorded interruptions, not missed cadence, and no continuous coverage is claimed across an interruption. ## Permanent access Every record lives at a permanent URL and is public by its unguessable id; anyone with the link can read it without an account. Records and packets already issued remain accessible after monitoring service ends, and revoking an API key or deleting the account does not remove or rewrite them. ## 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. ## Official sources - [SAM.gov Exclusions](https://sam.gov/content/exclusions): the official public federal exclusions source. - [2 CFR 180.300](https://www.ecfr.gov/current/title-2/subtitle-A/chapter-I/part-180/subpart-C/section-180.300): permitted verification methods for covered transactions. - [2 CFR 200.332](https://www.ecfr.gov/current/title-2/subtitle-A/chapter-II/part-200/subpart-D/section-200.332): pass-through entity requirements for subawards. - [USAspending.gov](https://www.usaspending.gov/): federal award and spending data as reported by agencies, used in public contractor profiles. - [Federal Audit Clearinghouse](https://www.fac.gov/): public Single Audit submissions. ## 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.