Case Study Catalog

Live at case-study-catalog.fly.dev. A public catalog of real examples of generative AI in higher education, in three collections (teaching, research, and reducing AI misuse), with a submission form, a password-gated dashboard for approving new entries before they go live, and a set of analyses built on the catalogs. Every entry must describe something actually built, run or trialled, with a source link.

The code is also usable as a starter template: fork it, replace the seed data and branding with your own topic, and deploy.

• GET / — public catalog (search + facets)
• GET /submit — public submission form
• GET /admin — password-gated review dashboard (approve / reject / edit / delete)
• GET /about — about page
• GET /ai-for-research — companion catalog for research (rather than teaching) case studies
• GET /reducing-ai-use — companion catalog for "reducing AI (mis)use" case studies
• GET /trends, GET /research-trends — aggregate trend/association views over the teaching and research catalogs, respectively
• GET /analyses — landing page for the four analyses: teaching trends, research trends, AI guidance analysis, and research on AI detection
• GET /ai-guidance-analysis — analysis of what UK and Irish universities tell students about generative AI; every count traces to a quote in the institution's own document (method and codebook in policy/, data in data/policy/). Draft, in progress. /ai-policy-atlas redirects here
• GET /teachers-spotting-ai — research dashboard on whether teachers can tell AI-written work from student writing (sources in docs/teachers-spotting-ai-writing.md)
• GET /ai-perceptions — findings explorer for the AI-perceptions research papers (separate from the case-study catalogs above)

How it works

• Your own curated entries ship as data/seed.json and are loaded into the database once, the first time the server starts against an empty database.
• Public submissions land in the same database with status = 'pending' and are invisible to /api/catalog until approved.
• The admin dashboard (/admin) is gated by a single shared password (ADMIN_PASSWORD). It shows every entry — originally-curated and community-submitted alike — with approve/reject/edit/delete on any of them, plus an "Add from email" box that publishes straight from a pasted notification email, and a "Repository suggestions" list for links someone flagged as worth going through by hand.
• Storage is SQLite via Node's built-in node:sqlite module — no native build step, no separate database service to run.
• Every new submission also fires an email notification (see below) — this is optional and skipped silently if not configured.

Email notifications

Sends via Gmail SMTP (not a new account — reuses whichever Gmail address you designate as the sender) whenever someone submits through /submit. Set three env vars:

Var	Meaning
GMAIL_USER	The Gmail address that sends the notification
GMAIL_APP_PASSWORD	An app password for that account (see below) — not your regular Gmail password
NOTIFY_EMAIL	Where notifications are delivered — can be any address, including a different Gmail account or an institutional/shared team inbox

To get an app password: the GMAIL_USER account needs 2-Step Verification turned on (Google Account → Security), then generate one at myaccount.google.com/apppasswords. It's a 16-character code, not your login password — paste it into GMAIL_APP_PASSWORD.

If any of the three vars is missing, the server logs a warning on startup and simply skips sending — submissions still work normally, they just won't trigger an email.

The recipient doesn't need to be related to the sending account or match any domain — Gmail SMTP can deliver to any inbox, so pointing NOTIFY_EMAIL at an institutional address works the same as pointing it at a personal one.

Every notification email also includes the submission as a single-line JSON block, formatted to be pasted straight into the admin dashboard's "Add from email" box (see below) — the email itself is the durable record of a submission, independent of whether its row in the database is still there by the time you get to it. The "Add from email" box also accepts the plain-text part of the email on its own, or the whole email pasted in — it isn't JSON-only.

Repository suggestions

/submit also has a small secondary form for "I know of a whole page/PDF/collection of these, not just one" — it takes a URL and an optional note, emails you the same way a regular submission does, and lists it under "Repository suggestions" in the admin dashboard. There's no automatic extraction (see the note in /submit about why a published page can't fetch or read an arbitrary URL for you) — you visit the link yourself, and add whatever qualifies through the normal form or paste box. Mark a suggestion done once you've gone through it.

Git persistence for approved entries (avoids paying for a persistent volume)

Without this, approved entries only exist in the SQLite file, so a host with no persistent disk (e.g. a bare Fly.io machine with no volume attached) loses them on every rebuild. With it, every approve/edit/delete/reject of any entry — originally-curated or community-submitted, since the admin dashboard can edit or delete either — commits the full current list of approved entries to data/community.json via the GitHub API, including which collection each one belongs to and whether it was seeded or submitted. Once that first sync has ever happened, community.json becomes the living snapshot of the whole catalog: a freshly rebuilt instance loads from it rather than from the original seed.json (which stays untouched as the initial bootstrap for a repo that's never synced yet).

This is the beginning of the README. Read the rest at the original. Read the full README ↗