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:

The Clery Act (20 U.S.C. § 1092(f)) and its implementing regulations (34 CFR § 668.46) require all Title IV institutions to issue two distinct types of alerts:

Each case is classified under one of these categories, plus “advisory” for non-Clery discretionary notifications, “missing-student” for HEOA 2008 cases, and “test” for drills. Classification is based on incident type and apparent institutional intent, not on whether the institution correctly identified the legal obligation.

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.

Institutional diversity

This archive actively seeks alerts from underrepresented institution types (HBCUs, community colleges, tribal colleges, institutions in US territories, small liberal arts colleges) because their alerts 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 to fill, 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[]
}