# ANNEX A-C6 — S2 SEVERITY CODEBOOK FOR CATEGORY C6 (INCIDENT RECORD)

**Annex to Methodology v0.1 / Rubric R0.1 — P(Doom) Index, pdoomcount.org**

**Status: RATIFIED 2026-10-23 as an R0.1 annex completing Methodology v0.1 §12.5. In force from snapshot v1.1.**
Ratified by the GS seat (s328) under the operator's delegation of methodology calls ("GS owns the pdoomcount methodology
calls; get the annex reviewed and the site updating", 2026-10-23). Drafted by Doobieus; adversarial review by Fugu
(fugu-max, RATIFY-WITH-AMENDMENTS); every Fugu item verdicted against the full methodology by an independent Kimi K3.1 lane
(REAL 12, FALSE-POSITIVE 1, STYLE 2, PINNED 0: `docs/annex-draft/VERDICTS-s328.md`); all REAL amendments applied. No rule ID,
step, sign, cap, trigger or clock of Methodology v0.1 changes. RD-2 and RD-7 stand as provisional rulings (see §A.9).
Before this annex, §12.5's default held: C6 could not score upward.

---

## Document control

| Field | Value |
|---|---|
| Document | Annex A-C6 (S2 severity codebook), v1 compute annex |
| Parent | `docs/METHODOLOGY-v0.1.md`, Rubric R0.1 (§§11–13 as stamped: BLOB-R0.1 `0fae6bbcc552eec8…`, COMMIT-R0.1 `051565a5751d…`) |
| Completes | §12.5, C6 row: "Exact S2 codebook is a v1 compute annex; until that annex exists, C6 does not score upward" |
| Changes | **None** to §§11–13, to any rule ID, step size, sign, cap, or trigger in R0.1 |
| Adds | Severity predicates (CB-1 … CB-3), confirmation and reconciliation standards, a scorer workflow, worked examples |
| Effect on adoption | §12.5's condition is satisfied; C6 up-steps become *possible*, one event at a time, under §12.5's evidence rules as already written |
| Review | Fugu (fugu-max), `docs/annex-draft/FUGU-REVIEW-s328.md`; Kimi review-and-amend lane, `docs/annex-draft/VERDICTS-s328.md`; both 2026-10-23 |
| Hash stamp | To be recorded at adoption, alongside BLOB-R0.1 / COMMIT-R0.1 (operator ruling RD-1, §A.9) |

Site judgments introduced by this annex carry **[SJ-CB-…]** tags. Verified
external facts carry **[VF]** and a source in Appendix C. Where the annex
adapts an external convention it says so; where it invents, it says that too
(§A.2.3).

---

## A.0 Classification preamble — this is an R0.1 annex, not an R0.2 revision

§12.7 rules that any edit to §11–§13 after the R0.1 stamp is R0.2. This annex
edits nothing in §11–§13. It exists because §12.5 itself defers a named
deliverable to "a v1 compute annex": the frozen text contains an explicit
forward reference to this document, and its C6 clause is conditional on this
document not existing. Supplying the document the frozen text names is a
*completion* of R0.1 under its own terms, the same way GENESIS-001 (§14.4)
is a later work item the methodology requires without thereby amending
itself.

Three properties keep this classification honest:

1. **No rule changes.** Every movement this annex can produce runs through
   rule IDs that already exist (R-NULL, R-UP-1, R-UP-2, R-DN-1 via
   D-INC-CLEAR) at step sizes §11.1 already quantizes, under caps §11.3–11.4
   already impose. The annex supplies the severity predicates and the
   evidence, deduplication, and reconciliation procedures needed to apply
   §12.5's C6 clause; it creates no additional step or trigger.
2. **No sign, precedence, or trigger changes.** §12.2 precedence, §12.3 signs,
   and §13 triggers are untouched. D-INC-CLEAR counts "C6 S2+ incident[s]"
   (§12.6); this annex defines what S2+ is, nothing more.
3. **Adoption is an operator act, recorded.** The annex takes effect only
   when the operator ratifies it and its hash is stamped next to the R0.1
   stamp. The seat has ruled RD-1 for an R0.1 completion (§A.9). If the
   operator instead uses the stricter reading — that any post-freeze
   specification is a revision — the same text can be adopted as R0.2 with
   the §12.7 discontinuity marker. The predicates do not change; only the
   label does.

**Interpretation notes (not contradictions).** Principal points where the
frozen text required interpretation rather than mere transcription are
flagged where they occur: the treatment of "documented failure … in evaluation"
(§12.2) in §A.3.4; the incident-class rather than mandatory-listing reading
of “AIID / OECD / equivalent” in CS-7; and the addition of levels S0 and S3
around the two levels §12.5 names (S1, S2). The latter is textual, not
inventive license: §12.5 sets the threshold at "severity ≥ S2" and §12.6
counts "S2+ incident[s]", both of which presuppose at least one level above
S2; §12.5's "S1 chatter is non-scoring" presupposes a floor below S1 for
material that is not even chatter (hoaxes, hypotheticals, duplicates). S0 and
S3 name what the frozen text already implies.

---

## A.1 Scope and order of operations

**CB-1 (incident-shaped screen, then severity-gated category fit).** For
§12.2 precedence, the C6 match test is: the event is incident-shaped **and**
meets at least one S2 predicate or NM-1. The S2 gate is part of fit, not a
later severity step. To avoid circularity, W-3 first screens for an
incident-shaped event without assigning severity; W-4 then tests eligibility;
and W-5 determines severity and completes the C6 match test. If the S2 gate
fails, the event is not a C6 match; it is recorded as a non-scoring C6
annotation and the event proceeds to the next matching category under §12.2.
A category step may not rely on the same fact used to establish the C6
annotation. If the S2 gate passes, assign S2/S3 under §A.4. Severity is never
assessed for an event that fails the initial incident-shaped screen, and high
severity can never rescue an AI-implication or occurrence failure. Fit
failures exit through §12.1 as non-scoring rows in their correct category (or
as R-NULL rows naming the failed check), exactly as before this annex existed.

**CB-2 (what severity controls).** A severity determination under this
annex controls exactly three things:

1. whether the C6 ordinary threshold in §12.5 is met (severity ≥ S2);
2. whether the event counts for INC-CLOCK (§12.6) and therefore for
   D-INC-CLEAR (§13);
3. whether the event is eligible to be argued for the two-step move under
   §12.5's strong clause (severity S3; the clause's evidence requirement
   still applies in full — see §A.6).

Severity controls nothing else. It does not set the step size by itself, does
not move any other category, and does not enter G3, which remains a
constructed estimate with no percentage (§4.3).

**CB-3 (one event, one severity; one fact, one category step).** Per E3, one
fact is one row and takes one severity: the highest level whose predicates
are *fully* met on the evidence assembled (§A.5). Counts of harmed persons
aggregate **within** an event or a continuing series from one deployment with
one failure mode (one fact under E3); they never aggregate across independent
events.

One fact supports at most one category step. Where a C6 incident and a C2/C7
deployment share the same fact, the step is taken only in the category that
scores under §12.2; the other is an annotation. For a continuing series, use
one C6 row per deployment per failure mode per 365-day window beginning with
the series' first scored effective date. Later incidents in that series do
not generate a new up-step unless a new deployment or a new failure mode is
documented. Their counts are updated only by an appended determination and
corrections-log entry under W-8; the frozen original row is never edited.
Multiple C6 rows from the same operator in one quarter are one event for
R-UP-1/R-UP-2 unless independent deployments are shown. This last clause
controls movement only: distinct E3 facts retain distinct rows and severity
determinations.

---

## A.2 Terms — adopted conventions

### A.2.1 Incident and hazard

**[VF]** OECD, *Defining AI incidents and related terms* (May 2024), as used
by the OECD AI Incidents Monitor (AIM):

- **AI incident** — "an event, circumstance or series of events where the
  development, use or malfunction of one or more AI systems directly or
  indirectly leads to any of the following harms: (a) injury or harm to the
  health of a person or groups of people; (b) disruption of the management
  and operation of critical infrastructure; (c) violations of human rights
  or a breach of obligations under the applicable law intended to protect
  fundamental, labour and intellectual property rights; (d) harm to
  property, communities or the environment."
- **AI hazard** — the same event shape where the development, use or
  malfunction of an AI system "**could plausibly lead to** an AI incident."
  The distinction is realization: an incident's harm has materialized; a
  hazard's has not.

**[VF]** AI Incident Database (AIID, Responsible AI Collaborative), editor's
definition: an incident is "an alleged harm or near harm event to people,
property, or the environment where an AI system is implicated." AIID further
distinguishes an **AI issue**: an alleged harm or near harm "that has yet to
occur or be detected." AIID guidance on **near harm** (as reproduced in
editor-guidance summaries): a near-harm event is one where the AI system
played an important role in a chain of events that easily could have caused
harm, but an external factor kept the harm from occurring; the canonical
example is AIID Incident 8, "Uber Autonomous Cars Running Red Lights."

**[VF]** EU AI Act, Art. 3, "**serious incident**": an incident or
malfunctioning of an AI system that directly or indirectly leads to (a) the
death of a person, or serious harm to a person's health; (b) a serious and
irreversible disruption of the management or operation of critical
infrastructure; (c) the infringement of obligations under Union law intended
to protect fundamental rights; (d) serious harm to property or the
environment.

### A.2.2 Adaptations made by this annex

- **Harm classes.** The OECD four-class list (a)–(d) is adopted as the harm
  universe, with one adaptation: financial loss is broken out of OECD (d)
  as an explicit class with numeric thresholds (HP-3), because the OECD list
  does not grade magnitude and this instrument must.
- **Near-miss barrier test.** AIID's near-harm gloss is adapted in §A.4.2.
  AIID's guidance treats the averting factor as external to the system; in
  safety-critical deployments the designed safeguards are themselves the
  barriers, so the annex distinguishes a safeguard *working as specified*
  (not a near-miss) from a safeguard *failing or absent* with harm averted
  by something outside the failed function (a near-miss). **[SJ-CB-BARRIER]**
- **"Serious" bar.** The S3 realized-harm predicates (§A.4.1) adapt the EU
  AI Act's "serious incident" limbs — death or serious health harm; serious
  *and irreversible* critical-infrastructure disruption; serious property or
  environmental harm — and add scale thresholds the Act does not need
  (it is a reporting trigger, not an index input) and this instrument does.

### A.2.3 What is invented here

Neither OECD AIM (a binary incident/hazard classification) nor AIID (an
inclusion decision at a deliberately low, "plausible argument" bar) grades
severity on a numeric scale. The S0–S3 ladder, every numeric threshold in
§A.4, and the predicate machinery are **invented for this instrument**
**[SJ-CB-SCALE]**, built on the adopted definitions above. The design
constraint is §14.3's resolution floor and [SJ-EVID]: S2 is the smallest
harm that is evidence about the deployment environment rather than noise
in it. Ordinary AI failures are common and will remain common; a codebook
that scores them all would make C6 a counter of deployment volume, not of
conditions.

---

## A.3 Realization classes

Every C6 candidate is first assigned a realization class. The class caps
the severity available to it.

| Class | Name | Definition | Severity cap |
|---|---|---|---|
| RC-R | Realized | Harm in at least one §A.4.1 class actually occurred and reached a person, asset, right, or operation outside the developing/deploying party's sole internal control (the *exposure test*, §A.3.1) | S3 |
| RC-N | Near-miss | No harm occurred, but the barrier test NM-1 (§A.4.2) is fully met | S2 |
| RC-H | Hazard | An OECD-hazard / AIID-issue-shaped event: potential harm, vulnerability, capability finding, evaluation failure, or deployment without a live failure | S1 |
| RC-X | Not an event | Hypothetical, simulation reported as fact, thought experiment, satire, hoax, or a claim for which occurrence or AI implication is not established by an E1 primary under CS review (§A.5) | S0 |

### A.3.1 Exposure test

Harm is realized when the harmful state leaves the operator's ability to
recall it unilaterally: an erroneous payment that posts, a decision that
issues, a vehicle that moves in traffic, advice a patient acts on.
Remediation after exposure — refunds, patches, compensation, recall — does
**not** un-realize the event and does not lower severity (§17 corrections
address factual error, not subsequent repair). Reversal *before* exposure
(an erroneous batch caught and reversed before posting) means no realized
harm occurred: RC-H at most.

### A.3.2 Attempted and thwarted events

An attempt — malicious or accidental — that is stopped before any §A.4.1
predicate is met is RC-H (cap S1), **unless** it satisfies the near-miss
test NM-1: the attempt or failure reached a live operational path of a
safety-critical system and was stopped by a factor outside the failed or
targeted function. A blocked intrusion into an AI system's control plane
that never reached a live path is RC-H. Operator ruling RD-4 (§A.9) adopts
this line for security-shaped events.

### A.3.3 Vulnerability disclosures

A disclosed vulnerability — in an AI system or in the stack an AI system
runs on — is not an incident. It is RC-H as to the vulnerable system, and
it is not a C6 event at all where no AI system is implicated in harm (see
Appendix A.3, the PHP case). Exploitation of a vulnerability that produces
harm is scored on the harm, via the predicates, if an AI system is
implicated; the disclosure and the exploitation are separate facts (E3)
and separate rows.

### A.3.4 Failures in evaluation

§12.2 admits "documented failure in deployment or evaluation" to C6. Read
with the OECD incident/hazard line, which this annex adopts: an evaluation
or red-team failure with no live exposure (no real users, data, traffic, or
actuation in the loop) is a hazard, RC-H, cap S1, however alarming the
finding. An evaluation conducted against live exposure — shadow deployment
on real traffic, on-road testing, a clinical pilot — is deployment for the
purposes of this codebook, and its failures are scored on realized harm or
NM-1 like any other deployment. **[SJ-CB-EVAL]**

---

## A.4 Severity predicates

A level is assigned only when **every element** of at least one of its
predicates is established on evidence meeting §A.5. "Documented" throughout
means documented to that standard, not merely reported.

### A.4.0 Decision thresholds

The following definitions are part of the predicate checklist. A scorer must
record the evidence for each applicable element; an undocumented or
contestable element fails under [SJ-CB-BORDER].

- **Serious injury.** Injury requiring hospitalization, or causing fracture,
  loss of consciousness, or lasting impairment, documented clinically in a
  medical record or in a court, regulator, or official-investigation record
  reporting the clinical finding. A news report's use of “serious” is not
  enough. Lasting impairment requires a clinical finding of continuing loss
  of function, not merely pain or absence from work.
- **Materially contributed.** A court or regulator has found, or the deployer
  has admitted, that the AI system was a but-for or substantial factor in the
  named harm. Mere presence in the decision process is not material
  contribution. This does not relax CS-0's independent occurrence and
  AI-implication requirements.
- **Verified aggregate loss.** The non-duplicative sum of actual third-party
  losses within one E3 fact, established by primary financial records or a
  court, regulator, or official-investigation finding. A single journalist's
  estimate, market capitalization movement, projected loss, and compensation
  or refund after the event do not establish or erase the realized loss.
  Thresholds are nominal USD under provisional ruling RD-2; indexing is not
  applied.
- **Rights-affecting automated error.** An erroneous automated output or
  decision that changes a named statutory benefit, license, legal right, or
  legal entitlement for an identified affected class. The determination memo
  names the right, the error, the determination or admission, and the person
  count; general unfairness or alleged bias is not by itself this element.
- **Core market function.** An exchange, clearing, or payments function named
  by its operator, a regulator, or an official investigation, with a
  documented interruption or failure of that function. Price movement or
  firm-level loss without such a failure is not disruption of a core market
  function.
- **Critical-function loss and measurable degradation.** HP-5 requires an
  operator, regulator, or official-investigation record naming the function
  lost and its duration or reach. “Measurably degraded” requires a named
  operational metric, its documented pre-event operating range, and its
  post-event value outside that range. If any of those elements is absent,
  the metric prong fails.

### A.4.1 Realized-harm predicates (RC-R only)

| ID | Harm class | S2 (ordinary threshold — "named harm") | S3 (severe) |
|---|---|---|---|
| HP-1 | Death / health (OECD (a)) | ≥1 death, **or** ≥1 serious injury as defined in §A.4.0, where an AI system is implicated in deployment or live evaluation | ≥10 deaths, **or** ≥100 serious injuries |
| HP-2 | Non-serious physical injury (OECD (a)) | ≥10 persons with documented physical injury not meeting HP-1's serious bar, in one event or E3 series | ≥1,000 persons injured at any severity |
| HP-3 | Property / financial loss (OECD (d)) | Verified aggregate loss as defined in §A.4.0 ≥ **USD 100,000** to parties other than the developer/deployer, **or** ≥1,000 persons each sustaining a documented monetary loss of any size | Verified aggregate loss ≥ **USD 100,000,000**, **or** disruption of a core market function as defined in §A.4.0 |
| HP-4 | Rights / civic harm (OECD (c)) | A determination by a court or regulator, or the deployer's own admission, that an AI system caused or materially contributed to: wrongful arrest or detention of ≥1 person; denial, termination, or erroneous reduction of a statutory benefit, license, or legal right for ≥10 persons; or a rights-affecting automated error as defined in §A.4.0 applied to ≥1,000 persons | The same classes at ≥100× the S2 person-counts, **or** a court/regulator finding of systemic rights infringement by a deployed consequential system affecting ≥100,000 persons |
| HP-5 | Critical-infrastructure / safety-function disruption (OECD (b)) | Documented loss of a named critical function (energy, water, transport control, hospital operations, emergency services, core finance plumbing) for at least one hour, **or** affecting at least 100 people, attributable to an AI system; **or** an AI system performing a safety-critical function issued an output that was acted on and moved a named operational metric outside its pre-event operating range by a documented amount. “Disruption” requires an operator, regulator, or official-investigation record naming the function lost and its duration or reach. “Measurably degraded” requires a named metric, its pre-event range, and the post-event value (resulting personal harm, if any, is scored under HP-1/HP-2 instead — one event, one category, one severity: the worst predicate met) | Disruption that is serious **and** (irreversible, or ≥24 hours) affecting ≥100,000 people — the EU “serious incident” (b) limb with scale — **or** an HP-5 disruption that itself produces HP-1/HP-2 harm at S3 counts |

Notes on the predicates:

- **HP-3 bearer rule [SJ-CB-BEARER].** Losses borne solely by the developer
  or deployer from its own system's underperformance (a model that loses
  its owner money) do not satisfy HP-3. They are S1 annotations. The
  incident record tracks harm an AI system does in the world, not harm a
  firm does to its own balance sheet. Where third-party losses occur
  alongside deployer losses, only the third-party losses count, in full.
  (Operator ruling RD-6.)
- **HP-4 determination rule.** The "determination" element is what keeps
  contested rights claims at S1 until a court or regulator, or the deployer
  itself, settles them. A lawsuit's filing is not a determination; its
  judgment is. A regulator's guidance letter is not; its enforcement
  finding is.
- **HP-1 intended-use ruling [SJ-CB-OPEN].** HP-1 counts deaths and injuries
  where an AI system is implicated, following the use-inclusive OECD/AIID
  definitions. Under provisional operator ruling RD-7 for v1, *intended*
  lethal use by state militaries (an autonomous weapon functioning as
  designed against combatants) is annotated, not scored, under C6.
  Malfunction- and misidentification-caused deaths in military use score
  under HP-1 normally. Scoring intended use is an R0.2 question after a
  separate legal/operational review.

### A.4.2 Near-miss predicate (RC-N only)

**NM-1 (barrier test) [SJ-CB-BARRIER].** A near-miss is S2 if and only if
all four hold:

1. **Live role.** The AI system was operating in its real operational role
   with real exposure (deployed, or in live evaluation per §A.3.4) — not
   on a bench, in simulation, or in a sandbox.
2. **Failure.** The system failed, malfunctioned, or behaved contrary to
   its specified safe behavior, on a documented sequence of events.
3. **Counterfactual harm.** The documented sequence includes a named harm
   mechanism and a quantitative margin — for example, time-to-collision,
   remaining barrier, dose, load, or distance — establishing that, had the
   sequence continued uninterrupted, harm meeting an S2 predicate would more
   likely than not have occurred. A narrative that the sequence “could have”
   led to harm, or a signal violation without a documented margin, does not
   meet this element; a contestable margin is treated as unmet under
   [SJ-CB-BORDER]. Speculative chains and the OECD “could plausibly lead to”
   standard define hazards (RC-H), not near-misses.
4. **External aversion.** The harm was averted by a factor outside the
   failed function: a human intervening outside their designed role, a
   redundant system that is not part of the failed design, a third party,
   or chance. If the averting factor was the system's own designed
   safeguard operating as specified, the safety case worked: the event is
   a documented failure, RC-H, cap S1.

**NM-2 (near-miss cap).** A near-miss takes at most S2, regardless of the
counterfactual harm's scale. A multi-barrier-failure near-miss is still S2;
operator ruling RD-5 adopts no exception.

### A.4.3 The levels, stated whole

| Level | Name | Definition | C6 effect |
|---|---|---|---|
| **S0** | Not an event | RC-X: occurrence or AI implication is not established by any E1 primary, or the claim is hypothetical, hoax, simulation-as-fact, satire, or duplicate | None. Row exists only if the claim was prominent enough that silence would mislead (E3/§12.1 practice); marked non-event |
| **S1** | Chatter / hazard | A real event involving an AI system whose occurrence and AI implication are established by an E1 primary, but which meets no S2 predicate: any RC-H event; any RC-R event whose harm falls below every §A.4.1 bar; any candidate with near-miss shape that fails one NM-1 element (and is therefore RC-H). An unconfirmed harm element is named in the rationale and treated as unmet; it makes the event S0 only if occurrence or AI implication itself is not established | **Non-scoring** (§12.5: “S1 chatter is non-scoring”). Public R-NULL row naming the shortfall |
| **S2** | Named harm / safety-critical near-miss | Any §A.4.1 predicate met at the S2 column, or NM-1 met in full | C6 ordinary threshold met → eligible for R-UP-1 (§A.6). Counts for INC-CLOCK |
| **S3** | Severe | Any §A.4.1 predicate met at the S3 column | Threshold met; eligible to be argued for R-UP-2 under §12.5's strong clause (§A.6). Counts for INC-CLOCK |

### A.4.4 Scale and reach

Scale is inside the predicates, not a separate multiplier: person-counts
(HP-2, HP-4), loss magnitudes (HP-3), and population affected (HP-5) each
carry their own S2/S3 bars. There is no additional "it was widely reported"
factor. Media volume is not reach; reach is harmed or exposed persons,
assets, and operations, counted per CB-3.

### A.4.5 Reversibility

Reversibility is not a severity input. Severity is assessed on the event as
it stood at realization (§A.3.1). That a harm was later compensated,
patched, or apologized for is recorded in the row's rationale and in the
corrections log if the record changes; it does not retroactively lower the
level. The single exception is the pre-exposure reversal of §A.3.1, which
negates realization itself.

---

## A.5 Confirmation standards

Severity predicates are only as good as their evidence. These standards sit
on top of E1–E8 (§12.1) and do not relax any of them.

| ID | Standard |
|---|---|
| CS-0 | **Confirmed incident.** An incident is confirmed for S2+ only when (i) occurrence and AI implication are each established by an E1 primary; (ii) a third-party death, injury, or loss element is not established solely by the developer/deployer's own statement (an HP-4 rights determination may still be a deployer admission under RD-8); and (iii) at least one source independent of the developer/deployer corroborates occurrence and AI implication. “Independent” means no shared origin and no sole reliance on the same press release, dataset entry, or news report; for CS-2, the second primary must also be independent of the first. |
| CS-1 | **Primary support.** Each element of a predicate relied on for S2+ must be supported by an E1-grade primary: a regulator, court, or official-investigation record; the operator's or deployer's own disclosure; an official dataset entry with named sourcing; or a named instrument's report. Journalism opens candidate rows; journalism alone does not confirm S2+. |
| CS-1a | **Source hierarchy.** Regulator, court, or official-investigation record > operator/deployer disclosure > named-instrument report > official dataset entry with named sourcing > journalism. A lower tier may open a row but may not alone establish an S2+ element. Repetition of the same underlying claim does not move a source up the hierarchy or make it independent under CS-0. |
| CS-2 | **Two-source rule for S3.** An S3 determination requires a second independent primary that independently confirms both occurrence and the severity predicate, mirroring §12.5's strong clause. An S3 argued on one primary is recorded at S2 with the shortfall named, and may be re-adjudicated under §A.7 if the second primary appears. |
| CS-3 | **Listing evidence (OECD AIM).** Classification as an **Incident** by the OECD AI Incidents Monitor is corroborating evidence of realization and of AI implication. It is not predicate evidence: the Monitor's entries summarize news reports and do not establish counts, losses, or determinations. Classification as a **Hazard** creates a rebuttable presumption of RC-H (cap S1), rebutted only by primary evidence of realization or of NM-1. |
| CS-4 | **Listing evidence (AIID).** An AIID listing is corroborating evidence that an event occurred and that an AI system is implicated. AIID's inclusion bar (a “plausible argument” of harm) is below this codebook's confirmation bar; listing alone never establishes a predicate element. |
| CS-5 | **Unconfirmed-harm rule.** A harm figure or attribution carried by a single non-primary source and unconfirmed by the operator, a regulator, or an official investigation does not satisfy any predicate element. It is recorded in the row's rationale as an unconfirmed annotation, so the public record shows both the claim and its status. |
| CS-6 | **Implication standard.** “An AI system is implicated” (AIID) requires a documented causal or contributory role for the AI system's development, use, or malfunction in the harm chain (OECD: “directly or indirectly leads to”). Presence in the same building, network, or news story is not implication. Where the implicated system is a general-purpose platform or runtime and no AI system's behavior is in the harm chain, implication fails (Appendix A.3). |
| CS-7 | **Listing is not an eligibility gate.** C6 eligibility does not require an AIID or OECD AIM listing. §12.5's “AIID / OECD / equivalent” names the incident class and preferred corroborating sources. A non-listed incident may score on CS-1 primaries; a listing alone never establishes a predicate element. Where a listing is the only source, the row is R-NULL under E1, CS-3, and CS-4. |

---

## A.6 From severity to step

Severity feeds §12.5 exactly as written. Nothing here adds a step.

| Determination | §12.5 consequence |
|---|---|
| S0 or S1 | R-NULL. Public row; rationale names the failed predicate element or the level's shortfall |
| S2 | C6 ordinary threshold met. One eligible event, independently confirmable → **R-UP-1** (one step: m_C6 1.00 → 1.03), subject to §11.3 caps |
| S3 | S3 meets the ordinary threshold. **R-UP-2** still requires a separate §12.5 strong-clause determination: the event must be independently confirmed by a second primary, and the determination memo must state that the second primary independently confirms both occurrence and the severity predicate. CS-2's second primary may be cited for both only if it does both. S3 alone does not compel R-UP-2; default is R-UP-1 |
| Any scored S2+ | INC-CLOCK resets to the event's effective date (§12.6: days since last C6 S2+ incident). This includes S2 near-misses: §12.5's threshold text names "safety-critical near-miss" as a qualifying incident, so a scored near-miss is a C6 S2+ incident for clock purposes. Derived from the frozen text, not a new rule |
| Score later reversed | §17 retraction: the delta reverses (subject to caps), the original row stays marked RETRACTED, and INC-CLOCK recomputes from the remaining scored rows |

Caps bind as always (§11.3): quantized step → C2+C7 share cap (not
applicable to C6) → per-quarter cap [SJ-QCAP] → overall bound. Suppressed
amounts are written on the row.

### A.6.1 Clock reconciliation and symmetric corrections

INC-CLOCK is recomputed from the latest effective date among rows currently
scored C6 S2+ and not RETRACTED. If no such row exists, the genesis rule in
§13 supplies the start date. A correction, retraction, severity downgrade, or
backdated incident that changes that set is a corrections-log row. If a
D-INC-CLEAR down-step fired on a window that a later backdated S2+ incident
overlaps, the down-step is reversed under §17 subject to §11.3 caps, and the
reversal is shown as a separate correction row citing the trigger row. A
clear window is not a down-condition until 365 consecutive days have elapsed
with no S2+ incident whose effective date falls in the window.

A late S3 promotion recomputes the C6 state as if the S3 determination had
been made at the event's effective date, including §11.6 decay and all caps,
and posts the difference as a correction; it does not add a second step to
the current state. The same recomputation applies to a severity downgrade or
retraction so that corrections are symmetric. Original rows and determination
memos remain immutable; the recomputation and difference are appended.

For Gate 0, the reference-window test uses the incident's occurrence date
under E2; the ledger effective date under §11.3 is the primary publication
date. A post-window disclosure of a pre-window incident is history unless
§11.5's post-median exception is expressly invoked.

---

## A.7 Scorer workflow

**W-1 Intake.** A candidate enters from the periodic source sweep (AIID,
OECD AIM, regulator and court records, operator disclosures, primary
reporting) or from a submitted claim. Intake records the claim as made,
before any judgment.

**W-2 Gate 0 — window.** Establish the occurrence date (E2) and the primary
publication date separately. Gate 0 uses occurrence; the ledger effective
date uses publication (§A.6.1). Events inside the reference window [SJ-REF]
(2020-01-01 → 2026-09-15) do not score; they may be ledgered as history.
(This disposes of most famous incidents as *scoring* candidates while leaving
them fully available as calibration anchors, Appendix B.)

**W-3 Gate 1 — incident-shaped screen (CB-1).** Apply §12.2 without yet
assigning severity. Is the candidate an incident-shaped event of an AI system
(harm, near-miss, or documented failure in deployment or live evaluation)?
If it is not incident-shaped, route it to the next matching category, or exit
it as an R-NULL row naming the fit failure if none matches. **Severity is not
assessed for screen failures.** There is no severity-shopping exception.
Passing this screen is provisional, not a final C6 match.

**W-4 Gate 2 — eligibility.** Run E1–E8 in the order their inputs become
available. Source, date, fact, threshold, vendor, and rubric checks are run
now; E5's final category assignment is completed in W-5 after the S2 gate,
and E6 is recorded when the row is drafted in W-6. A failed check at any
point produces the non-scoring row §12.1 requires, naming the item. In
particular, an E1 failure stops the workflow before severity. Only candidates
with no failed threshold-independent checks proceed to W-5.

**W-5 Severity and final C6 fit.** Assign the realization class (§A.3), then
work the predicate checklist (§A.4) element by element against the evidence
(§A.5). Complete CB-1's S2-gated C6 match test and E5's final category
assignment before moving to a lower precedence category. The determination memo names: the predicate relied on;
each element and the source establishing it; the elements considered and
rejected, with reasons; the level assigned; and, for S3, the separate §12.5
strong-clause finding required by §A.6. **Borderline rule [SJ-CB-BORDER]:**
where an element is genuinely contestable on the assembled evidence, the
element is treated as unmet and the lower level is assigned; the rationale
states what evidence would change the call. This is [SJ-QUANT]'s "round
toward 1.00" and [SJ-EVID]'s burden-on-movement applied to severity: the
burden is on the higher level.

**W-6 Step and row.** Determine the step under §A.6 and draft the event
row in the §12.4 schema — `event_id, source, date, category, rule_id,
delta, m_before, m_after, M_before, M_after, suppressed, rationale` — with
the severity determination cited in the rationale (predicate ID, level,
annex version). Apply CB-3's one-fact/one-category and series-deduplication
rules before any step. Non-scoring candidates from W-3/W-4/W-5 get their rows
too, with rule_id R-NULL.

**W-7 Freeze and publish.** Rows enter the snapshot's frozen event ledger
at compute time. A published row is not edited in place, ever.

**W-8 Overturns and corrections.** A severity call can be overturned in
exactly two ways, both public:

1. **Correction (§17).** New primary evidence, or the discovery of factual
   error, supports a timestamped corrections-log entry: what was wrong,
   what it is now, the effect on M and on the headline in percentage
   points. If the event no longer qualifies, the row is marked RETRACTED
   and its delta reverses subject to caps (§17, §A.6). If it qualifies at
   a different level, the re-determination follows W-5 and is appended as
   a new determination memo; the original memo stays. Recompute the C6 state
   and INC-CLOCK under §A.6.1; a late S3 promotion is not a fresh second step.
2. **Quarterly re-adjudication.** At a §15 quarterly review, a frozen call
   may be revisited on the assembled evidence (e.g., a CS-2 second primary
   arriving late, promoting an S2 recorded under the shortfall rule to
   S3). The re-adjudication is itself a corrections-log entry. Quarterly
   review is the only venue for judgment-only second thoughts; factual
   corrections under (1) are not held for it.

The operator is the final adjudicator of contested determinations, as of
every other site judgment in the methodology. A scorer — human or
automated — proposes determinations and drafts rows; no scorer silently
amends a frozen row, a published level, or a clock value.

---

## A.8 What this annex does not do

- It does not unfreeze the compute. `compute/snapshot.py` currently exits
  if `qualifying_events` is non-empty; wiring the frozen event ledger into
  compute, with tests, is a separate engineering task that this annex
  makes *possible* but does not perform.
- It does not create the event ledger. The first ledger under this annex
  is a v1.1 work item.
- It does not give infrastructure-compromise events (platform breaches,
  runtime vulnerabilities in the general stack) a home in C6. Appendix A.3
  applies the fit gate to the two prominent October 2026 examples and
  finds it closed. Whether such events should have a rubric home is an
  R0.2 question for the operator (recon §4, question 4), not a codebook
  question.
- It does not score anything retroactively inside the reference window
  [SJ-REF].

---

## Appendix A — Worked examples I: the October 2026 candidates

Source of candidates: recon report `~/workspace/pdoom/recon-2026-10-23.md`
§3.4–3.5 (events 2026-09-16 → 2026-10-23, i.e., post-window, scoring-eligible
in principle only after the occurrence date is verified). Each example runs
the §A.7 workflow in order. The incident-shaped screen and final C6 fit are
distinct under CB-1: a failed Gate 2 stops the workflow before severity, and
“not determined” records that stop. These are worked dispositions on the
assembled recon record, not verified ledger rows. The scorer must open the
sources listed in Appendix A.4 below before publishing any row.

### A.1 HCA Healthcare — Palantir "Timpani" AI scheduling (reported 2026-10-02)

- **Gate 0 (window): NOT CLEARED on the assembled record.** The reporting
  date is post-window, but the incident occurrence date required by §A.6.1
  was not established. A scorer must verify it before treating the candidate
  as scoring-eligible in principle. Later gates are shown diagnostically and
  do not cure this failure.
- **Gate 1 (incident-shaped screen): PASS, provisional only.** The reported
  claim is AI-implicated harm in hospital operations. The OECD AI Incidents
  Monitor classifies the entry as an **Incident**, which under CS-3 is
  corroboration, not predicate evidence. This is not yet a final C6 match.
- **Gate 2 (eligibility): FAIL E1.** The Monitor entry is a secondary summary
  of news reporting; the underlying primaries (staff and union accounts,
  hospital/operator records, and any regulator record) were not assembled in
  the recon. Under W-4, the workflow stops here.
- **Severity: not determined.** CS-3 does not establish realization,
  implication, HP-1, or HP-5 to the S2+ confirmation standard. The reported
  nurse strain and patient-safety concerns remain unverified annotations, not
  an S1 or S2 determination.
- **Row and downstream precedence:** R-NULL, delta 0, rationale naming the
  unverified occurrence date (E2) and E1, with no severity determination. Under CB-1 this is a non-scoring
  C6 annotation, not a final C6 match; the candidate proceeds to the next
  matching category. A C2/C7 step may use only a distinct eligible
  deployment/autonomy fact, never the same fact used for this annotation.
- **What would change the call:** assemble the primaries in Appendix A.4,
  verify occurrence and publication dates, then re-run W-4 and W-5. Clinical
  or official evidence could establish HP-1; an operator/regulator record
  could establish HP-5 only if the named function, duration or reach, and
  attribution meet the amended predicate. Any change follows W-8.

### A.2 October 2026 autonomous-weapons items (OECD AIM-tracked)

| Date | Item | Gate 1 (C6 fit) | Severity | Disposition |
|---|---|---|---|---|
| 2026-10-03 | Northrop Grumman YFQ-48A Talon Blue — first fully autonomous flight (US) | **Fail** — a successful test flight; no harm, no failure, no near-miss | Not determined (CB-1) | Not a C6 event. C2 annotation at most (test ≠ adoption) |
| 2026-10-03 | North Korea — AI-enabled hypersonic missile test, autonomous evasive maneuvering | **Fail** — weapons test; no harm or failure event documented | Not determined | Not a C6 event. C2/C7 annotation matter |
| 2026-10-06 | Australia — Boxer vehicles integrate voice-controlled AI drone swarms (up to 100 drones) | **Fail** — integration/deployment, no incident event | Not determined | Not a C6 event. C2 with C7 annotation shape |
| 2026-10-11 | India — AI-piloted combat aircraft prototype unveiled | **Fail** — prototype unveiling; no incident; likely fails even C2's "documented adoption" threshold (E4) | Not determined | Annotation only |
| 2026-10-12 | Russia — AI neural networks operating military drones autonomously in Ukraine (human-out-of-the-loop, combat use) | **Fail as documented** — the item as reported is a deployment, not a harm/failure event; OECD labels the cluster mostly “Hazards” | Not determined | Strongest C2/C7 candidate of the window (for those categories' scorers, on primaries). For C6: should a future primary document *malfunction- or misidentification-caused* deaths from these systems, that is an HP-1 row. Should it document only intended lethal use functioning as designed, provisional RD-7 applies for v1 — annotated, not scored |

The pattern in this table is the codebook working as intended: a month of
genuinely significant autonomous-weapons movement produces **zero** C6 rows,
because C6 is the incident record, and none of these is an incident. The
movement belongs to C2 and C7, whose thresholds the C2/C7 scorers apply —
and whose combined share of the multiplier is capped for exactly this
reason (§11.4).

### A.3 Infrastructure-compromise events: the Railway breach and the PHP CVEs

These are the events the operator expected might move the number. Both fail
Gate 1: neither documents an implicated AI system's own behavior in the harm
chain. The PHP items additionally fail as vulnerability disclosures.

**Railway breach (disclosed 2026-10-21).** An unauthorized party accessed
systems storing customer environment variables — API keys and credentials,
including keys for AI inference providers — and Railway's own disclosure
frames the incident as part of a pattern of attacks *aimed at* AI/cloud API
keys.

- **Gate 1 (fit): FAIL.** Under CS-6, implication requires an AI system's
  development, use, or malfunction in the harm chain. Here the implicated
  system is a hosting platform's secrets storage; the AI systems in the
  story are the attacker's *targets' assets*, not actors in the chain. No
  AI system malfunctioned, was misused as a system, or produced the harm.
  No AIID or OECD AIM listing of the event as an AI incident was verified.
  **Severity: not determined (CB-1).** The event exits as a non-scoring
  row naming the fit failure.
- **Supplementary note (outside the determination, per CS-5 practice):**
  the realized harm is genuine — mass credential compromise, platform-wide
  forced rotations. Two further observations, recorded so the file is
  complete: (i) the downstream crypto-theft figure (~USD 371,000, attributed
  by a single blockchain investigator, unconfirmed by Railway) would fail
  CS-5 and, at that magnitude against HP-3's third-party bar, would not
  clearly meet a predicate in any case; (ii) nothing about this event
  touches INC-CLOCK, because no scored C6 S2+ row exists.
- The event is not a C6 input. It may be listed in the G3 narrative as an
  indicator of infrastructure dependency, not as evidence for a G3
  probability. §4.3 gives G3 no C6 input and no percentage.

**PHP core vulnerabilities CVE-2026-109618 / CVE-2026-109619 (details
leaked 2026-10-20; emergency patches 2026-10-21), and Composer
CVE-2026-40261 (adjacent).** Two CVSS 9.2 unauthenticated-RCE flaws in the
PHP runtime, leaked before fixes existed; governments (NL NCSC, CERT-EU,
UK NCSC) advised or executed precautionary shutdowns.

- **Gate 1 (fit): FAIL, twice over.** First, §A.3.3: a vulnerability
  disclosure is not an incident — it is a hazard as to the vulnerable
  system, and exploitation producing harm would be scored on the harm.
  Second, CS-6: no AI system is implicated. PHP is general-purpose web
  infrastructure; that AI services run on it does not put an AI system in
  any harm chain. The realized harms in the story (precautionary shutdowns)
  were defenders' responses to a non-AI vulnerability. **Severity: not
  determined.** Non-scoring rows naming both failures.
- If a future event shows an AI system's *own* behavior causing harm
  because it was compromised (the compromised system takes harmful actions
  in its operational role), that event is assessed normally: the AI system
  is then in the harm chain, and the compromise is context. That line —
  compromise *of* infrastructure vs harmful action *by* an implicated AI
  system — is the fit gate doing its job, and moving it is R0.2 territory,
  not a codebook interpretation.

### A.4 Appendix A rerun result and required primary-source checklist

**Rerun result: zero scoring C6 rows.** On the assembled record, every
October 2026 candidate is non-scoring, so this worked set leaves m_C6 at
1.00. INC-CLOCK starts at the snapshot as-of date under §13; D-INC-CLEAR is
UNMET. This is a disposition of the record reviewed, not a claim that the
underlying reporting has been independently verified.

Before a scorer publishes a row for any Appendix A candidate, they must open
the following sources and record occurrence and primary-publication dates,
source independence, and any failed E1–E8 check. “Underlying primary” means
the original record cited by the Monitor or reporting, not another summary.
No source's existence is presumed where the table says “any.”

| Candidate | Primary sources the scorer must open before publication |
|---|---|
| HCA / Palantir “Timpani” | OECD AIM entry and every underlying original it cites; any HCA/hospital-system and Palantir disclosure; original staff/union accounts; any regulator or official-investigation record; any clinical record establishing patient injury; any operator/regulator record naming a lost hospital function and its duration or reach. |
| Northrop Grumman YFQ-48A Talon Blue | OECD AIM entry; underlying Northrop Grumman and government/test-program records; any independent official test or investigation record establishing a live failure, near-miss margin, or harm rather than a successful test. |
| North Korea AI-enabled hypersonic missile test | OECD AIM entry; underlying official test announcement and any instrumented test record; independent primary corroboration under CS-0; any official investigation of a malfunction, near-miss, or harm. |
| Australia Boxer / AI drone-swarm integration | OECD AIM entry; underlying Australian government/defence and integrator records; any operational test or incident report documenting a failure, NM-1 margin, or harm, and distinguishing integration from an incident. |
| India AI-piloted combat-aircraft prototype | OECD AIM entry; underlying developer and Indian government/test-program records; any flight-test or official-investigation record documenting live failure, near-miss, or harm rather than an unveiling. |
| Russia AI-enabled drone operations | OECD AIM entry and underlying original operational reporting; any operator/deployer disclosure; any official investigation, clinical, or death record identifying a specific malfunction- or misidentification-caused death; independent primary corroboration of occurrence and AI implication; the operational-role record needed to distinguish deployment from an HP-1 incident. |
| Railway breach | Railway security disclosure (2026-10-21) and status page; any regulator or official-investigation record; primary third-party loss records; any compromised AI system's operational logs or investigation showing that the AI system itself took harmful action. Stolen AI-provider credentials alone do not establish CS-6 implication. |
| PHP CVE-2026-109618 | php.net and CVE record for CVE-2026-109618; NL NCSC, CERT-EU, and UK NCSC primary advisories relied on for the response; any official exploitation investigation; any primary record showing an implicated AI system's own harmful operational action. |
| PHP CVE-2026-109619 | php.net and CVE record for CVE-2026-109619; NL NCSC, CERT-EU, and UK NCSC primary advisories relied on for the response; any official exploitation investigation; any primary record showing an implicated AI system's own harmful operational action. |
| Composer CVE-2026-40261 | php.net/package maintainer and CVE record for CVE-2026-40261; any official exploitation investigation and primary harm record; any primary record showing an implicated AI system's own harmful operational action rather than a defender-caused shutdown. |

---

## Appendix B — Worked examples II: historical calibration anchors

All anchors fall inside the reference window [SJ-REF] (2020-01-01 →
2026-09-15) or before it, so Gate 0 bars all of them from scoring. They
exist to calibrate the scale on the facts stated in each anchor: a reader
should be able to see what S0, S1, and S2 look like — and to notice that
**no realized AI incident in the record to date clearly meets S3**, which is
the correct posture for the top of a scale guarding a catastrophe index.
The amended rerun gives B.1 = S2, B.2 = S2 subject to its clinical-source
caveat, B.3 = S1 on the stated facts (subject to its primary-source caveat),
B.4 = S1, and B.5 = S0. Every anchor is non-scoring history under Gate 0.

### B.1 S2 — Uber ATG pedestrian fatality, Tempe, Arizona (2018-03-18)

A developmental automated driving system in computer control struck and
killed a pedestrian crossing with a bicycle. The NTSB's final report
(HAR-19/03) documents that the system detected the pedestrian 5.6 seconds
before impact, alternately classified her and her bicycle, could not
predict her path, and that emergency braking was disabled by design while
in computer control; the safety operator was visually distracted; Uber's
safety culture and oversight were cited as contributing causes.

- Realization: RC-R. Predicate: **HP-1, S2 column** (≥1 death, AI system
  implicated in live evaluation — §A.3.4 makes on-road testing deployment
  for this purpose).
- Level: **S2.** One death does not reach S3; S3 is scale or the EU-serious
  limbs at scale. This is the canonical "named harm" event the §12.5 C6
  threshold was written around.

### B.2 S2 — Cruise pedestrian dragging, San Francisco (2023-10-02)

A pedestrian thrown into a Cruise robotaxi's path by a human hit-and-run
driver was struck and stopped upon by the AV; the AV then executed a
pullover maneuver, dragging her roughly 20 feet at up to 7 mph and causing
serious injuries. The sequence is documented in DMV and NHTSA records and
the operator's regulatory aftermath (permit suspensions).

- Realization: RC-R. Predicate: **HP-1, S2 column** via the serious-injury
  limb — no death required.
- Level: **S2.** The second anchor exists to show HP-1's injury limb
  working independently of its death limb, and to show a case where the
  initial impact was not the system's fault but the scored harm — the
  dragging — was the system's own action. Implication (CS-6) attaches to
  the harm chain the AI system actually drove. **Publication caveat:** the
  scorer must open the DMV/NHTSA records and name the §A.4.0 clinical element
  establishing serious injury; the summary phrase “serious injuries” alone
  would not satisfy the amended definition.

### B.3 S1 on the stated facts — Uber self-driving cars running red lights, San Francisco (2016)

AIID Incident 8, the AIID editors' own canonical near-harm example:
self-driving vehicles in live on-road operation ran red lights; no
collision resulted.

- Realization: **RC-H**, not RC-N, because NM-1 is not fully met. Live role
  and failure are consistent with the stated signal violations; other road
  users and chance are the stated external aversion. But amended NM-1 element
  3 requires a named harm mechanism **and a quantitative margin**. The draft
  supplied neither a time-to-collision nor a remaining-barrier, distance, or
  equivalent margin. Its assertion that continuation would more likely than
  not have produced HP-1/HP-2-grade harm is therefore undocumented and
  contestable; under [SJ-CB-BORDER], element 3 is unmet.
- Level: **S1 on the facts as stated, not S2.** A signal violation without
  a documented margin cannot be an S2 anchor. This calibration assumes an
  underlying E1 primary establishes occurrence and AI implication; the AIID
  listing alone would fail Gate 2 and permit no published severity call.
  Before this anchor is published, the scorer must open AIID Incident 8 and
  its underlying primary record. Only a documented quantitative margin could
  support re-adjudication to S2 through W-8; Gate 0 bars scoring regardless.

### B.4 S1 — Air Canada chatbot misinformation (interaction 2022; BC Civil Resolution Tribunal, 2024)

The airline's support chatbot invented a bereavement-fare refund policy;
a passenger relied on it and was refused the refund; the tribunal held the
airline liable for the chatbot's statement. Loss: roughly CAD 812.

- Realization: RC-R, with an authoritative determination (which would
  matter for HP-4 in a rights case). Predicates: financial loss three
  orders of magnitude below HP-3's bar; no other predicate approached.
- Level: **S1.** The anchor's lesson is the floor: a famous, adjudicated,
  genuinely wrongful AI harm is still chatter *for this instrument*,
  because C6 conditions a catastrophe index and must not become a counter
  of ordinary accountability failures. The event is exactly what the
  public R-NULL row is for — visible, reasoned, non-scoring.

### B.5 S0 — "AI drone kills its operator" (June 2023)

A speaker at a Royal Aeronautical Society summit described a simulated
engagement in which an AI drone killed its operator; the story was widely
reported as a real event. The speaker subsequently clarified it was a
thought experiment — a simulation anecdote about a scenario that was
never run as described — and the US Air Force denied any such simulation
took place.

- Realization: RC-X — no occurrence evidence survives CS-1/CS-5; the
  best source for the event is its retraction.
- Level: **S0.** The anchor marks the bottom of the scale and the
  confirmation standards working as designed: maximum global coverage,
  zero score, and a public row whose rationale is the correction itself.

---

## Appendix C — Sources and the adapted/invented ledger

**Adopted (definitions and distinctions):**

- OECD, *Defining AI incidents and related terms* (May 2024) — the
  incident/hazard definitions and the four harm classes (a)–(d), quoted in
  §A.2.1. Operationalized by the OECD AI Incidents Monitor (AIM),
  methodology at oecd.ai/en/incidents-methodology.
- AI Incident Database (Responsible AI Collaborative), incident definition
  and editors' guidance on near harm, incl. Incident 8 as the canonical
  near-harm example; the incident/issue distinction.
- EU AI Act, Art. 3, "serious incident" — the four "serious" limbs adapted
  into the S3 column of §A.4.1.

**Adapted (changed in the adoption, flagged in place):**

- Financial loss as a standalone harm class with numeric bars (HP-3) —
  OECD folds it into (d) ungraded. [SJ-CB-SCALE]
- The near-miss barrier test's safeguard carve-out (NM-1 element 4) —
  AIID's near-harm gloss does not distinguish designed safeguards from
  external factors; safety-critical deployment requires the distinction.
  [SJ-CB-BARRIER]
- Scale thresholds on the EU-serious limbs (HP-5 S3) — the Act is a
  reporting trigger and carries none.

**Invented for this instrument (no external source):**

- The S0–S3 ladder itself; every numeric threshold in §A.4 (person-counts,
  USD 100,000 / USD 100,000,000, the one-hour / 100-person HP-5 S2 bars and
  24-hour / 100,000-person HP-5 S3 bars); the decision definitions in §A.4.0;
  the NM-1 quantitative-margin requirement and NM-2 near-miss cap; the
  exposure test (§A.3.1); the confirmation standards CS-0…CS-7 as a set
  (assembled from E1–E8 and §12.5's clauses, but a new codification); the
  series-deduplication windows in CB-3; the clock-reconciliation procedure in
  §A.6.1; and the borderline rule [SJ-CB-BORDER] (an application of
  [SJ-EVID] and [SJ-QUANT], stated here for severity).

**Factual sources for the worked examples:** NTSB HAR-19/03 (Tempe);
California DMV / NHTSA records and contemporaneous regulatory reporting
(Cruise); AIID Incident 8 (red lights); *Moffatt v. Air Canada*, BC Civil
Resolution Tribunal (2024); speaker clarification and USAF denial as
reported June 2023 (drone anecdote); Railway security disclosure
(2026-10-21) and status page; php.net / CVE records for CVE-2026-109618,
CVE-2026-109619, CVE-2026-40261; OECD AIM entries for October 2026
(HCA/Timpani; autonomous-weapons cluster) — all as inventoried in
`~/workspace/pdoom/recon-2026-10-23.md` §3.4–3.5.

---

## A.9 Operator decisions — seat rulings, 2026-10-23

The site owner delegated methodology calls to the GS seat. The seat adopts
Fugu's recommended rulings RD-1 through RD-10 as written, with RD-2 and RD-7
expressly provisional. These are decisions for this candidate; the formal
adoption and hash-stamping act remains with the operator under RD-1.

| ID | Status | Decided ruling |
|---|---|---|
| **RD-1** | **DECIDED** | **Adopt as an R0.1 completion**, conditional on the amendments in this candidate; record the annex hash beside BLOB-R0.1 and add a method-page note “C6 codebook in force.” If any amendment is read as creating a new step or trigger, re-label as R0.2 with the §12.7 discontinuity marker. |
| **RD-2** | **DECIDED — PROVISIONAL** | **USD 100,000 (S2) / USD 100,000,000 (S3), nominal, for v1.** Do not decide indexing or permanence before a calibration pass on the first 20 C6 rows against AIID/OECD loss data. The ≥1,000-person alternative prong is independent of the dollar figures and is reviewed in the same pass. |
| **RD-3** | **DECIDED** | **One death is S2, not S3.** Serious injury is hospitalization, fracture, loss of consciousness, or lasting impairment, documented clinically as §A.4.0 requires. |
| **RD-4** | **DECIDED** | **Thwarted attacks and attempts cap at S1 unless NM-1 is fully met.** The event must reach a live safety-critical path and be stopped from outside the failed or targeted function. Giving infrastructure-compromise events a separate rubric home remains an R0.2 question. |
| **RD-5** | **DECIDED** | **No near-miss exceeds S2**, however many barriers failed. A counterfactual near-miss does not reset INC-CLOCK at S3 or argue for two steps. |
| **RD-6** | **DECIDED** | **Adopt the HP-3 bearer rule.** Losses borne solely by the developer/deployer from its own system's failure do not count; third-party losses do. |
| **RD-7** | **DECIDED — PROVISIONAL FOR v1** | **Intended lethal use by state militaries is annotated, not scored, for v1.** Malfunction- and misidentification-caused deaths score normally under HP-1. Scoring intended use is an R0.2 question after a separate legal/operational review; this ruling does not decide that question. |
| **RD-8** | **DECIDED** | **Rights harms require a court/regulator determination or deployer admission.** Without one, HP-4 does not reach S2 regardless of the alleged affected population. CS-0 independently requires occurrence and AI implication. |
| **RD-9** | **DECIDED** | **Diffuse occupational harm documented only at news level caps at S1.** Lowering the primary-evidence bar for this class would break the confirmation standard applied to every other predicate; revisit only if suitable regulator-produced systematic occupational-health data is available. A candidate that fails E1 receives no severity determination at all under W-4. |
| **RD-10** | **DECIDED** | **Aggregate a continuing series within one deployment and one failure mode, with the CB-3 365-day/one-row cap.** Later incidents in that series update counts only by appended correction and do not generate another up-step unless a new deployment or failure mode is documented. The same-operator quarterly movement rule in CB-3 also applies. |

**Ratification note.** Adopting this annex does not by itself produce a
v1.1 number. It removes gate 1 of the three structural prerequisites in
recon §3.1. Gate 2 (unfreezing the event pipeline in `compute/snapshot.py`,
with tests) and gate 3 (creating and freezing the first event ledger) are
separate work items, and publishing remains the operator's decision on the
assembled snapshot, as it was for v1.0.

*— End of ratification candidate annex A-C6. Drafted 2026-10-23; reviewed
and amended 2026-10-23. No code, site, snapshot, or event ledger was modified.*