Evidence program · Updated August 13, 2026
Broker Evidence Roadmap
This page explains how OfflistMe builds an authoritative, updateable data broker knowledge base. Every profile separates provider-published facts, registry context, read-only observations, derived classifications, user-authorized outcomes, and unknown fields.
Current evidence snapshot
1,018
Broker profiles
customer-ready catalog records
150,329
Evidence facts
source-linked facts and observations
803
Registry context
matched public-registry profiles
524
Route observations
read-only web checks
524
Independent routes
route semantics observed
461
Semantics pending
provider URLs needing review
461
Semantic dispositions
read-only classifications; no auto-promotion
33
Failed/recheck queue
independent rechecks pending
493
DNS-checked email routes
mailbox not verified
These counts describe routing and provenance. They do not prove request submission, mailbox acceptance, broker response, deletion, monitoring, or non-republication.
The 461 previously semantics-pending URLs now have explicit read-only dispositions. First-party candidates still require route-role review; cross-domain and processor candidates still require entity confirmation; ambiguous and blocked pages remain manual work.
Prioritized evidence work
The backlog is prioritized by the evidence needed to make a profile useful and safe to cite. It is not a promise to fill every field proactively, especially fields that require a user's own request outcome.
| Priority | Workstream | Scope | Proof required | Boundary |
|---|---|---|---|---|
| P0 | Failed route rechecks | 33 | Independently observe the recorded provider URL and preserve status, redirects, errors, and access blockers. | A failed observation is not proof of provider-wide unavailability. |
| P0 | Route-semantics review | 461 | Review the first-party page to distinguish an opt-out route from a privacy policy, processor portal, or unrelated source page. | A reachable URL is not automatically a canonical submission route. |
| P1 | Workflow detail enrichment | 0 | Record source-backed field purpose, format, jurisdiction, sensitivity, match impact, channels, and prerequisites. | Do not infer exact form requirements from a URL or title alone. |
| P1 | Entity and suppression mapping | 0 | Use official corporate, registry, legal, or provider evidence for legal operator, parent, aliases, brands, and suppression relationships. | Shared domains or email routes do not prove shared ownership or suppression. |
| P1 | Verified contact evidence | 0 | Keep first-party contact provenance and bounded DNS evidence separate from mailbox acceptance. | DNS/MX checks do not prove an inbox exists or accepts a request. |
| P2 | Freshness and provenance | 1,018 | Maintain source-check dates, next verification dates, source URLs, capture methods, and retracted observations for each profile. | A date without a source is not evidence. |
Nine dimensions on every broker profile
A profile is more than an opt-out link. Its evidence matrix tracks whether each dimension is documented, partially documented, unknown, or not recorded.
Entity identity
Dimension-level field coverage is shown on each profile, with source dates and remaining gaps.
Business context
Dimension-level field coverage is shown on each profile, with source dates and remaining gaps.
Regulatory context
Dimension-level field coverage is shown on each profile, with source dates and remaining gaps.
Request workflow
Dimension-level field coverage is shown on each profile, with source dates and remaining gaps.
Contact routes
Dimension-level field coverage is shown on each profile, with source dates and remaining gaps.
Privacy boundary
Dimension-level field coverage is shown on each profile, with source dates and remaining gaps.
Verification
Dimension-level field coverage is shown on each profile, with source dates and remaining gaps.
Catalog metadata
Dimension-level field coverage is shown on each profile, with source dates and remaining gaps.
Source provenance
Dimension-level field coverage is shown on each profile, with source dates and remaining gaps.
What is intentionally not a proactive backlog
User-authorized outcome fields—such as a user-confirmed submission, broker response, case ID, deletion confirmation, or relisting observation—are recorded only when the user explicitly supplies or authorizes the evidence. OfflistMe prepares drafts and routes; users review, send or submit, verify, and follow up.
Verification rules
- Prefer provider-published or official registry sources.
- Keep route reachability, route semantics, mailbox acceptance, delivery, response, deletion, and relisting as separate states.
- Preserve source dates, next verification dates, conflicts, access blockers, and retracted observations.
- Publish only claims supported by the stated source and observation method.