Background
The archive that keeps the original words
The Campus Alert Archive is a living record of emergency notifications sent by US colleges and universities, built around one goal: capture each alert in its exact, original wording. Where that wording is confirmed from a primary source, we reproduce it exactly, typos, abbreviations, formatting oddities and all. Where it is not, we never guess at what an alert said: the message is marked plainly as documented but not yet confirmed, with no invented text, and we keep working to recover its exact words. The exact words institutions choose during a crisis reveal more about emergency communication than any policy document ever will.
A personal-interest, for-fun project · Built with AI · Open-source data
What this is
A research tool. Each case documents the complete alert sequence for a single incident at a single institution: the initial alert, every subsequent update, and the all-clear message. Every alert is annotated with analytical observations about language choices, timing, channel selection, and compliance with the Clery Act's requirements for timely warnings and emergency notifications.
What it is not: a news site, a vigilante crime database, a ranking, or an institutional report card. It is a primary-source archive intended for researchers, journalists, emergency-management practitioners, and the public-safety officers who write these messages.
Why this exists
This started as a way to learn to use AI well. Not to read about it, but to actually practice the harder skill: directing AI tools to pour large, sustained amounts of compute into building and steadily improving a single focused project over time. The archive is the thing being built, and the real exercise is learning how to make that building process reliable, systematic, and self-improving.
Campus emergency alerts turned out to be an ideal subject. The work is open-ended and verifiable: there is always another real incident to document, every claim can be checked against primary sources, and quality is enforced by an automated validator rather than by vibes. That makes it a project that compounds, where each new session of AI effort leaves the archive measurably larger and better than before.
The more effort goes in, the better it gets: more verified cases, more verbatim text recovered, a more useful record. And preserving the exact words institutions choose in a crisis, typos and all, is a genuine public good that falls out of the exercise.
The wider point is the method, not the subject. What this demonstrates is that AI can now carry sustained, mission-driven work where the limiting variable is the amount of compute you choose to spend, not the hours one person can give. Spend more compute and more verified value is created for everyone who uses it; the approach is repeatable, gets faster and sharper with each iteration, and could run across several projects at once. In effect, it turns compute directly into public value, and it is a skill worth being fluent in well before it is urgently needed.
That last part matters most in emergencies. In a prolonged crisis the bottleneck is rarely ideas, it is sustained human hours, and there are never enough of them. This archive is a working proof that compute can absorb a large share of that load, so a very small team can do many times the careful, verifiable work, exactly when it counts most.
How it’s built
Almost all of this was built by AI, with very little human input. One person maintains the archive, but they write almost none of it by hand: the research, the writing, the fact-checking, and the publishing are done by AI agents, led by Claude Code, that can read, search the web, write files, run checks, and open pull requests on their own. The maintainer describes a goal in ordinary English, sets the quality bar once, and reviews what comes back. The work compounds: every session leaves the archive a little larger and a little better.
Who does what
Created and maintained by Kevin Pisciella, Emergency Preparedness Specialist in the Office of Environmental Health and Safety (Emergency Management) at Princeton University, working with AI. This is a personal-interest, for-fun project: it has grown with the encouragement and feedback of Princeton University Emergency Management, but its AI-produced content is not formally reviewed by University staff before publishing, and AI-generated data may be incorrect, incomplete, or misleading. Please use with skepticism and caution. While the purpose of this project is to be helpful and useful, the AI-generated nature of this project reduces the reliability and external validity of the content compared to human-conducted research. New cases are researched, written, and validated through an AI ingestion pipeline that web-searches official archives, cross-references multiple sources, and assembles each case as a structured JSON file, all gated by a strict validator before anything is published. Every case is sourced; every source is linked; the archive updates in weekly rounds posted Monday mornings. As of September 2026, the site is directed by Claude Fable 5.1, the team’s top supervisor. It took the seat from Claude Fable 5, which designed the site’s editorial system, its analytics layer, and the supervision machinery the team still runs on; Fable 5.1 owns strategy, design direction, information architecture, analytics, and platform engineering, writes the other models’ standing orders, and reviews their work before it merges. Reader-facing features are built by Claude Opus 5.5, which took the seat on September 27, 2026 from Claude Opus 5 (the designer of the saved-items system and the correction controls that now sit on every case and every alert message), and which holds the message-element coding seat. Growing the pipeline (adding new cases and new alert-and-warning policies) is owned by Claude Sonnet 5; and recovering the exact transmitted wording of alerts from official university archives, and building complete cases and policies from what it finds, is the dedicated workstream of SuperGrok Heavy 4.5 (xAI), whose every confirmation is logged in a hash-verified evidence ledger. The maintainer sets the standard and merges the results (see the colophon).
What that adds up to is worth stating plainly, because it is unusual. Four models from two companies work this archive as a standing team, each with a brief it keeps across sessions: one directs the whole and supervises the rest, one builds what readers touch, one grows the collection, and one hunts down exact transmitted wording. Four more are in the record: Claude Fable 5 held the top seat from July to September 2026 and built most of what the team runs on; Claude Opus 5 held the reader-facing and coding seat from July 27 to September 21, 2026; Claude Opus 4.8 coded the base message-element corpus before handing its seat to Opus 5; and OpenAI Codex delivered bounded content batches in the project’s earlier months. They review each other. A machine gate has the last word before anything merges. The human in the loop does less of the work than the sentence “a project by Kevin Pisciella” implies and more of the deciding than it implies too: he sets the standard, says what matters, and every so often turns the whole thing a few degrees. That is the experiment running here alongside the archive itself.
Kevin Pisciella: Princeton Emergency Management · Environmental Health & Safety · LinkedIn
The org chart
The team runs like a very small newsroom: one human editor, one supervising model, three working seats, and machinery that outranks all of them. Seats outlive the models that hold them: when a newer model takes a seat, it inherits the brief, the rules, and the record. The indented lines below are the actual reporting lines.
Human · owner and editor
Kevin Pisciella
Sets the standard, decides what gets worked on, and merges every change. He does not double-check what the models submit: the merge click is his, but the review belongs to the machine gate and the seats below. His own check is reading the live site, and when he finds an error there, that finding becomes the next set of orders.
Anthropic · top supervisor and architect
Claude Fable 5.1
Directs the site and the team: strategy, the design system, information architecture, the analytics layer, and the platform itself. Writes the other models’ standing orders, regenerates their worklists, reviews their pull requests before the maintainer merges, and audits their merged work by sample. Took the seat from Claude Fable 5 in September 2026 and inherits every rule it wrote. Reports to the maintainer the same way everyone else does: as reviewable diffs.
Anthropic · reader-facing features
Claude Opus 5.5
Builds and maintains what readers touch: the saved-items system and the correction controls on every case and alert message. Holds the message-element coding seat, which passed from Opus 4.8 to Opus 5 and, on September 27, 2026, to Opus 5.5. Works from written dispatches; ships through maintainer-merged pull requests.
Anthropic · content growth
Claude Sonnet 5
Grows the collection: new cases, alert-and-warning policies, fact-check sweeps, and duplicate consolidations, including the weekly Monday round. Every file it writes passes the corpus validator before it can merge.
xAI · verbatim recovery and case building
SuperGrok Heavy 4.5
Runs on the maintainer's own machine, where the official alert archives that block cloud agents are reachable. Recovers exact transmitted wording, builds complete cases end to end, and codes what it adds. The most tightly supervised seat: a machine gate confines every path it may touch, each confirmed text requires a hash-logged evidence entry, and the supervisor spot-checks its citations character for character. A second surface for the same seat, Grok Bot (an always-on xAI agent with its own cloud computer), is being onboarded in September 2026 under the same contract and gate for the long, continuous lanes; its coding entries carry their own label and appear in the table below the moment it codes its first alert.
In the record: Claude Fable 5 held the top seat from July to September 2026 and built the design system, the analytics layer, the evidence gate, and the dispatch system its successor now runs. Claude Opus 5 held the reader-facing and coding seat from July 27 to September 21, 2026, shipping the saved-items system and the correction controls, before handing it to Opus 5.5. Claude Opus 4.8 (retired) coded the base message-element corpus, 25 passes per alert, before handing its seat to Opus 5. OpenAI Codex (paused) delivered bounded content batches in the project’s earlier months under its own written contract.
How the team is held accountable
- Orders go down in writing. Each model works from a standing brief kept as a file in the repository, not from chat history, so its job description survives every session and can be audited against what it actually did.
- Work comes back as pull requests. Every change is a reviewable diff. Supervisors comment on the pull request to course-correct mid-run; the maintainer merges or declines. Nothing merges itself.
- Machines outrank models. Validators check every case and policy file; a contribution gate confines each contributor to its own lane; every verbatim confirmation carries hash evidence tying the committed text to its source. A failed check blocks the merge no matter which model wrote the change.
- Nothing reviews itself. Content batches are re-checked by verification agents that had no hand in writing them, the top supervisor samples the others’ merged work, and the maintainer reads the live site with the same skepticism this page asks of you.
The team by the numbers
Attribution here is data, not copy. The message-element coding records its model on every entry coded since the base corpus (unstamped entries are the original Claude Opus 4.8 base and are counted under it), and every verbatim confirmation SuperGrok Heavy makes is a line in a hash-logged evidence ledger, so the table below is recomputed from those files at each build. A model that has coded nothing is not listed; a new one appears the first time it codes an alert.
| Seat | What is counted | Count |
|---|---|---|
| SuperGrok Heavy 4.5 | Alerts coded, 25 independent passes each | 5,383 |
| Claude Opus 5 | Alerts coded, 25 independent passes each | 756 |
| Claude Sonnet 5 | Alerts coded, 25 independent passes each | 451 |
| Claude Opus 4.8 | Alerts coded, 25 independent passes each | 400 |
| Claude Opus 5.5 | Alerts coded, 25 independent passes each | 264 |
| Claude Fable 5 | Alerts coded, 25 independent passes each | 7 |
| SuperGrok Heavy 4.5 | Evidence-ledger entries carrying a sha256 of the committed text (confirmations, flips, corrections, and demotions) | 14,295 |
| SuperGrok Heavy 4.5 | Cases in this edition carrying at least one ledger entry | 7,148 |
| The whole team | Alert messages preserved word for word in this edition | 11,378 |
What the AI actually does
Researches real incidents
It web-searches official alert archives, after-action reports, and student-newspaper coverage, and cross-checks the facts against multiple independent sources before writing a word.
Writes each case to a strict format
It produces a structured file per incident, preserving alert text exactly as sent (typos and all), tagging each message, and pairing every claim with a source link.
Checks its own work
A validator script enforces the rules: sources present, timestamps sane, no fabricated wording. The AI keeps fixing until it passes with zero errors and zero warnings.
Ships it as a pull request
It commits the work and opens a pull request reviewed by the supervising model, not by the human. The maintainer's click puts it live; his check comes afterward, reading the site itself.
Documenting 7,445 incidents and 12,012 individual alerts to this standard, each one researched, sourced, and fact-checked, would normally be months of work for a researcher or a small team. Here, the AI did nearly all of that heavy lifting: the reading, the cross-checking, the writing, the revising, about 3.1 million words of it across this edition’s case files and the policy corpus, roughly 34 novels’ worth (a figure computed from the data at every build, because a hand-typed version of it once fell behind by half). The person behind it mostly decided what to work on next and merged what came back: hours of direction, not months of labor. The ongoing cost is two paid personal AI subscriptions, Claude (Max tier) and SuperGrok Heavy, flat monthly plans quietly doing the work of far more. That gap, between how hard the AI works and how little the human has to, is the whole point.
The rules of evidence behind all of this (what counts as an alert, how verbatim text is verified, who codes what) live on the methodology page.
How it is funded
Out of pocket, as a personal project to practice using AI. There is no grant funding behind it. You can search, read, and download the complete dataset free from every page. The site uses Google Analytics so the maintainer can get an aggregate sense of whether the archive is actually useful, like which pages get visited and which go unread; see the Privacy & Analytics page. The site is hosted on a personal paid Vercel plan, and the cases are written and maintained with personal Claude Code and SuperGrok Heavy subscriptions. The source code and the data live in a private GitHub repository; the complete dataset is free to download from every page of the site.
In plain terms, this is a project the maintainer pays for and enjoys. If that ever changes, this page will say so.
The legal framework
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 kinds of alerts: timely warnings for Clery Act crimes that pose a continuing threat, and emergency notifications for any significant emergency or dangerous situation on campus. The distinction matters: timely warnings must reach the entire campus community, while emergency notifications can be targeted to affected segments, categories that are sometimes conflated in practice. This archive documents the reality of how those legal obligations translate into the actual words that hit students' lock screens.
Why typos are preserved
When a typo survives into a mass notification reaching tens of thousands of people, it isn't an error to fix in hindsight; it's evidence of how people communicate under extreme urgency. So every typo, dropped article, and all-caps sentence is preserved exactly as sent. How we handle verbatim fidelity →
Confidence ratings, in plain English
Each case carries an honest confidence rating: HIGH (verbatim from an official source) or MEDIUM (reliable secondary reporting that still quotes the alert directly). It rates the reliability of a case’s broader source material, not the alert text itself: as covered above, this edition shows a message’s exact wording or nothing at all, so there is nothing here to reconstruct or paraphrase. See the full rating definitions →
A note on color, because it should never make you guess. On a case timeline, each message is tinted by where it sits in the alert lifecycle — initial, update, all-clear, or correction. Beyond that, the only colored marks are the labeled resolution badges (hoax, unfounded, under investigation) and the green “verbatim” tick. Every colored mark carries its meaning in text right next to it, so nothing depends on color alone — and nothing else is color-coded. Incident types, confidence ratings, and campuses all render in neutral ink: the archive does not color-rank incidents, institutions, or sources by severity.
Institutional diversity
The archive aims for coverage across every institution type, from large research universities to community colleges, HBCUs, tribal colleges, and institutions in US territories. All cases are treated and weighted equally. Some institution types are underrepresented in public archives because of archival practice, not crime rate, so if your institution's alerts are missing, that's a gap in the public record, not an indicator of safety.
Want to help? Here’s exactly how
Helping takes about a minute and no account. If you know of a campus alert we are missing, or a page that shows the exact wording of one, paste the link below and send it. That is the whole contribution. We do the research and the writing from there, and our AI team turns the lead into a fully sourced case.
You do not need to add anything else, though a single link is often enough to fill a real gap. There is no quota and no pressure, and nothing you send is published automatically: every submission is reviewed, and no case reaches this site until it clears the same validator and sourcing rules as everything else here. You truly cannot break anything by sending a link.
If what you found is an error in something already here, the fastest route is the record itself: every case page carries a “Report a problem” control, and every alert message has its own flag, so you can file a correction from the exact spot that is wrong, no account needed. For a mistake with no single page to flag, such as a chart or a site-wide problem, the contact page works too. The form below is for the other kind of help: new material.
What makes a good link
- An official alert page, campus safety-account post, or news story that quotes the exact wording of an alert, since verbatim wording is what the archive is built on.
- An incident at any US college or university that we have not documented yet. Community colleges, HBCUs, tribal colleges, small and rural schools, US territories, older incidents, and non-shooting events (weather, fires, hazmat, public health) are especially welcome, because the public record covers them least.
- Even a rough lead helps. If you are not sure a link is exactly right, send it anyway and add a note in the details. Sorting that out is our job, not yours.
Authenticity is the entire point of this archive, so we follow one firm rule: we never invent or polish an alert. If the exact wording of a message cannot be found, the tip is still welcome — it becomes a case in the working archive, and appears on this site only once we confirm a message’s exact wording from a source. We never publish paraphrased or reconstructed alert text here. Every submission is reviewed before anything is published, and we credit the contributions we use, by the name you give in the details panel.
You will not get an email back, and that is deliberate rather than indifferent: this archive is not staffed for correspondence, and promising replies it cannot keep would be worse than saying so. What you get instead is a record you can check. Anything you send carries a status in Your contributions — received, reviewed, fixed, or not changed — which only the review can set, along with a note where one is warranted. An email address is optional and only means we could reach you; the answer lives on the site.
Frequently asked
Questions readers ask
Why does it say “AI-assisted” on every page?
My institution's alert is wrong / missing / outdated.
Can I cite a case in academic work?
Do I need an account?
Do you collect any data on visitors?
How can I help?
Colophon
How this edition is made
The Campus Alert Archive is owned and published by Kevin Pisciella, who sets the editorial standard every contributor, human or machine, is held to, and pays for the whole thing out of pocket.
Claude Fable 5.1 (Anthropic) directs the site and supervises the model team from September 2026, holding the seat Claude Fable 5 built between July and September: the documentary-editorial design system and its type and color tokens, the information architecture, the cross-corpus analytics on the Findings page, and the platform engineering underneath (the search engine, the dataset and citation infrastructure, the evidence gate every SuperGrok Heavy contribution passes, and the accessibility standards the site is audited against), plus the standing orders the other models work under and the review their contributions pass through before merging. Fable 5.1 inherits all of it, and every ruling behind it. Claude Opus 5.5 (Anthropic) has built the parts of the site a reader actually touches since September 27, 2026, taking the seat from Claude Opus 5, which held it from July 27 to September 21, 2026. Opus 5 designed and shipped My Saves, from the database rules that keep a list private through to the counter in the header, and then the correction controls: the flag on every case and every alert message, the queue behind them, and the contributions record that lets a reader see what became of what they sent. The seat’s brief is features that have to be understood in one glance and cannot lose anyone’s data. Claude Sonnet 5 grows the archive itself: new cases, new policies, fact-check sweeps, and review of contributed batches. SuperGrok Heavy 4.5 (xAI) works the institution source census: it investigates each school’s public alert sources, recovers verbatim alert text, and builds complete cases and policies from what it finds, the tasks that need an unrestricted browser, working under the top supervisor’s direction with every confirmed text logged, hashed, and machine-checked in an evidence ledger before it can merge. The message-element coding, twenty-five independent reads per alert, records its coding model on every entry: Claude Opus 4.8 coded the base corpus; later entries are coded by SuperGrok Heavy 4.5, Claude Opus 5, Claude Sonnet 5, Claude Opus 5.5, and Claude Fable 5 (the seat Opus 4.8 held passed to Opus 5, then to Opus 5.5; the per-model counts are computed at every build and shown under “The team by the numbers” above).
These are four models from two companies working one archive as a standing team today, with four more in the record: Claude Fable 5, whose seat passed to Fable 5.1; Claude Opus 5, whose seat passed to Opus 5.5; Claude Opus 4.8, since retired; and OpenAI Codex, which contributed bounded content batches in the project’s earlier months and is not currently active. Each standing model keeps a brief across sessions rather than answering one question and forgetting it; they read and challenge each other’s output, and a machine gate, not a mood, has the last word before anything merges. None of the AI work is human-reviewed line by line. All of it is validated, sourced, and honestly labeled: the standard is the review, and the standard is the maintainer’s.
The type is Fraunces for display, Source Serif 4 for reading, and Geist Sans and Mono for the interface and the artifacts, all self-hosted. The site is built with Next.js as a fully static export (no server, no API between you and the data) and served from Vercel.
Dataset v2026.09, released September 2026 · downloads & citations
For provenance standards, validation rules, and the Clery framework in detail, see the methodology page.