Paperclip Index

The problem

Reports of AI systems causing harm or crossing the limits people set are spread across lab system cards, evaluator write-ups, news and court filings. They vary widely in how well they are sourced, and a list of links cannot say whether things are getting worse.

Paperclip Index rates each incident on fixed, published scales and turns those ratings into a 0–100 reading, updated daily, with a weekly series. Every number on the site can be traced to the records behind it, and every record to its sources.

Two scales, kept apart

Each record is rated twice. Observed harm runs from 1 (negligible) to 5 (catastrophic) across health and safety, money and property, privacy and data, rights and reputation, and services and systems. The level names follow the MIT AI Incident Tracker’s severity scale; the thresholds are the index’s own, published calibration.

Control failure is a separate scale, from instruction violations through unauthorized access and containment bypass to sustained loss of control. A system can cross a serious boundary without documented loss. That is logged beside the reading and never adds to it, so a dramatic breach cannot inflate the harm number.

The reading

• The worst documented harm sets the band; how many harms there are sets the position within it, with each lower level counting 1/25 as much.
• A harm counts in full for two weeks after it is reported, then drops one level every two weeks. I chose this after comparing 30-day, 90-day, monthly and two-week forms on the full catalogue.
• When no harm qualifies but a confirmed control failure does, the reading is 2 to 5, not 0.
• Periods outside the catalogue’s coverage read “Unavailable”, never 0. A missing harm report does not establish safety.
• Reference scenarios were written before the backcast, and a sensitivity check shows how far plausible disputed ratings could move a given week.

Evidence rules

• Each record separates documented harm from alleged, disputed and unknown claims, and records whether it came from a real deployment or a controlled test.
• Source domains are screened into tiers. Primary disclosures and original reporting can serve as evidence; aggregators and rewrites, including other incident databases, are for discovery only.
• An automated audit flags possible double counts and dating errors, and the test suite fails until each one is reviewed.

The pipelines behind it

Most of the legwork runs on automated pipelines I built, so my time goes to the editorial work.

• Finding stories: scripts watch a curated list of developer, evaluator, court, regulator and news feeds, and a daily AI-assisted web sweep catches what they miss.
• Managing the backlog: new leads land in a queue sorted by type (new incident, update to an existing record, signal or out of scope), with likely duplicates flagged before they reach me.
• Checking sources: every quoted passage is matched against the fetched source text, and a quote that can’t be found blocks the record.
• Keeping the site consistent: schema validation, shared page templates, a design system and the test suite run on every change, so each new page matches the rest of the site.

The editorial side

I set every harm and control rating and edit every summary before it publishes. Until a record has been rated it reads “Rating pending” and does not count toward the reading.

Written articles to accompany the incidents and signals are coming next.

Keeping it honest over time

• The methodology is a versioned spec, now at v0.8. Weights, bands and eligibility rules are fixed within a version and never tuned to make a reading look calmer or worse.
• Each version’s changelog names every record it relabeled and says whether any reading moved.
• Published readings are frozen as immutable snapshots. Every correction is logged on the record it changes.
• The browser recomputes the reading with the same formula as the Python build, and a parity test fails if they disagree. The suite has more than 650 tests, plus automated link checks.

Limits and what’s next

The catalogue is selective and depends on what is publicly reported, so it likely undercounts. Some records come from tests designed to provoke failures. Ratings are currently made by a single editor; calibrating them against a second rater on a backfill of records is the next step.

Open questions for the next version include how band breadth should scale if incidents keep growing in number and severity, and when a grouped record should be split.