CORRECTIONS
Challenge a claim.
Bring evidence.
CCLR is review-gated but not immutable. Corrections should identify the exact record or claim and provide evidence strong enough to justify changing canonical data.
What to report
- the program, provider, relation, event, or evidence record involved;
- the specific statement or state you believe is wrong or incomplete;
- the proposed correction;
- primary, regulatory, forensic, on-chain, or otherwise independently verifiable evidence;
- dates or lifecycle boundaries when relevant.
Review rule
A correction does not overwrite history simply because a newer state exists. Where the evidence describes a later lifecycle change, the registry should normally add a new event or close a time-bounded relation rather than rewrite the earlier state away.
Provider-wide evidence is not sufficient by itself to assign affected or unaffected status to every connected program.
Public route
Open a repository issue with the record ID or canonical name in the title and attach the evidence supporting the correction.
Open correction issue ↗Do not submit secrets, private keys, private customer data, or other sensitive material. Public corrections should rely on evidence that can safely be reviewed and cited.
Publication boundary
Research notes and monitoring leads are not canonical publication data. A correction becomes public registry data only after the supporting evidence and record boundaries are reviewed and validation passes.