Correction channel

Data correction and withdrawal

Report an incorrect registrant, curated claim, privacy issue, or data-rights concern with the relevant source and evidence. A request does not automatically change the public result.

The correction intake channel is not configured for this deployment.

Even if the application appears healthy, this fails the production launch gate. No fake form is shown that pretends to accept a request.

  1. 1

    Identify the record

    Provide the relevant MAC or prefix, source name, and the exact claim shown on screen.

  2. 2

    Explain the request and its basis

    Include the requested correction, a verifiable reference or evidence link, and contact details needed for a response. Do not send passwords, private keys, or unnecessary personal data.

  3. 3

    Review and temporary action

    The target for initial human review is 2 business days; the normal decision target is 10 business days. Clear personal-data, security, or severe misattribution reports enter a 24-hour temporary suppression review queue.

  4. 4

    Auditable decision

    A request may be rejected with reasons, corrected through a new source release, handled with temporary or permanent suppression, or escalated for rights/privacy review.

Immutable record policy

Source and resolution release rows are never retroactively mutated. Emergency visibility changes use ticket-referenced suppression; permanent data changes use a new release. Every decision produces an audit trail.

Security reports use a separate channel

Do not send application vulnerabilities or credential leaks to the correction address. Use the private security advisory channel instead.

Process details should be read together with the data terms and the active data release.