Most people who notice an error in a record do not report it — because reporting looks like effort with uncertain return.
Which means every report received should be treated as a sample of a larger population, not as an isolated incident.
Making reporting easy
- A visible route on the record itself.
- No account required where the claim is independently verifiable.
- A short form, not a lengthy one.
- Acknowledgement with a reference the reporter can follow.
- A stated response time, and meeting it.
- Friction in reporting is friction in finding errors.
Triage
- Distinguish factual corrections from disputes.
- Distinguish record errors from source errors — the latter must be reported upstream.
- Prioritise by downstream impact.
- Route authorship disputes to publishers, since they are not registry decisions.
- Set expectations about timing when triaging.
Verification
- Verify even sympathetic claims — the process protects everyone including the reporter.
- State what evidence is needed for each claim type.
- Record what was accepted.
- Where a claim cannot be verified, say so rather than declining silently.
Treating each report as a sample
- Ask whether the same cause affects other records — it usually does.
- One bad affiliation may indicate an unresolved institution variant affecting hundreds.
- Fix the cause, then sweep the affected set.
- Track categories over time to find where the pipeline is weakest.
Closing the loop
- Tell the reporter what was done.
- Log the correction with previous values retained.
- Propagate to the API immediately.
- Notify bulk consumers where aggregates were affected.
- Reporters who see results report again; those who see nothing do not.
Publishing the statistics
- Volume, categories and response times.
- Notable systematic corrections and their causes.
- This builds trust rather than undermining it — a registry reporting no corrections is not error-free, only closed.
One thing worth remembering
Treat every error report as evidence of a class of error, not a single instance.
The person who reported it is the exception. Behind their report there are usually many identical errors that nobody thought worth mentioning — and finding those is where the value of the report actually lies.
Câu hỏi thường gặp
Why treat reports as samples?
Because most people who notice an error do not report it — so each report received represents a larger population of unreported errors.
How is reporting made easy?
A visible route on the record, no account required where independently verifiable, a short form, acknowledgement with a reference, and a stated response time that is met.
How should reports be triaged?
Distinguish factual corrections from disputes and record errors from source errors, prioritise by downstream impact, and route authorship disputes to publishers.
What does closing the loop involve?
Telling the reporter what was done, logging the correction with previous values retained, propagating to the API immediately, and notifying bulk consumers where aggregates changed.
What is the real value of an error report?
Finding the class of error behind it — the reporter is the exception, and there are usually many identical errors nobody thought worth mentioning.
