Building a Living Case Database: Schema, Human-in-the-Loop AI, and the Math That Kills Most Niche Sites

Most "build a niche site" posts stop at the content strategy.

This one starts where those posts usually end: the operating model.

I spent time reverse-engineering what it actually takes to run a site that publishes living case files instead of one-and-done articles. The full blueprint (architecture, data model, nine-prompt production pipeline, privacy gates, economics, and monetization) is here:

→ How to Build a True-Crime Case-Tracking Website From Scratch

What follows is the part I think is most useful for builders: the data and process decisions that determine whether the site survives past the first six months.

1. The core unit is not an article — it's a row

Every case is a structured record before it becomes a page. The schema is deliberately over-normalized from day one:

• defendants, victims, attorneys, judge are foreign keys (or arrays of FKs), not free-text fields.
• charges is its own table with per-charge legal status.
• hearings is an append-only log (newest first).
• last_verified is a first-class field that drives the stale-case metric.

Why? Converting flat text into linked entities later is one of the most painful refactors you can do on a live site. Plan for the graph even if the MVP UI still renders everything as plain text.

The page template is just a view over that schema:

Case Name / Docket
├── Status + Last Updated
├── Summary (2–3 sentences, rewritten as the case evolves)
├── Timeline (dated, newest first)
├── The Money / Harm
├── Key Documents
├── Related Cases
└── Update Log

2. The production system is nine prompts + one human gate

This is not an autonomous AI newsroom. It's a research and drafting pipeline with mandatory human sign-off on every legal-status claim, every newly named person, and every publication decision.

High-level flow:

1. Signal Hunter – monitors new filings, hearings, sealed-to-unsealed changes
2. Qualification – hard PASS/FAIL gates (primary source exists? trackable docket? privacy risk?)
3. Source Hunter + Claim Ledger – builds a citation table with claim ID, source, page/para, legal status, confidence
4. Analysis – patterns only if the ledger supports them; alternative explanations required
5. Entity Map – what lives on the permanent case page vs. what becomes a standalone explainer
6. Case File Builder – every factual sentence must cite a claim ID
7. Accuracy + Privacy Gate – the single most important step
8. Update Check – for already-tracked cases
9. Distribution

The privacy/accuracy gate is non-negotiable. Any open flag (minor identification, sealed records, presumption of guilt, secondary-only sources treated as fact) blocks publication.

3. The real constraint is operating capacity, not content ideas

Homicide Watch D.C. peaked at ~500k pageviews/month and still closed. The cost of keeping every active case current was effectively one full-time reporter. When the founders moved and couldn't find a local partner willing to fund that role, the site shut down.

That is the actual problem this architecture tries to solve.

Define these metrics before you publish the first case file:

Metric	Target	Warning
Active cases per editor	15–25	>30
High-activity cadence	Daily	>48h
Dormant cadence	Weekly	>14 days
Stale-case rate	<5%	>10%
Correction rate	<2 / 100	>5

Site health formula:

stale-case rate < 5% AND correction rate < 2 → the site is delivering what it promised.

stale-case rate > 10% → it has operationally collapsed, even if traffic looks great.

Size the number of active cases to what one person can actually sustain, not to what would be editorially interesting.

4. Why this is interesting for builders

Most AI content systems optimize for volume. This one optimizes for trust under continuous update pressure. The claim ledger, the hard privacy gate, and the explicit automation boundary (what AI can draft vs. what a human must sign) are the parts that make the difference between a site that can keep running and one that quietly dies when the founder gets busy.

If you're building anything that needs to stay accurate over time (case tracking, regulatory monitoring, product changelogs, research databases), the same pattern applies:

1. Structured schema first
2. Provenance on every claim
3. Explicit human gates on the high-risk decisions
4. Metrics that tell you when the operation is failing, not just when traffic is up

Full write-up with the complete prompt set, site map, monetization layers, and real-world examples (Homicide Watch, DC Witness, CourtWatch, etc.) is here:

https://www.moneytraces.com/2026/09/how-to-build-true-crime-case-tracking.html

Curious what others have found when trying to keep structured "living" data products accurate at low headcount. The operating numbers are the part most architecture posts skip.