How the archive earns its credibility

Pipeline

How a case enters the archive

1. DiscoveryA new incident is identified via official alert archives, branded X/Twitter handles, student newspapers, local TV coverage, Clery Annual Security Reports, or after-action reviews. Both fresh and historical cases are eligible.
2. VerificationDate, institution, location, casualty counts, and timeline are cross-checked against at least two independent sources before any JSON is written. Building names, street names, and timezones are confirmed against the institution's own materials.
3. AuthorshipThe case file is composed: alert text reproduced verbatim from the strongest available source, every claim in the context and summary fields paired with an inline source link, every alert tagged with its channel, type, and an honest isVerbatimConfirmed flag.
4. ValidationEvery file passes through scripts/validate-cases.mjs, which enforces schema integrity, character-count parity, chronological ordering, slug uniqueness, and ISO date formatting. Cases failing any required rule are rejected before merge.
5. PublicationOn merge to main, the static site rebuilds and the case is live at a permanent URL. The full JSON remains in the open repository so any reader can audit the underlying data.

Editorial standards

Non-negotiable rules

Five rules govern every case in this archive. They are reproduced verbatim from the project's editorial guide and any case that violates one is corrected or removed.

1. 01
   Preserve all typos.“shots fire” stays as “shots fire.” Typos are authenticity markers.
2. 02
   Every annotation must be specific to that message.Never generic observations.
3. 03
   Confidence ratings must be honest.HIGH = verbatim from official source. MEDIUM = from reliable secondary. LOW = partial/reconstructed.
4. 04
   Prefer SMS versions over email versions when both exist.SMS reflects the constraint environment.
5. 05
   Alert timestamps must be chronologically ordered.Sequence 1 before sequence 2 before sequence 3. An alert cannot precede the incident it describes. The validator enforces this.

Every case in this archive originates from publicly available sources. No case is fabricated, extrapolated, or composited from multiple incidents. Each case documents a single incident at a single institution with one or more alert messages reproduced verbatim from their original source.

Sources include official university alert archives, institutional social media accounts (primarily Twitter/X), student newspaper reporting, local media coverage, Clery Act Annual Security Reports, and after-action reviews. Source attribution is recorded at the alert level and the case level.

Our goal is to capture every alert in its exact, original wording. When that wording is confirmed from a primary source, it is reproduced exactly as sent: typos, grammatical errors, inconsistent capitalization, and formatting oddities are all preserved because they constitute evidence. When UNLV sent “shots fire” instead of “shots fired” during the December 2023 shooting, that typo was not an error to correct. It was an authenticity marker documenting the extreme urgency of composition under crisis conditions.

Cleaning up alert text would destroy the evidence of how humans actually communicate when lives are at stake.

Not every case has reached that bar yet. Where the exact transmitted text has not been recovered, the alert is reconstructed from reporting and clearly labeled as such, with an honest confidence rating, and tracking down and verifying the true verbatim wording is continuous, ongoing work.

Every case is assigned a confidence rating reflecting the reliability of its source material:

Every alert message includes analytical annotations: observations about language choices, timing, channel selection, compliance implications, or comparison to other cases. Annotations must be specific to the individual message, not generic observations about the incident. An annotation like “Uses Run-Hide-Fight protocol language” is acceptable only if accompanied by specifics: which formulation, how it compares to the standard, what it reveals about the institution's approach.

All cases are validated before publication against a strict rule set:

• Valid JSON structure with all required fields present
• No duplicate case IDs or URL slugs
• At least one alert message per case
• At least one source per case
• Sequential alert numbering, chronologically consistent
• Character counts match verbatim text length
• Valid ISO 8601 timestamps with timezone offsets
• Two-letter state codes
• Slug format compliance (lowercase alphanumeric with hyphens)

Cases that fail validation on any required field are rejected. Cases with warnings (short headlines, missing annotations, character-count mismatches within tolerance) are flagged for review but not blocked.

Beyond the verbatim record, every confirmed first-burst alert is coded for the six evidence-based elements of an effective warning message: the source (who is sending it), the hazard (what the threat is), the location (where it is), the guidance (the protective action to take), the time (when the message applies), and the impact (what the hazard could do). The core five come from public-warning science, including the work of Mileti and Sorensen, the CDC Crisis and Emergency Risk Communication framework, and FEMA IPAWS and WEA content guidance; the sixth, impact, was added on the recommendation of Dr. Jeannette Sutton, one of the field's foremost warning researchers, whose work on the content of Wireless Emergency Alerts informs the Impact definition used here (her research program and practitioner resources are introduced on the Message Anatomy page).

The coding is not keyword matching. Each alert is read in full and judged, element by element, by 25 independent Claude Opus 4.8 passes, each recording a verdict and a written justification. The headline result for an element is the majority vote across those 25 passes. A further arbitrator pass then reviews all 25 reads and writes a final one-to-two sentence synthesis for each element.

This is exploratory research. The codings are AI-generated and are not human-reviewed, so they should be read as systematic AI judgments with visible reasoning rather than validated ground truth. The analysis is shown interactively on the Message Anatomy page and is included in the data exports: the consensus and arbitrator assessment are folded into the “Everything” export on each coded case's first alert row, and the full element-coded dataset (consensus, per-element vote counts, and all 25 per-pass reads) is downloadable on its own.

Institutional diversity

The archive aims for coverage across every institution type and region, and all cases are treated and weighted equally. Some institution types (community colleges, HBCUs, tribal colleges, institutions in US territories, small liberal arts colleges) are systematically underrepresented in public archives due to archival practices, not crime rates. Gaps in coverage are tracked and reported. If an institution type or geographic region is missing from this archive, that is a gap in the public record, not an indicator of safety.

Data schema

The complete data schema is defined in TypeScript and enforced at build time. Key structures:

CaseStudy {
  id:          string       // YYYY-MM-DD-institution-slug
  slug:        string       // URL-safe routing slug
  institution: Institution  // name, state, type, alertSystem
  incident:    Incident     // date, type, cleryCategory, headline, summary
  alerts:      Alert[]      // verbatim messages with annotations
  sources:     Source[]     // attributed provenance
  confidence:  high | medium | low
  tags:        string[]
}