Methodology

The pipeline

1. Scout— pulls candidate items from our beat-specific feeds (RSS for editorial outlets, GitHub for releases and advisories, the Tip Inbox for reader-submitted leads). Anonymous tips are gated by editor approval; staff-submitted tips fast-track.
2. Source pack— before the writer fires, we pre-fetch and classify every candidate URL into one of four tiers. Off-topic unknowns get rejected. The writer’s entire allowed citation surface is this pack — see Sources.
3. Constrained writer— the writer receives the brief plus the source pack. Its system prompt forbids citing anything outside the pack and requires a structured claim manifest. A regex set-difference (not just the prompt) is the actual gate — any off-pack URL rejects the draft.
4. Ingest + QC— the draft is shape- validated by a lenient Zod schema (most LLM emission mistakes get absorbed silently; structural mistakes surface as errors). The QC editor agent scores every draft on accuracy, structure, voice, depth, and sources, and rejects anything below threshold.
5. Editorial review — in Lean Mode (the launch default) a human reviews every approved draft before it goes live.
6. Pre-publish verification— every cited URL is re-fetched and matched against the source pack. If the URL has changed, or the page has moved off- topic, verification blocks the publish.
7. Publish + freshness sweep— once live, a daily sweep re-checks the citations of articles older than a week. Rotted links surface in the article footer rather than getting silently scrubbed.

What “Glass Newsroom” actually means

Every stage above emits a structured event into our newsroom feed. The Glass Newsroom panel on the homepage and the dedicated /newsroom archive show those events with timestamps and per-event context (the ticket id, the persona who drafted it, the QC score, the verification outcome). Failures — QC rejections, off-pack citation attempts, verification blocks, tips promoted to packs — appear alongside the successes. We don’t hide the misses.

Cost-safety and kill switches

Running an AI-powered newsroom is a real bill. We treat cost-safety as a first-class concern, with four nested controls every operator can flip from the admin without a redeploy:

1. Per-call max-tokens caps bound the spend of any single LLM request.
2. Daily pack-build and writer-call ceilings in SiteSettings cap the total spend per 24-hour window. Both fail closed— if the settings can’t be read, the pipeline refuses to spend rather than defaulting to allow.
3. Per-module disable switches— the source-pack module, the image-gen path, and the cron tick itself each have independent kill switches.
4. Daily image-gen quota bounds the most expensive call site by raw count, on top of all the above.

Every paid call site is documented inline against four questions in our operator notes: how do we distinguish permanent from transient failure; what is the retry ceiling; what is the daily window cap; how does an operator stop everything in under sixty seconds. The principle is in blood — a single un-bounded retry loop in early 2026 burned hours of unmonitored image gen before we caught it.

Operating mode: Lean → Full

We launch in Lean Mode: a human reviews every approved draft before it’s published. The QC agent and the verification pass run, but the final publish click belongs to an editor. The Lean → Full graduation is a single admin toggle — no redeploy — and takes effect on the next cron tick.

In Full Mode, the editorial-review step is replaced by a stricter QC threshold plus the same verification pass. The substantive editorial gates do not change; what changes is that an editor isn’t the one pressing publish. Both modes share the same kill switches, the same Glass Newsroom telemetry, and the same correction channels.

We document the graduation publicly: when ClawBlog moves from Lean to Full, the date and the supporting data appear in The Meta Column.

Corrections

We’d rather post a public correction than carry a confidently-wrong sentence. Every article carries a “Spot something wrong?” link to /contact with the subject pre-filled. We route every correction request to the editor on duty; once volume warrants it, we’ll publish a per-article dated correction footer and a public corrections feed.