About

A registry for bridge incident aftermath.

Bridge Incident Registry records historical bridge incidents, source-backed outcomes, unresolved questions, and lifecycle changes after incidents.

Not a safety ranking

BIR does not recommend bridges, rank bridge safety, or provide investment advice. It records historical claims and outcomes with source attribution.

Purpose

Why this registry exists

Most incident lists focus on the exploit. BIR focuses on what happened after.

Aftermath tracking

Pause, recovery, reimbursement, reopening, migration, shutdown, and final outcome are tracked as first-class records.

Evidence-first

Major claims should point to source material, with uncertainty and conflicts preserved when sources disagree.

Static public archive

The first version is a static site backed by reviewed JSON files, not a live monitoring dashboard.

Limits

What BIR does not do

Clear limits keep the project useful and safer to publish.

No rankings: BIR does not score or rank bridge safety.
No recommendations: BIR does not advise users to use or avoid a bridge.
No exploit reproduction: BIR does not publish operational attack steps or reproduction instructions.
No private data: Reports should not include private keys, seed phrases, passwords, or personal financial information.
No unsupported allegations: Claims require source material or must be marked as unresolved/unknown.

Corrections

Correction and report flow

BIR should become more accurate over time without accepting unverifiable claims.

What to report: Wrong status, missing evidence, broken source URL, duplicate record, better archive link, or outdated recovery/reimbursement outcome.
What to include: Record name, exact claim to change, source URL, archive URL if available, and a short explanation.
What not to include: Private keys, seed phrases, passwords, personal account data, or non-public allegations.
Review result: Accepted changes should update the relevant JSON record and appear through a reviewed pull request.

Contact

For now, corrections should be filed through the project repository or the public contact/report form when available. Every accepted correction should leave a visible source-backed trail in the registry data.