BrokerBlitzer
Vocabulary

Every state, and what it does not license.

21 published states across three lanes. Generated from the type definitions the engine is built from, so this page cannot describe a state the API does not serve.

Most systems report one status. The distinction between "the broker said yes" and "we went back and checked" is the reason there are 21.

EvidenceState

What a search-derived finding proves

Present only on findings the search lane produced. Absent on direct-scan findings, where scanStatus already carries the verdict. Only current_page_confirmed counts toward exposedCount or drives a filing.

  • indexed_candidate A search index held a URL whose title matched a name. The page was NOT fetched, so this is not established exposure and must not be rendered like a confirmed finding.
  • current_page_confirmed Fetched, classified as an individual profile, and matched to the subject on an attribute found in the rendered page content. The only search state that counts toward exposedCount.
  • subject_not_observed Fetched, but confirmation was not reached. NOT a claim of absence — carries a NotConfirmedReason, because "we could not confirm" and "they are not there" differ.
  • current_page_unreadable The fetch was blocked or errored. Unresolved, and never downgraded to "not there".
  • wrong_subject The live page is about a DIFFERENT named person. Suppressed from the customer's results in every mode, because showing a stranger's profile is worse than showing nothing.
NotConfirmedReason

Why a fetched candidate did not confirm

Always accompanies subject_not_observed. "We could not confirm" and "they are not there" are different facts, and only the first is what that state records.

  • stale_index The index entry pointed at a page that no longer exists (404/410).
  • generic_redirect The fetch landed somewhere structurally different — a dead profile bounced to a homepage.
  • soft_404 HTTP 200 with a "no results" body. A failure the status code does not report.
  • page_changed The page rendered but is not an individual profile: a search page, index, or opt-out guide.
  • identity_insufficient The subject is named but no independent discriminating attribute was found, so the match could be a namesake. Two attributes are required when the surname is common.
  • parser_uncertain We could not tell. The honest default rather than a guess in either direction.
RemovalStatus

Where a filing actually stands

Ten states, because "sent" and "worked" and "could not be sent" are three different things. Note undeliverable in particular: the request never reached the broker, which is counted as neither filed nor pending.

  • queued Recorded and waiting for the send drain. Nothing has left the building.
  • submitted The statutory request was sent to the broker's listed compliance address. Submitted is NOT delivered and NOT accepted — it means a well-formed request went to the address on file.
  • needs_input Broker replied asking for something before it will proceed (a postal address, DOB, proof of authority, a consumer portal step). Sent, NOT failed, NOT confirmed — awaiting input. Carries a structured `needsInput` so the demand is actionable, not a blob (spec §6).
  • confirmed The broker confirmed it acted. This sets providerAttestedAt, NOT scanVerifiedAt: a broker's word is evidence of what the broker said, never evidence the record is gone.
  • failed The broker received the request and declined it. A decision was made, and it went against us — distinct from `undeliverable`, where no decision was ever made.
  • captcha_required The removal route is gated behind a CAPTCHA the engine will not solve on the subject's behalf.
  • not_removable No statutory removal route exists for this source. Detecting a listing and being able to file against it are separate things, and this is where they diverge.
  • no_records Broker's identity engine found no name+DOB match to suppress. Terminal, and NOT a failure — the scan can still have found the person by name (they match differently).
  • undeliverable The filing never reached the broker: a hard bounce came back for its compliance address (SPEC-BOUNCE-CLASSIFICATION §4). Distinct from `failed`, which means the broker received the request and declined it — a decision that was never made here. Distinct from `pending`, which claims we are awaiting a reply that can never come. Counted in neither `filed` nor `pending`, because "we could not file" must never be reported as "we filed", the same contract `canAssertClean` enforces one layer up.
  • deferred Recorded as owed but not executed, because the removal executor is gated off. An audit row exists so the trail is correct the day it is enabled; nothing was sent.

Two timestamps that are never derived from each other

providerAttestedAt is when a broker told us it had acted. scanVerifiedAt is when we went back and observed the record gone.

Neither is ever computed from the other, and a filing can carry the first for months without the second. A vendor that reports one number cannot tell you which of these it had — and for a compliance claim, that is the only thing worth knowing.

Read the contract Run a response