# The Record — User Stories

## Purpose

The Record is a WHO-hosted, global public-interest registry of deaths and serious harms linked to conversational AI chatbots. It must let the public understand individual cases and uncertainty, let affected and authoritative parties contribute evidence or challenge errors, and give journalists, lawyers, researchers, and regulators durable evidence without turning allegations into facts or exposing protected people.

This document synthesizes 115 stories from eleven perspectives: public visitor, family member, journalist, plaintiff attorney, WHO regulator, academic epidemiologist, autonomous research agent, editorial reviewer, adversary, vendor counsel, and coroner. Adversary stories are expressed as outcomes the design must prevent. No source story is discarded: every capability lists its originating `US-XX-YY` references, and merged acceptance criteria retain each distinct requirement.

Capabilities are grouped by the dominant user outcome, although several span areas. Priority is the highest source priority (`P0 > P1 > P2`); any disagreement is shown beside it. “Conflicts” identify requirements that cannot safely be reconciled by simple feature combination and therefore need policy or architecture decisions in the HLD.

## Persona index

| Persona id | Short name | Role | Primary need |
|---|---|---|---|
| 01 | Sarah Chen | Public visitor | Understand, verify, find, and share cases without specialist knowledge. |
| 02 | Adrian Marks | Family member | Submit and maintain a loved one’s case with dignity, privacy, and human support. |
| 03 | Rachel Okafor | Investigative journalist | Contribute sourced reporting and rely on attributable, current, durable records. |
| 04 | David Levine | Plaintiff-side attorney | Discover patterns and preserve authenticated, court-ready evidence. |
| 05 | Dr. Priya Suresh | WHO regulator | Evaluate comparable surveillance evidence, methods, uncertainty, and sovereignty. |
| 06 | Prof. Kenji Tanaka | Academic epidemiologist | Reproduce analyses from citable, versioned data and provenance. |
| 07 | RAVI-1 | Autonomous research agent | Discover, validate, and incrementally retrieve public data without human-only barriers. |
| 08 | Elena Vidal | Editorial reviewer | Verify and publish defensible records through accountable, sustainable workflows. |
| 09 | Adversary | Threat actor / negative persona | Corrupt, suppress, exploit, deanonymize, or disable the registry—the design must prevent this. |
| 10 | Nia Delacroix | Vendor legal counsel | Exercise a timely, evidence-based right of reply without erasing editorial independence. |
| 11 | Marcus Reddick | Coroner / medical examiner | Submit and preserve an official verdict with legal meaning and protected identities intact. |

## Capability areas

### 1. Public reading & discovery

The public experience must make a complex evidence registry intelligible while preserving the distinctions, provenance, uncertainty, and privacy that make it trustworthy.

#### CAP-1.01 — Plain-language entry and terminology
**Personas:** Sarah Chen (US-01-01)
**Priority:** P0
**As a public visitor,** I want a plain-language path into the registry so that specialist vocabulary does not prevent exploration.
**Acceptance criteria:**
- Given I arrive from a general search, when the registry opens, then I see a plain-language introduction and a clear browse path.
- Given I focus, tap, or activate a specialist term, when its help opens, then I receive a concise definition without losing my place.
- Given I search with everyday words, when relevant material exists, then results also teach me the associated registry terms.
**Design notes:** Keep formal methodology accessible.

#### CAP-1.02 — Evidence tiers, claim status, and conflicting sources
**Personas:** Sarah Chen (US-01-02, US-01-04)
**Priority:** P0
**As a reader,** I want tiers and claim qualifications explained beside evidence so that I do not mistake uncertainty for settled fact.
**Acceptance criteria:**
- Given T1, T2, or T3 appears, when I activate it or open the tier guide, then I see its plain-language definition, criteria, and distinctions from the other tiers without implied meanings beyond policy.
- Given I open a case, when I read a factual claim, then it links to an identifiable citation or is explicitly marked unsupported, and its confirmed, disputed, or other methodological status is visible and explained.
- Given sources conflict, when I inspect the relevant section, then the disagreement is represented without declaring the disputed point settled.
- Given a citation’s source is available, when I activate it, then I reach the material or sufficient identifying metadata.
**Design notes:** Tier is not causality or severity.

#### CAP-1.03 — Faceted, docket, and cohort discovery
**Personas:** Sarah Chen (US-01-03), David Levine (US-04-03, US-04-04), Prof. Kenji Tanaka (US-06-05), Marcus Reddick (US-11-06)
**Priority:** P0
**As a reader or specialist researcher,** I want composable filters and normalized searches so that I can find geographic, vendor, legal, evidentiary, and prevention patterns.
**Acceptance criteria:**
- Given I select one or more country, vendor, year, court, legal-theory, evidence-tier, prevention-report, topic, recipient, or jurisdiction filters, when applied, then results and counts follow documented combination rules, show every active criterion, and let me remove criteria independently.
- Given no result matches, when results update, then I see a clear empty state and can reset or broaden filters; given inclusion and exclusion tier selections conflict, then the system blocks them or states deterministic precedence first.
- Given I enter a docket with variant punctuation, spacing, or prefixes, when I search, then exact and normalized matches are returned across cases.
- Given firm matters or multiple records relate to one litigation, when shown, then sourced relationships are cross-linked without merging distinct cases or exposing confidential matter data.
- Given a legal theory tag is shown, when I inspect it, then its source is available; given I save or export a query, then its criteria, execution date, tier definitions, dataset version, and resulting count accompany it.
- Given recommendations or Regulation 28 materials exist, when I filter by prevention report metadata, then they and later official responses are discoverable chronologically without exposing protected identities.
**Design notes:** Version vocabularies and normalization.

#### CAP-1.04 — Trustworthy site, citation, and source provenance
**Personas:** Sarah Chen (US-01-05), David Levine (US-04-05), Prof. Kenji Tanaka (US-06-06), Marcus Reddick (US-11-10)
**Priority:** P0 (source priorities P0/P1)
**As a reader,** I want verifiable publisher and source lineage so that I can distinguish official, primary, secondary, and restricted evidence.
**Acceptance criteria:**
- Given I inspect site identity, when I activate the WHO badge or equivalent marker, then it verifies the host and publisher.
- Given I inspect a citation, when details open, then title, publisher or author, publication date, destination, retrieval date, source type, archive location, and its relationship to the finding appear when available; intermediary lineage leads toward primary material.
- Given a court filing is verified against an official source or authenticated docket copy, when its badge opens, then I see court, docket, title, filing date, URL, retrieval date, and PDF hash; if redistribution is barred, then an official citation and access route replace a false attachment link.
- Given a source may be redistributed, when requested, then the preserved document includes checksum and rights metadata; if restricted, then a citation, stable locator, access date, hash, and limitation support comparison with a lawful copy.
- Given a source is corrected or replaced, when history is inspected, then earlier relationships and hashes remain visible.
- Given a capacity-verified official and hash-verified document support a case, when displayed or exported, then an official-source badge names the office and jurisdiction, secondary material remains separately labeled, and the original official text remains recoverable through history.
**Design notes:** Official origin does not endorse interpretation.

#### CAP-1.05 — Responsible longitudinal and comparative analytics
**Personas:** Dr. Priya Suresh (US-05-02, US-05-03), Prof. Kenji Tanaka (US-06-11)
**Priority:** P0 (source priorities P0/P2)
**As a policy or academic analyst,** I want transparent trends and comparisons so that reporting artifacts are not mistaken for risk or causal change.
**Acceptance criteria:**
- Given I choose a period and time unit, when a trend loads, then it shows counts and defensible rates with 95% confidence or credible bands, numerator and denominator definitions, and downloadable values.
- Given coverage, methodology, or tier rules changed, when I inspect a series, then discontinuities are annotated and original versus consistently reprocessed series are distinguishable; recent lag-affected periods are provisional with completeness or nowcast assumptions and warnings against unsupported incidence or causality claims.
- Given countries are compared, when displayed, then assignment rules distinguish event location, residence, and reporting jurisdiction and show missingness, ascertainment, denominator, and source-coverage limitations; non-comparable ranking is blocked by default.
- Given vendor, parent, product, or model breakdowns are requested, when returned, then a versioned entity registry preserves historic names and ownership and labels unknown or disputed attribution.
- Given a cell is small or identifying, when viewed, queried, or downloaded, then consistent suppression or aggregation applies.
- Given I generate a kernel-density trend, when displayed or downloaded as accessible, editable SVG, then kernel, bandwidth, boundary treatment, temporal unit, missing-date handling, active filters, dataset version, non-identifying plotted values, and a regenerable machine specification accompany it.
**Design notes:** Surface limitations before comparison.

#### CAP-1.06 — Concise offline case summary
**Personas:** Sarah Chen (US-01-12)
**Priority:** P1
**As a public visitor,** I want a concise case summary for offline reference so that key facts and sources remain usable away from the live site.
**Acceptance criteria:**
- Given I request a summary, when generated, then it identifies the case, displayed status, last-updated date, citations, and canonical URL.
- Given I read it offline, when source details are displayed, then names and links or identifiers remain legible.
- Given the live case may change, when I inspect the file, then its generation date and direction to the current canonical record are clear.
**Design notes:** This is not an evidentiary snapshot.

#### CAP-1.07 — Dignified family context
**Personas:** Adrian Marks (US-02-08)
**Priority:** P1
**As a family submitter,** I want optional tribute and family context so that a person is not reduced to a death or chatbot interaction.
**Acceptance criteria:**
- Given I add tribute language, when published, then it appears in a clearly identified family-context section separate from verified findings.
- Given an editor proposes changes, when I review them, then I can compare wording, discuss it with a human, and approve or decline before publication.
- Given I am not ready, when I submit, then I may leave tribute blank and add it later.
**Design notes:** Keep context separate from findings.

### 2. Submission workflows (family / journalist / coroner / vendor / editorial)

Submission must support radically different authority, safety, evidence, and timing needs while ensuring that submission alone never confers verification or public status.

#### CAP-2.01 — Explainable, trauma-informed family intake
**Personas:** Sarah Chen (US-01-06), Adrian Marks (US-02-01)
**Priority:** P0
**As a family member or curious visitor,** I want understandable submission and correction guidance so that I can participate without legal expertise or surrendering data merely to learn.
**Acceptance criteria:**
- Given I read process guidance, when it opens, then stages, evidence expectations, review, challenge, correction, and separate missing-case and wrong-record routes are explained without requiring an account or personal information.
- Given I begin family intake, when it opens, then a supportive introduction, content notice, question preview, and clear pause, save, and return controls appear.
- Given a required legal, medical, or technical term appears, when I answer, then plain language and examples are beside it; nonessential questions may be skipped without loss or blockage.
- Given I need help, when requested, then a clearly described route reaches a named human reviewer rather than only an automated response.
**Design notes:** Treat support and resumability as functional.

#### CAP-2.02 — Granular public identity and consent controls
**Personas:** Adrian Marks (US-02-02)
**Priority:** P0
**As a family submitter,** I want field-level control and an exact preview so that the public record respects the person’s privacy and memory.
**Acceptance criteria:**
- Given I configure identity, when previewed, then I can choose full name or first initial and independently include or omit a photo exactly as the public will see it.
- Given I enter location and date, when setting visibility, then I can limit location to hometown and withhold the exact date.
- Given publication or republication is proposed, when I review the preview, then current name, photo, location, and date choices require confirmation.
**Design notes:** Separate public and review data.

#### CAP-2.03 — Private relationship verification
**Personas:** Adrian Marks (US-02-04), Adversary (US-09-03)
**Priority:** P0
**As a family submitter,** I want to prove my relationship privately so that impersonators cannot claim family authority and verification does not expose me.
**Acceptance criteria:**
- Given family status is claimed, when verification begins, then plain-language instructions list acceptable identity and relationship evidence plus a route for people without listed documents.
- Given evidence is provided, when submitted, then it is confidential, absent from the public entry, and preceded by an explanation of who may access it and why.
- Given contact ownership or required identity-sensitive verification is incomplete, when the submission is handled, then it is not labeled family-authenticated.
- Given the subject’s name is public, when previewed, then my name, contact details, documents, and relationship remain absent unless separately and explicitly disclosed; failed impersonation never appears as verified submission from me.
**Design notes:** Verification is not publication consent.

#### CAP-2.04 — Confidential, integrity-checked supporting evidence
**Personas:** Adrian Marks (US-02-03), David Levine (US-04-10), Elena Vidal (US-08-06), Marcus Reddick (US-11-02)
**Priority:** P0 (source priorities P0/P1)
**As a submitter or reviewer,** I want sensitive evidence preserved privately with provenance and hashes so that it can verify a case without uncontrolled disclosure or silent replacement.
**Acceptance criteria:**
- Given a coroner report, verdict, screenshot, court filing, or expert declaration is uploaded, when stored, then it is reviewer-only by default, encrypted, role-restricted, and records original file, source and chain-of-custody metadata, upload time, uploader, confidentiality/redaction state, case links, and cryptographic hash.
- Given I review my upload, when needed, then I can remove, replace, or supply a redacted version without changing public narrative; any proposal to publish an excerpt is shown exactly and requires explicit permission and applicable authorization.
- Given a hash is recalculated, when it differs, then access/publication stops, the incident is logged, and silent replacement is rejected; original and replacement retain distinct hashes, timestamps, identities, reasons, and case links.
- Given an expert declaration is submitted, when described, then expert, court, docket, date, and filing status are captured; given restricted personal data exists, then public release is blocked until authorization and redaction requirements pass while the sealed original remains secure.
- Given an official file is downloaded, when checked, then the service reports whether it matches the submission hash.
**Design notes:** Govern originals and derivatives separately.

#### CAP-2.05 — Family status, edit, and fact-update loop
**Personas:** Adrian Marks (US-02-05, US-02-07)
**Priority:** P1
**As a family submitter,** I want understandable status and edit updates so that I can add new facts without losing history or human contact.
**Acceptance criteria:**
- Given status becomes verified or published, when it changes, then my chosen channel receives a plain-language explanation and a link to the current entry or preview.
- Given an edit is proposed, when ready, then I receive a human-readable what-and-why summary and whether I must respond; sensitive questions can reach an identifiable reviewer and receive a distinct human-path acknowledgement.
- Given a lawsuit, ruling, or other development emerges, when I submit it, then I can state fact, timing, source, and confidential evidence.
- Given an update is pending, when viewed, then published and proposed text and review status are distinct; when accepted, the update is dated and does not silently overwrite history.
**Design notes:** Prevent notification leakage.

#### CAP-2.06 — Withdrawal and jurisdictional erasure
**Personas:** Adrian Marks (US-02-06)
**Priority:** P0
**As a family submitter,** I want to withdraw or invoke applicable erasure rights so that later choices and jurisdictional rights receive a reasoned human decision.
**Acceptance criteria:**
- Given publication has not occurred, when I withdraw, then review and publication stop and I receive confirmation.
- Given the case is public, when I request withdrawal, then before confirmation I see what will be removed or retained, why, and the decision timeline.
- Given I identify the relevant jurisdiction, when I request deletion or equivalent protection, then I need not know a statute name and receive an explanation under applicable law.
- Given a request is completed, denied, or partial, when decided, then I receive a dated outcome, remaining public material, and a route for human review or challenge.
**Design notes:** Model withdrawal and erasure separately.

#### CAP-2.07 — Sourced journalist submission and attribution
**Personas:** Rachel Okafor (US-03-01), Adversary (US-09-04)
**Priority:** P0
**As an investigative journalist,** I want sourced first-namer and surfacing-outlet credit so that original reporting remains attributable after deduplication.
**Acceptance criteria:**
- Given I submit after publication, when byline, outlet, URL, date, case details, and sources are verified, then the canonical page credits the surfacing outlet and first-namer.
- Given several sources are supplied, when stored, then each URL retains available title, publisher, author, and date; an exclusive label applies only to reporting exclusive to that outlet, not independently available facts.
- Given a later contributor submits the same case, when duplicates resolve, then verified first-namer and outlet credit remain while later contributions are acknowledged.
- Given publication occurs, when public metadata is generated, then receipt time, queue position, reviewer activity, file metadata, IP-derived data, and other submitter-correlating signals are not exposed.
**Design notes:** Attribution requires consent and privacy review.
**Conflicts:** [CONFLICT: Rachel Okafor US-03-01 vs Adversary US-09-04] Public first-namer credit can identify a submitter or source through timing and metadata; the system needs consented attribution without exposing nonpublic submission lineage.

#### CAP-2.08 — Embargo and consent holds
**Personas:** Rachel Okafor (US-03-02), Elena Vidal (US-08-05)
**Priority:** P0
**As a source or editor,** I want explicit embargo and consent holds so that sealed, unpublished, or unapproved material cannot appear prematurely.
**Acceptance criteria:**
- Given a future media embargo is set, when pending, then case, sources, and existence are visible only to authorized staff; the submitter can update or cancel it with confirmation.
- Given the embargo expires, when the published URL and verification are ready, then release occurs automatically with attribution; otherwise it remains private and the submitter receives an actionable alert.
- Given a sealed record or family-approved wording is pending, when an editor sets its distinct hold, then publication is blocked and reason, owner, review date, access restrictions, and consent scope are recorded.
- Given a hold clears, when supported by details, then the case returns to staging and still requires ordinary two-editor approval; unauthorized public users see neither case nor hold reason.
**Design notes:** Keep hold types distinct.

#### CAP-2.09 — Validated bulk docket intake
**Personas:** Rachel Okafor (US-03-04)
**Priority:** P1
**As a journalist,** I want structured batch submission for coordinated dockets so that each person receives a distinct record without repetitive entry.
**Acceptance criteria:**
- Given a docket has at least ten cases, when I upload the documented CSV template, then shared metadata and every case row are validated.
- Given a row is missing, invalid, or possibly duplicate, when validation ends, then row-level feedback lets me fix or exclude it without re-entering valid rows.
- Given the batch is accepted, when processed, then each victim receives a distinct canonical case linked to the docket with its own sources, attribution, and status.
- Given I open the receipt, when reviewed, then every row shows status, stable identifier, and canonical URL.
**Design notes:** Preserve person-level review.

#### CAP-2.10 — Authenticated institutional submission channels
**Personas:** Dr. Priya Suresh (US-05-07), Marcus Reddick (US-11-01)
**Priority:** P0
**As a ministry focal point or coroner,** I want a dedicated authenticated channel so that official submissions and corrections carry accountable authority.
**Acceptance criteria:**
- Given an institutional account is enrolled, when authority is verified, then organization, office, jurisdiction, current capacity, assurance level, and authoritative-directory or professional-body checks are recorded; conflicting checks block official publication for secure administrative review.
- Given the official authenticates, when using phishing-resistant MFA, then a secure workflow distinct from the public form supports cases, batches, corrections, and restricted-source attestations through encrypted portal or mutually authenticated API.
- Given a submission arrives, when validated, then authority, jurisdiction, digital signature, receipt time, disclosure constraints, and immutable receipt are recorded.
- Given it is incomplete, disputed, or amended, when status changes, then authorized users can track review, answer structured queries, and inspect versions without silent overwrite.
**Design notes:** Verify accounts and documents independently.

#### CAP-2.11 — Faithful official-verdict publication
**Personas:** Marcus Reddick (US-11-03, US-11-05, US-11-06)
**Priority:** P0 (source priorities P0/P1)
**As a coroner or medical examiner,** I want an official verdict mapped, tiered, and supplemented faithfully so that searchability and prevention use do not alter legal meaning.
**Acceptance criteria:**
- Given official findings, causation language, dates, scope, or local terms are mapped, when values are proposed, then each links to the exact source passage and complete original; inexact equivalents preserve the phrase and limitation without broadening or narrowing it.
- Given I approve or correct mapping, when saved, then my attestation is recorded and structured values publish beside controlling original wording.
- Given capacity and document are verified, when submitted, then T1 is assigned without the ordinary evidence queue; incomplete integrity, required-field, or protected-identity checks pause compliance only, and the published record explains the official basis, office, and jurisdiction.
- Given recommendations or Regulation 28 reports are attached, when stored, then document type, office, date, recipients, status, case relationship, and hash are recorded; later recipient responses and follow-up appear in chronology.
**Design notes:** Direct T1 retains compliance controls.
**Conflicts:** [CONFLICT: Marcus Reddick US-11-05 vs Elena Vidal US-08-02 / Adversary US-09-02] Direct T1 conflicts with universal evidence and approval gates.

### 3. Editorial verification & moderation

Editorial controls must convert heterogeneous submissions into defensible public records while making every consequential judgment reviewable and reversible without erased history.

#### CAP-3.01 — Versioned methodology and sourcing policy
**Personas:** Sarah Chen (US-01-11), Rachel Okafor (US-03-08), Dr. Priya Suresh (US-05-01), Prof. Kenji Tanaka (US-06-02), Nia Delacroix (US-10-09)
**Priority:** P0 (source priorities P0/P1)
**As a reader, submitter, or analyst,** I want a citable, versioned methodology so that inclusion, sourcing, tiers, disputes, and dataset effects can be audited.
**Acceptance criteria:**
- Given I open methodology, when I select a version, then a plain-language summary links to the full protocol covering population, period, search strategy, source scope, screening, inclusion/exclusion, deduplication, evidence tiers, adjudication, disputes, corrections, attribution, exclusivity, embargo, retention, and disclosure.
- Given T1 is defined, when policy is inspected, then qualifying sources, corroboration, reliability tests, exclusions, contradictory-evidence burden, and restrictions on unpublished official material are explicit; each T1 entry and dispute identifies its policy version.
- Given a policy changes, when effective, then version ID, date, rationale, approver, field-level differences, affected dataset releases, archived prior versions, and a plain-language material-change summary are available.
- Given I cite methodology, when metadata is generated, then responsible authors or board, title, version, publisher, publication date, and persistent identifier are supplied.
- Given a policy governs an in-progress submission, when acceptance is requested, then the exact governing version is linked.
**Design notes:** Bind policy versions to decisions.

#### CAP-3.02 — Moderated intake, duplicate detection, and abuse triage
**Personas:** Elena Vidal (US-08-01), Adversary (US-09-02, US-09-03)
**Priority:** P0
**As an editorial reviewer,** I want an abuse-resistant intake queue so that duplicates, fabricated observations, and coordinated submissions do not inflate priority, tiers, or counts.
**Acceptance criteria:**
- Given a submission resembles an existing or pending case, when detected, then candidate records, matching fields, confidence, velocity/content/source/entity signals, repeated submitter contact, and defined hallucination signatures are shown without automatic merge or rejection.
- Given an editor confirms, rejects, groups, rate-limits, merges, holds, or rejects a match, when decided, then the submission stays traceable and disposition and reason enter the audit log; a flag alone never changes tier or suppresses a case.
- Given evidence is not independently reviewable or a case duplicates a person/event, when assessed, then it does not enter public counts until an auditable disposition and approval.
- Given an unvalidated “sighted on X” item or premature allegation arrives by form, batch, or API, when not linked to validated source and canonical record, then it is excluded from pages, aggregates, feeds, ordering, tiers, and public status.
- Given coordinated duplication or server-side quotas trigger, when requests are bounded, then legitimate queued submissions remain reviewable and repeated variants do not multiply priority or counts.
**Design notes:** Flags inform; they do not decide.

#### CAP-3.03 — Evidence-gated tier workflow
**Personas:** Elena Vidal (US-08-02), Adversary (US-09-02), Nia Delacroix (US-10-09), Marcus Reddick (US-11-05)
**Priority:** P0
**As an editor,** I want tier-specific validation so that the public classification and count cannot exceed the reviewed evidence.
**Acceptance criteria:**
- Given T1 is proposed, when a validated coroner PDF or required T1 provenance is absent, then approval is blocked; given T2 is proposed, when fewer than two distinct named-source URLs exist, then approval is blocked with the missing requirement identified.
- Given T3 is staged or shown editorially, when displayed, then it is explicitly under review and never represented as verified.
- Given a T3-to-T1 promotion lacks required fields, provenance, or independent approval, when attempted, then it is rejected and public tier and count remain unchanged.
- Given a tier changes, when saved, then prior/new tier, evidence basis, policy version, editor, timestamp, and reason append to history.
- Given an official capacity and finding pass their documented pathway, when assigned T1, then official origin is explicit and remaining integrity/privacy controls still gate publication.
**Design notes:** Scope the official-source exception.
**Conflicts:** [CONFLICT: Marcus Reddick US-11-05 vs Elena Vidal US-08-02 / Adversary US-09-02] Resolve direct T1 versus universal gates.

#### CAP-3.04 — Staging and four-eyes publication
**Personas:** Elena Vidal (US-08-03), Adversary (US-09-01)
**Priority:** P0
**As an editor,** I want staged diffs and separation of duties so that one person cannot publish a new or high-impact changed record alone.
**Acceptance criteria:**
- Given an editor selects STAGE, when a new case or edit is prepared, then a reviewable version is created without altering public data and shows additions, removals, tier/evidence changes, and public wording against current state.
- Given the author signs off, when no second distinct eligible editor approved that exact version, then publication is blocked and the proposer cannot self-approve.
- Given a change removes a record, downgrades evidence, or materially changes claims, when proposed, then second approval is mandatory.
- Given two eligible editors approve and publication occurs, when recorded, then both identities, timestamps, reasons, and published version ID are preserved.
**Design notes:** Bind approval to exact bytes.

#### CAP-3.05 — Immutable editorial history and controlled revert
**Personas:** Rachel Okafor (US-03-07), David Levine (US-04-09), Elena Vidal (US-08-04), Adversary (US-09-01)
**Priority:** P0
**As a reader, attorney, editor, or auditor,** I want attributable versions, field diffs, and controlled reverts so that no historical change can be silently rewritten.
**Acceptance criteria:**
- Given any editorial action occurs, when committed, then append-only history records case, submission/review/tier/correction/merge/source/publication action, verified editor or system actor, role/affiliation, time, affected version and fields, reason, approvals, and supporting source.
- Given public versions differ, when history opens, then field-level additions, deletions, replacements, approvals, and immutable IDs are visible; a cited historical version remains addressable and distinct from current.
- Given protected details cannot be public, when an event is displayed, then content is redacted but action, time, withholding basis, and a verified institutional custodian remain visible while auditable identity is retained privately.
- Given REVERT is chosen, when a rationale is entered, then the prior version is staged as a new proposal, requires two distinct approvals, and preserves the bad edit, intermediate state, rationale, approvals, and result.
- Given an insider attempts to alter record and history, when processed, then independently stored signed checkpoints reveal deletion, insertion, reordering, or hash-chain break and alert reviewers.
**Design notes:** Link public and forensic event identity.

#### CAP-3.06 — Private editorial notes
**Personas:** Elena Vidal (US-08-07), Adversary (US-09-05)
**Priority:** P0
**As an editor,** I want clearly isolated private notes so that verification context is preserved without leaking to any public surface.
**Acceptance criteria:**
- Given an authorized editor saves a note, when stored, then it is labeled non-public with author and timestamp.
- Given a case is staged, previewed, published, exported, indexed, cached, backed up, or read through a public API, when public content is generated, then note text and metadata are excluded.
- Given an unauthenticated or unauthorized user guesses a note identifier, when requested, then access is denied without confirming existence and the attempt is logged where appropriate.
- Given note text is moved into proposed public wording, when staged, then the diff exposes it and normal two-editor approval applies.
**Design notes:** Enforce a notes data boundary.

### 4. Right of reply & dispute resolution

Challenges must be timely, evidence-based, human-reviewed, and appealable while preserving the registry’s independent account and historical record.

#### CAP-4.01 — Cross-party correction and dispute intake
**Personas:** Adrian Marks (US-02-10), Rachel Okafor (US-03-03), Elena Vidal (US-08-08), Nia Delacroix (US-10-01)
**Priority:** P0
**As a family member, journalist, or vendor representative,** I want a formal correction route so that I can challenge specific claims even when I did not submit the case.
**Acceptance criteria:**
- Given I identify challenged fields, proposed correction/removal, explanation, and evidence, when authenticated or privately relationship-verified as appropriate, then a trackable case number and timestamped receipt open review without silent overwrite or false implication of consent.
- Given review is pending, when I inspect it, then case, reporter type, claims, evidence, status, owner, and response deadline are visible to authorized parties; a neutral public notice may mark challenged material without exposing identity or evidence.
- Given the published service level is five business days, when it expires, then vendor counsel receives a reasoned decision or documented extension with reason and new deadline.
- Given review affects safety, legal exposure, publication, or tier, when escalated, then a senior reviewer, reason, and priority are recorded.
- Given accepted, rejected, or partial, when closed, then evidence, rationale, public changes, tier impact, identities, timestamps, preserved prior attribution, and a route to further evidence or reconsideration are recorded and communicated plainly.
**Design notes:** Share lifecycle; vary assurance and privacy.

#### CAP-4.02 — Confidential evidence-based vendor disputes
**Personas:** Elena Vidal (US-08-08), Nia Delacroix (US-10-02)
**Priority:** P0
**As vendor counsel,** I want a substantive dispute reviewed by an editor so that contested findings are qualified without disclosing privileged correspondence.
**Acceptance criteria:**
- Given I identify each finding and upload evidence, when received, then the submission is preserved, acknowledged, and the finding is marked disputed under public policy while review is pending.
- Given evidence is designated internal legal correspondence, when submitted, then only authorized reviewers may access it and it is not quoted, summarized, or published without explicit consent.
- Given review completes, when decided, then audit history identifies an editor or stable staff ID, timestamp, evidence considered, actions, and reasoned outcome and proves an editor—not automation alone—reviewed it.
**Design notes:** Do not leak confidential dispute evidence.

#### CAP-4.03 — Published vendor and official right of reply
**Personas:** Nia Delacroix (US-10-03), Marcus Reddick (US-11-08)
**Priority:** P0
**As an affected vendor or issuing official,** I want an attributable reply beside the record so that readers see later positions without overwriting history.
**Acceptance criteria:**
- Given a vendor response meets published length, relevance, and safety rules, when processed, then it appears on the same page, dated and clearly vendor-attributed, without replacing the entry.
- Given any response is rejected or redacted, when notified, then exact policy grounds and a cure or challenge route are supplied.
- Given a later inquest, appeal, or authority changes an official finding, when the instrument is submitted, then an expedited official pathway links an attributable reply to both determinations.
- Given an original finding is superseded, when viewed or exported, then status and later determination are prominent while historical record remains.
**Design notes:** Replies are not findings.

#### CAP-4.04 — Vendor pre-publication notice
**Personas:** Rachel Okafor (US-03-02), Elena Vidal (US-08-05), Nia Delacroix (US-10-04)
**Priority:** P0
**As vendor counsel,** I want 72-hour notice of vendor-tagged cases so that material errors can be raised before publication.
**Acceptance criteria:**
- Given a draft tags a registered vendor, when ready, then designated counsel receives proposed factual assertions, tags, evidence references, and scheduled time at least 72 hours before publication.
- Given a response arrives in time, when publication occurs, then an editor has reviewed it and records whether and how it affected the entry.
- Given an imminent-public-interest exception applies, when publishing early, then a specific rationale, approving editor, exception marker, and notice as soon as practicable are recorded.
- Given a case is embargoed, sealed, or awaiting family consent, when vendor notice would reveal it, then unauthorized existence and hold reasons remain nonpublic pending an explicit policy decision.
**Design notes:** Define confidentiality and urgency exceptions.
**Conflicts:** [CONFLICT: Nia Delacroix US-10-04 vs Rachel Okafor US-03-02 / Elena Vidal US-08-05] Notice can breach confidential holds or delay urgent publication.

#### CAP-4.05 — Reasoned appeal and independent reconsideration
**Personas:** Adrian Marks (US-02-10), Nia Delacroix (US-10-05)
**Priority:** P0
**As a challenger,** I want a reasoned appeal to an independent reviewer so that an adverse first decision can be intelligibly reconsidered.
**Acceptance criteria:**
- Given a dispute is denied or partial, when delivered, then every challenged finding cites the versioned policy, evidentiary threshold, and entry-specific reasoning.
- Given I appeal within the deadline and state grounds, when acknowledged, then it routes to an editor or panel not responsible for the initial decision.
- Given appeal concludes, when issued, then I receive reasoned outcome, evidence considered, resulting changes, public-change record, and whether further review exists.
**Design notes:** Define recusal, assignment, and quorum.

#### CAP-4.06 — Vendor-page amicus context
**Personas:** Nia Delacroix (US-10-06)
**Priority:** P2
**As vendor counsel,** I want to submit broader vendor-page context so that a cross-case position can be preserved outside individual corrections.
**Acceptance criteria:**
- Given an authenticated representative supplies attribution and disclosures, when submitted, then it is acknowledged and reviewed under content-neutral published rules.
- Given accepted, when the vendor page opens, then a clearly labeled vendor-submitted section shows publication date and version history.
- Given rejected or edited, when notified, then the policy basis and correction or appeal path are provided.
**Design notes:** Prevent implied WHO endorsement.

#### CAP-4.07 — Hoax takedown and scientific retraction
**Personas:** Prof. Kenji Tanaka (US-06-10), Nia Delacroix (US-10-07)
**Priority:** P0
**As a reader, researcher, or affected party,** I want false or overturned cases removed from current use without erasing correction history.
**Acceptance criteria:**
- Given credible hoax evidence arrives, when received, then expedited review is flagged and acknowledged with a deadline; once editorially confirmed, substantive content leaves listings/search within 24 hours.
- Given an academic review overturns a finding, when adjudicated, then a machine-readable retracted status records date, rationale, authority, and superseding evidence and excludes it from default current counts.
- Given the stable URL is resolved, when takedown or retraction applies, then a minimal tombstone and auditable reason remain without repeating fabricated allegations unless law or safety requires no notice.
- Given an older immutable snapshot included the case, when retrieved, then files remain unchanged but a linked correction notice explains later status.
- Given later exports and archive deposits publish, when generated, then stable ID and changed status remain machine-detectable.
**Design notes:** Use distinct tombstone statuses.

#### CAP-4.08 — Reviewer expertise, conflicts, and recusal
**Personas:** Prof. Kenji Tanaka (US-06-09), Nia Delacroix (US-10-08)
**Priority:** P1
**As a disputing party or researcher,** I want visible expertise and conflict controls so that governance and reviewer independence can be assessed.
**Acceptance criteria:**
- Given I inspect responsible editors, when governance metadata opens, then roles, expertise, affiliations, declared interests, recusal categories, and ORCID-compatible identities appear subject to privacy protections.
- Given I allege a specific reviewer conflict with supporting information, when submitted, then an unconflicted decision-maker assesses it before substantive review continues.
- Given decided, when communicated, then retained/replaced status and reason are provided without protected personal information.
- Given a release is inspected, when assessing conflicts, then dated editorial, institutional, and funder declarations—including explicit none—are available.
**Design notes:** Balance accountability with staff safety.

#### CAP-4.09 — Coordinated class review
**Personas:** Nia Delacroix (US-10-10)
**Priority:** P1
**As vendor counsel,** I want coordinated review of a defined entry class so that shared errors receive consistent remedies.
**Acceptance criteria:**
- Given representative entries, class criteria, and common evidence are submitted, when received, then one case number is issued and editors decide coordinated-review eligibility.
- Given accepted, when scope is set, then included entries, common question, status, and exceptions are visible to authorized counsel.
- Given a common issue is final, when remedied, then changes are consistently recorded per entry and different treatment is explained.
- Given denied, when reasons issue, then individual disputes and appeal of class-review denial remain available.
**Design notes:** Retain case-specific safeguards.

### 5. Security & integrity (anti-tamper, anti-hoax, anti-inflation)

These are positive security requirements derived from attack stories: The Record must remain public and machine-usable without allowing outsiders, insiders, or compromised dependencies to corrupt, expose, or disable it.

#### CAP-5.01 — Tamper-evident canonical corpus and counts
**Personas:** Elena Vidal (US-08-03, US-08-04), Adversary (US-09-01, US-09-02)
**Priority:** P0
**As a corpus custodian,** I want independently verifiable records, approvals, and feeds so that deletion, tier inflation, or count manipulation is detectable and prevented.
**Acceptance criteria:**
- Given a record is edited, reverted, unpublished, removed, or downgraded, when processed, then every version, actor, reason, time, and approval remains recoverable; high-impact action requires an independent second approver.
- Given record and audit history are attacked together, when checkpoints are verified, then independently stored signatures expose insertion, deletion, reordering, or hash-chain breaks and alert responders.
- Given a case, tier promotion, or observation lacks reviewable evidence, provenance, canonical linkage, or approval, when counts and feeds build, then it is excluded and public state is unchanged.
- Given a consumer verifies a count/feed, when following its signed manifest, then every item resolves to a stable canonical record in the reviewed dataset version.
**Design notes:** Signed release checkpoints complement, rather than replace, transactional controls and separation of duties.

#### CAP-5.02 — Privacy review and anti-reidentification
**Personas:** Adrian Marks (US-02-02, US-02-04), Adversary (US-09-04), Marcus Reddick (US-11-04)
**Priority:** P0
**As a protected person or submitter,** I want identifiers and correlating metadata minimized so that public records cannot reveal unnamed victims, relatives, or sources.
**Acceptance criteria:**
- Given names, contacts, IP-derived data, file metadata, precise place, or quasi-identifiers exist, when publishing, then documented privacy review removes/generalizes them and suppresses risky combinations and correlatable receipt, queue, reviewer, or publication timing.
- Given an official document identifies a protected person, when public material is created, then redaction covers preview, extracted text, structured fields, index, and exports; the official can confirm, add, or correct redactions first.
- Given lawful unredacted access occurs, when opened, then authorization is limited and logged while public output remains redacted.
**Design notes:** Authorized audit records should explain restriction without reproducing the identifying combination.

#### CAP-5.03 — Sensitive-object isolation and egress control
**Personas:** Adrian Marks (US-02-03), Elena Vidal (US-08-06, US-08-07), Adversary (US-09-05)
**Priority:** P0
**As a source or editor,** I want sensitive attachments and notes isolated so that guessing identifiers, compromised accounts, or abnormal downloads cannot exfiltrate them.
**Acceptance criteria:**
- Given an unauthenticated or out-of-scope user requests a private object, when server authorization runs, then access is denied without confirming existence and the attempt is recorded.
- Given sensitive content touches storage, delivery, logs, caches, exports, backups, or temporary links, when inspected, then it is encrypted, non-indexed, and available only through short-lived scoped authorization.
- Given an account enumerates or downloads abnormally, when rate, volume, or pattern thresholds cross, then bulk egress stops or is challenged and responders are alerted.
**Design notes:** Role plus case assignment, not authentication alone, governs access.

#### CAP-5.04 — Abuse-resistant public and write availability
**Personas:** RAVI-1 (US-07-08, US-07-09), Adversary (US-09-06, US-09-07)
**Priority:** P0 (source priorities P0/P1)
**As a legitimate reader, agent, submitter, or editor,** I want bounded, resilient service paths so that floods and aggressive scraping cannot deny access.
**Acceptance criteria:**
- Given distributed read floods or expensive/unbounded queries occur, when limits trigger, then cached records remain edge-available, abusive traffic is throttled, origin work is bounded, and coordinated rotation is assessed across token, account, network, and behavior.
- Given sanctioned feeds/exports are used, when legitimate systematic access occurs, then stable quotas expose only approved public data without degrading interactive reads.
- Given write/upload thresholds, size/type/count/storage quotas, or dependency backpressure trigger, when requests arrive, then cheap validation rejects or queues before expensive work and accepted submissions receive idempotent receipts.
- Given intake is attacked, when protected editorial mutations occur, then isolated capacity and authorization keep the editorial path available; retries do not duplicate submissions.
**Design notes:** Controls must reconcile open automated access with availability and privacy, using documented sanctioned bulk paths.
**Conflicts:** [CONFLICT: RAVI-1 US-07-08/09 vs Adversary US-09-06] Unchallenged headless reads and practical bulk reconciliation increase scraping and exhaustion risk; controls must be machine-readable and non-CAPTCHA while still behavioral and bounded.

#### CAP-5.05 — Secure privileged identity and sessions
**Personas:** Dr. Priya Suresh (US-05-07), Adversary (US-09-08)
**Priority:** P0
**As an administrator or official submitter,** I want phishing-resistant authentication and revocable sessions so that passwords or stolen tokens cannot authorize protected actions.
**Acceptance criteria:**
- Given credential stuffing occurs, when signing in, then rate/reputation controls apply and a password alone cannot authenticate an editor.
- Given a token appears on an anomalous client, when used for sensitive reads or writes, then fresh authentication is required and the owner or security team is alerted.
- Given browser attacks target a session, when attempted, then TLS, hardened cookies, origin and CSRF protections prevent disclosure or action.
- Given compromise or departure occurs, when access is revoked, then sessions, refresh tokens, and pending privileged actions promptly fail.
**Design notes:** Assurance levels should be explicit for editor, ministry, vendor, family, and official roles.

#### CAP-5.06 — Supply-chain resilience, backup, and recovery
**Personas:** Adversary (US-09-09)
**Priority:** P0
**As an operator,** I want controlled builds and isolated recovery so that malicious dependencies or ransomware cannot destroy the registry and its evidence.
**Acceptance criteria:**
- Given a direct or transitive dependency changes, when building, then lockfiles, integrity checks, review policy, and reproducible-build checks block unexpected code.
- Given malicious code runs, when constrained, then least privilege, egress limits, and separated production, secret, and backup planes prevent broad access and backup destruction.
- Given data is encrypted, corrupted, or deleted, when response starts, then an integrity-checked point-in-time copy restores within documented objectives.
- Given scheduled clean-environment restore tests run, when completed, then versions, evidence references, audit continuity, and required secrets are verified and failures reported.
**Design notes:** Recovery objectives and evidence-integrity checks are part of release governance.

#### CAP-5.07 — Untrusted content and model isolation
**Personas:** Adversary (US-09-10, US-09-11)
**Priority:** P0 (source priorities P0/P1)
**As a reader or editor,** I want submitted text, links, files, and model inputs treated as hostile data so that active content and prompt injection cannot execute or mutate records.
**Acceptance criteria:**
- Given text contains scripts or dangerous markup, when rendered, then encoding or allowlist sanitization makes it inert; URLs are normalized, safely attributed, stripped of misleading/control content, and unsafe schemes rejected.
- Given a purported PDF contains invalid structure, embedded actions, attachments, or active payload, when scanned, then it is quarantined; accepted files open from an isolated origin or safe conversion with restrictive browser controls.
- Given corpus text addresses a model, when analyzed, then it remains delimited untrusted evidence and cannot override instructions, tools, or rights; least-privilege policy denies and records induced access to secrets, private data, tools, or unapproved destinations.
- Given model output proposes a tier, citation, publication, or mutation, when schema/evidence/human approval is absent, then canonical data cannot change and unreviewed output remains segregated from verified facts.
**Design notes:** Model assistance cannot satisfy the independent human approval requirement.

#### CAP-5.08 — Resilient authentic distribution and domain lifecycle
**Personas:** Adversary (US-09-12)
**Priority:** P0
**As a reader or machine consumer,** I want alternate verifiable distribution so that censorship or domain takeover cannot substitute a counterfeit corpus.
**Acceptance criteria:**
- Given the primary path is regionally blocked, when legally and operationally feasible, then maintained alternatives or signed downloadable snapshots expose the approved public dataset.
- Given a mirror serves content, when retrieved, then signatures and canonical identity metadata distinguish authentic bytes.
- Given a subdomain or host retires, when resources change, then dangling DNS is removed before release and cannot be reclaimed.
- Given DNS, certificates, or content change unexpectedly, when continuously monitored, then maintainers are alerted, routes can be disabled, and issuance/deployment requires controlled authorization.
**Design notes:** Alternate channels need a published trust root and key-rotation process.

### 6. Machine-readable API & agent access

The public machine interface is a first-class product: discoverable, versioned, cache-efficient, bounded, and free of human-only challenges.

#### CAP-6.01 — Well-known discovery and OpenAPI contract
**Personas:** RAVI-1 (US-07-01)
**Priority:** P0
**As an autonomous agent,** I want a well-known capability document so that I can integrate without scraping pages.
**Acceptance criteria:**
- Given only the origin, when I request `/.well-known/the-record.json`, then JSON identifies canonical API, export, schema, feed, health, and OpenAPI URLs.
- Given I follow the contract URL, when fetched, then valid OpenAPI 3.1 describes every public read endpoint and response.
- Given a capability moves, when discovery is fetched, then replacement URL and migration guidance appear.
**Design notes:** Discovery itself must remain stable, cacheable, and minimally dependent.

#### CAP-6.02 — Complete streaming canonical export
**Personas:** RAVI-1 (US-07-02), Prof. Kenji Tanaka (US-06-01)
**Priority:** P0
**As a machine consumer,** I want the complete canonical public dataset in efficient JSON so that I can reconcile evidence without pagination loss.
**Acceptance criteria:**
- Given the full-export endpoint or published snapshot is requested, when successful, then every current publicly releasable canonical record and field—not a sample—appears with stable IDs, dataset/schema version, generation time, encoding, record count, and checksum.
- Given the response is large, when streaming is requested, then JSON Lines or another documented streaming JSON format is used.
- Given Brotli or gzip is accepted and appropriate, when returned, then `Content-Encoding` and `Vary` are correct.
**Design notes:** Current canonical export and immutable release snapshots must be distinct resources.

#### CAP-6.03 — Versioned schemas, API, and deprecation
**Personas:** RAVI-1 (US-07-03, US-07-07), Prof. Kenji Tanaka (US-06-01)
**Priority:** P0
**As an API client,** I want resolvable schemas and semantic versions so that contract changes cannot silently break ingestion.
**Acceptance criteria:**
- Given the stable schema URL is fetched, when successful, then a valid self-identifying JSON Schema describes the canonical entry and each declared version resolves to an immutable retained URL.
- Given schema fields change, when released, then machine schema and migration notes enumerate additions, removals, renames, and type changes; incompatible change uses semantic versioning.
- Given an API endpoint responds, when inspected, then its major API and full contract version are knowable; breaking change uses a new major while the prior remains for its support period.
- Given a version or field is deprecated, when used, then documentation and machine headers identify successor, migration instructions, sunset date, and removal policy.
**Design notes:** Dataset, schema, vocabulary, and API versions should not be conflated.

#### CAP-6.04 — Conditional retrieval and incremental change feed
**Personas:** RAVI-1 (US-07-04, US-07-05, US-07-06)
**Priority:** P0 (source priorities P0/P1)
**As an agent,** I want validators, events, and diffs so that I process only changed data without gaps.
**Acceptance criteria:**
- Given an export, entry, feed, schema, or discovery response, when delivered, then it includes `ETag`, meaningful `Last-Modified`, or both; valid conditional requests return bodyless `304`, while changed resources return `200` and new validators.
- Given entries change, when Atom/RSS is fetched, then stable event/entry IDs, timestamps, change types, version and diff links appear; conditional polling and documented pagination/archive traversal cover the retention window without gaps or duplicates.
- Given two valid entry versions are supplied, when diff is requested, then machine-readable added/removed/changed fields exactly match that transition and link immutable versions.
- Given an entry/version is absent, when requested, then documented JSON `404` or `410` replaces HTML.
**Design notes:** Feed retention and consumer checkpoint behavior need explicit operational guarantees.

#### CAP-6.05 — Headless access and transparent limits
**Personas:** RAVI-1 (US-07-08, US-07-09), Adversary (US-09-06)
**Priority:** P0 (source priorities P0/P1)
**As an autonomous public client,** I want permitted challenge-free reads and legible quotas so that unattended retrieval works safely.
**Acceptance criteria:**
- Given I inspect `/robots.txt` and `/ai.txt`, when fetched, then public API/export/schema/feed/discovery permissions and restrictions are explicit.
- Given a compliant headless client stays within published limits, when it reads public paths, then no CAPTCHA, JavaScript challenge, cookie wall, login, or bot interstitial blocks it.
- Given restriction or denial occurs, when returned, then a machine-readable HTTP error—not human redirect—explains it.
- Given any public response, when received, then limit, remaining allowance, and reset headers are documented; routine polling/bulk reconciliation can complete unattended, and excess returns `429`, machine error, and accurate `Retry-After`.
**Design notes:** See CAP-5.04 for the explicit openness-versus-abuse conflict.
**Conflicts:** [CONFLICT: RAVI-1 US-07-08/09 vs Adversary US-09-06] Challenge-free automation must coexist with aggregate behavioral rate controls and a sanctioned bulk path.

#### CAP-6.06 — Public API widget and graceful failure
**Personas:** Rachel Okafor (US-03-05)
**Priority:** P2
**As a journalist,** I want a public API suitable for a case-list widget so that embedded information stays current.
**Acceptance criteria:**
- Given the API is filtered by vendor, product, harm type, jurisdiction, or stable ID, when queried, then machine-readable public cases include canonical URLs and update timestamps.
- Given a case changes, when the widget refreshes, then current data returns without embed-code changes.
- Given the API is unavailable, limited, or empty, when the widget loads, then an accessible status and registry link replace misleading stale or empty output.
**Design notes:** Embeds should identify freshness and avoid copying restricted presentation fields.

### 7. Academic / regulatory export

Research and policy use requires complete, versioned, interpretable, reproducible artifacts with lawful restrictions stated rather than hidden.

#### CAP-7.01 — Complete exports, dictionary, and transfer packages
**Personas:** Rachel Okafor (US-03-09), David Levine (US-04-11), Prof. Kenji Tanaka (US-06-01, US-06-04)
**Priority:** P0 (source priorities P0/P1/P2)
**As a journalist, attorney, or researcher,** I want documented JSON/CSV and domain packages so that public data can be reused without semantic loss.
**Acceptance criteria:**
- Given I export filtered/selected cases or a full snapshot, when generated, then all matching releasable records include normalized case, docket, vendor, court, theory, source, permalink, snapshot, stable ID, export time, query, and file hash; policy-omitted fields are documented.
- Given CSV values resemble formulas or risk precision loss, when encoded, then spreadsheet execution is prevented and identifiers/dates retain documented formats.
- Given a field appears, when looked up, then the dictionary gives name, label, definition, datatype, values, unit, null meaning, derivation, sensitivity, vocabulary/schema versions, and meaning changes.
- Given REDCap or DSpace is requested, when built, then data and mappings preserve names, types, labels, vocabularies, provenance, and dataset version.
**Design notes:** Exports must apply the same disclosure controls as UI and API.

#### CAP-7.02 — Immutable signed dataset releases and repositories
**Personas:** Dr. Priya Suresh (US-05-08), Prof. Kenji Tanaka (US-06-03, US-06-08)
**Priority:** P0 (source priorities P0/P1)
**As a researcher or regulator,** I want signed immutable snapshots with persistent IDs so that cited data remains independently retrievable.
**Acceptance criteria:**
- Given a weekly/versioned release occurs, when published, then it receives persistent version ID/DOI, UTC timestamp, dataset/schema versions, changelog, checksums, verifiable signature, key-rotation documentation, and immutable files; concept ID discovers latest and prior releases.
- Given citation is generated, when used, then version, access date, and version-specific identifier appear; retrieving an older release returns its data/methodology plus linked later corrections without altering it.
- Given archival workflow completes, when depositing to Zenodo, Figshare, OSF, or equivalent, then data, schema, dictionary, methodology, license, citation, checksums, and replication materials match WHO release IDs and hashes.
- Given a repository is unavailable, when release occurs, then delay/status and retry or alternate repository are disclosed.
**Design notes:** Signatures authenticate bytes; DOI persistence and repository custody address availability.

#### CAP-7.03 — Reproducible counts and independent audit
**Personas:** Dr. Priya Suresh (US-05-05), Prof. Kenji Tanaka (US-06-07)
**Priority:** P0
**As an auditor or research team,** I want an end-to-end provenance package so that published counts can be independently rebuilt.
**Acceptance criteria:**
- Given a count/snapshot is selected, when provenance is requested, then case IDs, source manifests, screening/inclusion states, tiers, deduplication, adjudication, query/script, parameters, transformations, dependencies, expected output, and dataset/schema/vocabulary versions support reconstruction.
- Given materials may lawfully be shared, when an authorized auditor follows the guide, then counts and hashes reproduce.
- Given restrictions prevent exact reproduction, when inspected, then unavailable sources, legal basis, affected cases, stable citation, lawful hash/attestation, limitation, and closest auditable procedure are explicit without claiming full reproducibility.
- Given an auditor disputes a case or aggregate, when filed, then a trackable ID, conflict declaration, disposition, and link to correction or unresolved dissent are retained.
**Design notes:** Reproducibility claims must be scoped to the auditor’s lawful access.

#### CAP-7.04 — Harm mechanisms and health-code mappings
**Personas:** Dr. Priya Suresh (US-05-04)
**Priority:** P0
**As a public-health reviewer,** I want harm mechanisms mapped to health standards so that Member States can connect this registry to morbidity and mortality systems.
**Acceptance criteria:**
- Given mechanism filters apply, when results return, then self-harm, violence toward others, and psychiatric harm have separate published definitions, allow multiple labels, and leave ambiguity unclassified.
- Given a case is coded, when inspected, then applicable ICD-10-CM/ICD-11 morbidity or external-cause codes, rationale, provenance, confidence, and release are shown.
- Given existing codes are inadequate, when guidance opens, then a versioned non-normative supplemental agent/context proposal includes mappings, examples, limits, and governance status.
**Design notes:** Supplemental mappings must not masquerade as WHO-adopted normative codes.

#### CAP-7.05 — WHO framework crosswalks
**Personas:** Dr. Priya Suresh (US-05-06)
**Priority:** P1
**As a regulator,** I want versioned crosswalks to reportable-event frameworks so that duplication, gaps, and non-equivalent terms are visible.
**Acceptance criteria:**
- Given a WHO framework is selected, when compared, then concepts, minimum fields, seriousness/causality criteria, timelines, governance roles, and unmatched elements are mapped.
- Given similar terms differ, when inspected, then thresholds and meanings are explicit and not labeled equivalent.
- Given exported, when a Member State assesses adoption, then machine mappings and human gap analysis cite edition and effective date.
**Design notes:** Crosswalk version must bind to both framework and registry schema versions.

#### CAP-7.06 — FAIR and jurisdiction-aware stewardship
**Personas:** Dr. Priya Suresh (US-05-10), Prof. Kenji Tanaka (US-06-09)
**Priority:** P0 (source priorities P0/P1)
**As a steward or reuser,** I want reusable licensed metadata under machine-enforced sovereignty controls so that openness does not violate national law.
**Acceptance criteria:**
- Given a dataset is assessed, when inspected, then findability, conditional accessibility, interoperable standards, and reuse provenance, licensing, versioning, and guidance are documented; dataset rights are distinguished from third-party source rights and attribution/share-alike/modification terms are explicit.
- Given a document may not leave a jurisdiction, when processed, then it stays in approved locality and only authorized metadata, aggregates, hashes, or attestations cross borders by default.
- Given restricted data touches UI, API, export, audit, analytics, backup, or replicas, when rules prohibit transfer/disclosure, then identical controls identify legal basis, steward, and review route.
- Given localization, retention, or transfer law changes, when versioned policy takes effect, then affected records/replicas are identified and auditable localization, retention, or deletion follows.
**Design notes:** Policy enforcement must travel with derived artifacts, not stop at primary storage.

### 8. Legal citation & permalink stability

Legal users need current and historical records to remain distinguishable, addressable, and authenticatable even after edits, merges, removals, or superseding decisions.

#### CAP-8.01 — Stable case permalinks and historical versions
**Personas:** Sarah Chen (US-01-07), Rachel Okafor (US-03-06, US-03-07), David Levine (US-04-01)
**Priority:** P0
**As a reader, journalist, or attorney,** I want stable current and snapshot URLs so that sharing and citation survive changes.
**Acceptance criteria:**
- Given a case URL is copied, when opened publicly, then that case, citations, current tier, and last-updated date load without account.
- Given tier/URL scheme changes or duplicates merge, when an old URL resolves, then permanent redirect preserves stable ID and reaches current canonical page.
- Given ordinary display removes a case, when its permalink opens, then a durable non-sensitive notice replaces a generic broken page.
- Given Bluebook/OSCOLA citation is generated, when copied, then case/court/docket, permanent URL, access date, and snapshot ID match display; that ID retrieves exact cited and current versions.
**Design notes:** Canonical redirects must not erase direct addressability of immutable historical versions.

#### CAP-8.02 — Date-specific evidentiary snapshots and matter sets
**Personas:** David Levine (US-04-02, US-04-06)
**Priority:** P0 (source priorities P0/P1)
**As an attorney,** I want authenticated date-specific evidence and matter sets so that later registry edits cannot alter filed work product.
**Acceptance criteria:**
- Given I select a date, when downloading, then a read-only package contains then-available record/attachments and a manifest of case, timestamp, snapshot ID, source URLs, files, and hashes; the same ID reproduces bytes and verification result.
- Given I flag a case, fact, source, or snapshot, when assigning it to a matter, then I may add relevance, issue, and privilege notes.
- Given authorized teammates inspect the set, when viewed, then flagger, time, supporting snapshot, and review status appear; later public changes are shown separately while flagged snapshot stays fixed.
**Design notes:** Matter notes are private legal workspace data and need controls distinct from the public registry.

#### CAP-8.03 — Court-ready appendix and research-platform transfer
**Personas:** David Levine (US-04-08)
**Priority:** P1
**As an attorney,** I want formatted appendices and citation transfer so that registry research fits filing workflows.
**Acceptance criteria:**
- Given cases are selected, when Bluebook/OSCOLA appendix exports, then contents, sequential exhibit labels, citations, URLs, access dates, snapshot IDs, and sources appear; oversized output splits into indexed volumes without renumbering.
- Given LexisNexis or Westlaw transfer occurs, when mapped, then supported citations/dockets transfer and unsupported items remain citation-ready links.
- Given transfer completes, when reported, then successes, failures, and unmatched platform records are visible.
**Design notes:** Third-party integration must not imply those platforms authenticate registry content.

#### CAP-8.04 — Official cross-jurisdiction interoperability
**Personas:** Marcus Reddick (US-11-09, US-11-10)
**Priority:** P1
**As an official-source user,** I want jurisdiction profiles and versioned exports so that legal terminology survives exchange.
**Acceptance criteria:**
- Given UK, US, or Australian official records are imported, when mapped, then the applicable profile preserves source IDs/terms and reports unmapped fields.
- Given an authorized registry requests export, when supplied, then documented machine data contains structured fields, provenance, hashes, redaction, versions, and original-text links.
- Given a receiver validates it, when checking schema/integrity, then missing required fields, altered content, and profile are identifiable.
- Given any field, redaction, translation, attachment, or status changes, when history opens, then time, actor/authority, reason, prior/current value, unchanged original text, and links from earlier versions to superseding findings appear.
**Design notes:** Jurisdiction profiles express mapping limitations and never normalize away controlling language.

### 9. Internationalization & accessibility

Language, disability, device, and bandwidth must not change the perceived evidentiary status or block participation.

#### CAP-9.01 — Meaning-preserving multilingual content and intake
**Personas:** Sarah Chen (US-01-10), Adrian Marks (US-02-09), Dr. Priya Suresh (US-05-09), Elena Vidal (US-08-10), Marcus Reddick (US-11-07)
**Priority:** P1 (source priorities P1/P2)
**As an international reader, submitter, official, or reviewer,** I want traceable translations and qualified review so that another language does not displace authoritative text.
**Acceptance criteria:**
- Given a supported language is chosen, when navigating or submitting, then navigation, guidance, consent/privacy choices, help, status, and available record content switch consistently; unavailable language offers human support.
- Given content is translated, when shown, then source language, lawful original reference, method, human/model provenance, date, confidence, terminology notes, official/human-reviewed/automated status, and controlling original link are visible; untranslated content is labeled, not silently omitted or asserted authoritative.
- Given ambiguity or culturally specific concepts exist, when versions compare, then alternatives remain and human adjudication precedes equivalence; mistranslation correction can be requested.
- Given non-English evidence enters review, when detected, then source/target language, priority, assignee, translator, model assistance, and reviewer decision enter a translation queue; material unresolved text blocks publication where policy requires.
- Given original text changes, when a translation no longer matches, then it is marked outdated until updated, reviewed, linked in history, and two-editor approved.
**Design notes:** Translation status is provenance and must survive UI, export, and API transformations.

#### CAP-9.02 — Accessible, mobile, and low-bandwidth service
**Personas:** Sarah Chen (US-01-08, US-01-09), Dr. Priya Suresh (US-05-09)
**Priority:** P0 (source priorities P0/P2)
**As a user with a phone, disability, or limited connection,** I want equivalent access so that evidence does not depend on precision touch, sight, motion, or heavy downloads.
**Acceptance criteria:**
- Given a narrow screen or touch, when browsing, filtering, citing, or sharing, then no horizontal scroll is needed, targets are distinct, and return from a citation preserves position/filters where practical.
- Given keyboard, screen reader, magnification, high contrast, or reduced motion is used, when accessing pages, charts, tables, forms, and downloads, then logical headings/landmarks/order, meaningful labels/status, visible focus, text alternatives, accessible trend tables, UN requirements, and WCAG 2.2 AA apply.
- Given bandwidth is low, when a record loads, then essential text, status, update date, citations, and nonvisual status equivalents do not require large media.
**Design notes:** Accessibility acceptance testing must cover generated downloads and embedded widgets, not only pages.

### 10. Administration & operations

Operational controls must keep contributors informed, reviewers sustainable, governance accountable, and public machine clients able to distinguish outage from bad data.

#### CAP-10.01 — Case and saved-search alerts
**Personas:** Adrian Marks (US-02-05), Rachel Okafor (US-03-10), David Levine (US-04-07), Marcus Reddick (US-11-08)
**Priority:** P0 (source priorities P0/P1)
**As a contributor or researcher,** I want configurable, deduplicated alerts so that relevant changes do not silently invalidate my work.
**Acceptance criteria:**
- Given I am family, credited/following reporter, official source, or saved-query owner, when tier, status, source, fact, correction, canonical disposition, annotation, challenge, or matching case changes, then my chosen secure channel identifies case, actor where lawful, matching criteria, changed fields, reason, permalink, and relevant snapshot/diff.
- Given an alert opens, when followed, then it reaches the version diff and audit event, not only current state.
- Given preferences are set, when choosing immediate/daily/weekly, digest, or none by change type, then future delivery honors them without deleting on-site history.
- Given one change matches several searches, when alerts generate, then one notice preserves all matching search names.
**Design notes:** Actor identity in official alerts may need redaction under staff/source safety policy.

#### CAP-10.02 — Editorial throughput and wait-state metrics
**Personas:** Elena Vidal (US-08-09)
**Priority:** P1
**As an editorial director,** I want policy-aligned workflow metrics so that bottlenecks are visible without rewarding weak verification.
**Acceptance criteria:**
- Given work moves through intake, verification, staging, second review, dispute, translation, or hold, when states change, then entry/exit times and optional active work time are recorded.
- Given a period is selected, when metrics load, then counts, median/percentile cycle time, active time, queue age, and throughput by stage/tier distinguish external waiting from active review.
- Given a report exports, when generated, then definitions, period, included states, exclusions, and timestamp accompany aggregates.
**Design notes:** Metrics should not rank individual editors in ways that encourage rushed decisions.

#### CAP-10.03 — Service health, authenticity, and uptime commitment
**Personas:** RAVI-1 (US-07-10)
**Priority:** P1
**As a machine consumer,** I want health and integrity signals so that I can distinguish outages from invalid data.
**Acceptance criteria:**
- Given `/health` is requested unauthenticated, when operational, then lightweight JSON returns `200`, status, API version, and timestamp.
- Given I consult operations documentation, when planning ingestion, then an SLA/SLO defines availability, maintenance, incident communication, and measurement windows.
- Given a public resource is fetched, when delivered, then HTTPS protects it and advertised digests/signatures verify exports and immutable versions.
**Design notes:** Health must not expose internal topology or sensitive dependency status.

#### CAP-10.04 — Maintainer credit, governance, and reuse terms
**Personas:** Prof. Kenji Tanaka (US-06-09), Nia Delacroix (US-10-08)
**Priority:** P1
**As a scholarly or disputing user,** I want accountable governance metadata so that I can credit maintainers and assess decision authority.
**Acceptance criteria:**
- Given I prepare a publication, when credit guidance opens, then roles, recommended acknowledgement, contribution expectations, and a non-coercive substantial-contribution authorship discussion process appear.
- Given editorial identity is inspected, when opened, then board/member ORCIDs or compatible persistent listings, roles, expertise, affiliations, interests, and recusal categories are available subject to safety/privacy.
- Given data is reused, when license terms are read, then dataset versus third-party rights and attribution, share-alike, modification, and redistribution obligations are explicit.
**Design notes:** This capability governs public accountability; privileged access administration remains separately secured.

## Cross-persona matrix

`X` means the persona has at least one cited source story in the capability. Persona numbers match the index above.

| Capability | 01 Sarah | 02 Adrian | 03 Rachel | 04 David | 05 Priya | 06 Kenji | 07 RAVI | 08 Elena | 09 Adversary | 10 Nia | 11 Marcus |
|---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|
| CAP-1.01 | X | | | | | | | | | | |
| CAP-1.02 | X | | | | | | | | | | |
| CAP-1.03 | X | | | X | | X | | | | | X |
| CAP-1.04 | X | | | X | | X | | | | | X |
| CAP-1.05 | | | | | X | X | | | | | |
| CAP-1.06 | X | | | | | | | | | | |
| CAP-1.07 | | X | | | | | | | | | |
| CAP-2.01 | X | X | | | | | | | | | |
| CAP-2.02 | | X | | | | | | | | | |
| CAP-2.03 | | X | | | | | | | X | | |
| CAP-2.04 | | X | | X | | | | X | | | X |
| CAP-2.05 | | X | | | | | | | | | |
| CAP-2.06 | | X | | | | | | | | | |
| CAP-2.07 | | | X | | | | | | X | | |
| CAP-2.08 | | | X | | | | | X | | | |
| CAP-2.09 | | | X | | | | | | | | |
| CAP-2.10 | | | | | X | | | | | | X |
| CAP-2.11 | | | | | | | | | | | X |
| CAP-3.01 | X | | X | | X | X | | | | X | |
| CAP-3.02 | | | | | | | | X | X | | |
| CAP-3.03 | | | | | | | | X | X | X | X |
| CAP-3.04 | | | | | | | | X | X | | |
| CAP-3.05 | | | X | X | | | | X | X | | |
| CAP-3.06 | | | | | | | | X | X | | |
| CAP-4.01 | | X | X | | | | | X | | X | |
| CAP-4.02 | | | | | | | | X | | X | |
| CAP-4.03 | | | | | | | | | | X | X |
| CAP-4.04 | | | X | | | | | X | | X | |
| CAP-4.05 | | X | | | | | | | | X | |
| CAP-4.06 | | | | | | | | | | X | |
| CAP-4.07 | | | | | | X | | | | X | |
| CAP-4.08 | | | | | | X | | | | X | |
| CAP-4.09 | | | | | | | | | | X | |
| CAP-5.01 | | | | | | | | X | X | | |
| CAP-5.02 | | X | | | | | | | X | | X |
| CAP-5.03 | | X | | | | | | X | X | | |
| CAP-5.04 | | | | | | | X | | X | | |
| CAP-5.05 | | | | | X | | | | X | | |
| CAP-5.06 | | | | | | | | | X | | |
| CAP-5.07 | | | | | | | | | X | | |
| CAP-5.08 | | | | | | | | | X | | |
| CAP-6.01 | | | | | | | X | | | | |
| CAP-6.02 | | | | | | X | X | | | | |
| CAP-6.03 | | | | | | X | X | | | | |
| CAP-6.04 | | | | | | | X | | | | |
| CAP-6.05 | | | | | | | X | | X | | |
| CAP-6.06 | | | X | | | | | | | | |
| CAP-7.01 | | | X | X | | X | | | | | |
| CAP-7.02 | | | | | X | X | | | | | |
| CAP-7.03 | | | | | X | X | | | | | |
| CAP-7.04 | | | | | X | | | | | | |
| CAP-7.05 | | | | | X | | | | | | |
| CAP-7.06 | | | | | X | X | | | | | |
| CAP-8.01 | X | | X | X | | | | | | | |
| CAP-8.02 | | | | X | | | | | | | |
| CAP-8.03 | | | | X | | | | | | | |
| CAP-8.04 | | | | | | | | | | | X |
| CAP-9.01 | X | X | | | X | | | X | | | X |
| CAP-9.02 | X | | | | X | | | | | | |
| CAP-10.01 | | X | X | X | | | | | | | X |
| CAP-10.02 | | | | | | | | X | | | |
| CAP-10.03 | | | | | | | X | | | | |
| CAP-10.04 | | | | | | X | | | | X | |

## Priority summary

Priority is the highest among merged source stories; parenthetical source-priority notes appear on capabilities where contributors disagreed.

| Capability area | P0 count | P1 count | P2 count | Total |
|---|---:|---:|---:|---:|
| 1. Public reading & discovery | 5 | 2 | 0 | 7 |
| 2. Submission workflows | 9 | 2 | 0 | 11 |
| 3. Editorial verification & moderation | 6 | 0 | 0 | 6 |
| 4. Right of reply & dispute resolution | 6 | 2 | 1 | 9 |
| 5. Security & integrity | 8 | 0 | 0 | 8 |
| 6. Machine-readable API & agent access | 5 | 0 | 1 | 6 |
| 7. Academic / regulatory export | 5 | 1 | 0 | 6 |
| 8. Legal citation & permalink stability | 2 | 2 | 0 | 4 |
| 9. Internationalization & accessibility | 1 | 1 | 0 | 2 |
| 10. Administration & operations | 1 | 3 | 0 | 4 |
| **All areas** | **48** | **13** | **2** | **63** |

## Open questions surfaced by synthesis

1. What exact case-versus-claim semantics do T1/T2/T3 encode, and how does an official verdict pathway satisfy independent approval without re-adjudicating the finding?
2. Which public fields and timestamp granularity pass reidentification review, and when may a submitter affirmatively opt into first-namer attribution?
3. Which jurisdictions’ erasure, localization, retention, sealed-record, and protected-identity rules govern a case with several relevant locations?
4. What public notice is safe and legally appropriate for withdrawal, retraction, hoax takedown, legal removal, and superseded official findings?
5. How is the 72-hour vendor-notice rule waived or delayed for embargoes, family consent, sealed evidence, source safety, and urgent public interest?
6. Which materials can be redistributed, hashed, attested, or exposed only to authorized auditors, and who decides lawful access?
7. What are the authoritative controlled vocabularies, denominator sources, small-cell thresholds, comparison rules, and supplemental-code governance?
8. What are feed retention, API support periods, quotas, snapshot cadence, uptime/recovery objectives, signing trust root, and key-rotation procedures?
9. What qualifications, independence, recusal, and privacy rules apply to editors, translators, appellate panels, and institutional custodians?
10. Which translation ambiguities block publication, who can attest equivalence, and how quickly must dependent translations be refreshed after source changes?

## Explicit conflicts to resolve in HLD

1. **Attribution vs anonymity:** [CONFLICT: Rachel Okafor US-03-01 vs Adversary US-09-04] Public first-namer/surfacing credit can reveal submission lineage through timing or metadata; attribution must be consented and technically decoupled from confidential intake.
2. **Advance notice vs confidentiality and timeliness:** [CONFLICT: Nia Delacroix US-10-04 vs Rachel Okafor US-03-02 / Elena Vidal US-08-05] A mandatory vendor window can reveal an embargoed, sealed, or family-unapproved case, while urgent public interest may require earlier publication.
3. **Official fast track vs tier safeguards:** [CONFLICT: Marcus Reddick US-11-05 vs Elena Vidal US-08-02 / Adversary US-09-02] Direct T1 assignment and no re-adjudication must coexist with document integrity, privacy, independent approval, and anti-inflation gates.
4. **Open automation vs anti-scraping controls:** [CONFLICT: RAVI-1 US-07-08/09 vs Adversary US-09-06] Challenge-free headless and bulk access can enable exhaustion or commercial scraping; the resolution must retain sanctioned complete access under transparent behavioral limits.
5. **Transparent editor identity vs safety/privacy:** [CONFLICT: David Levine US-04-09 / Rachel Okafor US-03-07 vs Elena Vidal US-08-07 / Adversary US-09-05] Publicly attributable edits improve credibility, but some identity and notes require protected custody; stable public accountability must not expose sensitive staff or verification context.
6. **Immutable history vs deletion/minimization:** [CONFLICT: Adrian Marks US-02-06 vs Rachel Okafor US-03-07 / Prof. Kenji Tanaka US-06-10] Jurisdictional erasure and family withdrawal can require deletion, while legal and scientific users require immutable snapshots and tombstones; retention and public discoverability must be resolved separately.

---