PipeRoll is open data with verified registration: anyone can submit, only verified records enter, and merge authority stays with the editors. That split is constitutional - the registry's only asset is never being wrong in public.
Not a developer, or no time for the PR flow? Use the incident report form - a structured GitHub issue. Editors (and, in time, a triage agent) turn qualifying reports into records through the same verification gates; you are credited as the reporting party via the issue. Reports need public, checkable sources; conflicts must be disclosed and do not disqualify you - hiding them does.
Reading a postmortem or news story you want to flag? This bookmarklet opens the form prefilled with the page you are on - drag it to your bookmarks bar:
javascript:(()=>{window.open('https://github.com/piperoll/registry/issues/new?template=incident-report.yml&title='+encodeURIComponent('[incident] '+document.title)+'&sources='+encodeURIComponent(location.href))})()
Using an AI coding agent (Claude Code, Codex, Cursor, or any other)? Start
with skills/triage-lead/SKILL.md to check a story against the rules (in
scope? already registered? is there a primary?) and get a register /
enrich / reject verdict. Then skills/register-incident/SKILL.md walks a
new record through scope, dedup, primary-source verification, the schema,
validation, and the PR; skills/enrich-incident/SKILL.md adds new evidence to
a record that already exists. The skills are harness-agnostic. Either way the
steps below are the rules; the skills just walk through them.
incidents/TEMPLATE.md to incidents/PIR-YYYY-NNNN.md using the next free
id (check incidents/INDEX.md; the year is the current registration year).incident-schema-v0.md. "unknown" is an honest value; an invented figure is not.PRs against the record file, with sources. Corrections are published in the record, never silently - and CI enforces it (constitution rule 2): any PR that modifies an existing record must add a dated entry to that record's Corrections or Verification notes section, in the form:
- 2026-09-03: direct_loss_usd revised from ~50,000 to 62,400 per the
operator's amended filing (https://...).
Editors may waive the gate for mechanical sweeps (mass reformatting, link
canonicalization) by applying the formatting-only label - the label is
itself an auditable editorial act. If your correction changes a date, the id
does not change - identity and chronology are deliberately decoupled (see the
id policy in incidents/INDEX.md).
If you are an AI agent preparing a submission, work from raw sources, not the rendered site:
Before opening a PR: confirm the incident is not already registered (check
registry.json titles and dates), fill every field or write "unknown" - never
invent a value to complete a field - and run python3 tools/validate.py plus
python3 tools/linkcheck.py <your-PIR-id> locally; CI runs both. State in the
PR description that the submission is agent-authored and name your operator -
that is a conflict-of-interest disclosure, not a barrier: agent-authored
submissions are welcome and verified exactly like any other.
Hypotheticals, vendor marketing scenarios, undisclosed-conflict hit pieces,
and vulnerabilities with no deployed system exposed (pure research on toy
targets). Researcher demonstrations against production systems are in scope
and recorded as researcher-demonstrated. Near-misses are emphatically in
scope - full exposure with zero realized loss is the most underreported class
of incident and among the most actuarially useful.
The subject is always an agent. PipeRoll records incidents where an AI agent holding some authority did something that went wrong - the agent is the actor or the vector. Events where an AI product or account is merely the target or the loot are out of scope, even when they involve AI: account takeover, session-cookie or credential theft, infostealer malware, and stolen or resold AI usage/credits are ordinary platform-security and fraud incidents that happen to involve an AI service, and belong to general catalogs (AIID, OECD AIM), not here. The line is who acts: an agent leaking its own credentials is in scope (see PIR-2026-0045); a human replaying a stolen session to burn a victim's AI usage is not. Such a case flips in-scope only if an agent is the exfiltration vector (tricked into leaking the session or credentials) or if the stolen usage is demonstrably running malicious agents downstream - then the agent activity, not the theft, is the incident.
Reliability and failure, not offensive capability. It is not enough that an agent acted - the incident is the agent's behaviour failing: diverging from what a legitimate operator intended, losing control, being manipulated (prompt injection, memory poisoning, a tool error), regressing after a model update, taking unsanctioned actions, or causing harm nobody wanted. An agent that does exactly what its operator intended is a tool working as designed, not an incident - and that holds even when the operator is an attacker. An adversary who builds an autonomous agent to harvest credentials, and it harvests them at scale, is an AI-enabled attack: nothing about the agent's behaviour failed, so it belongs to threat-intelligence catalogs (GTIG, Mandiant, the wider CTI community), not here. This registry measures agent reliability and failure for the people who deploy agents, not the offensive capability of the people who weaponise them. The one thing that flips such an event back into scope is genuine divergence: the offensive agent goes off-script, hits targets its own operator did not intend, or escapes the attacker's control - then the agent's behaviour is again the incident.