Lucile Tranchant

Work, System Design

An executive-readout architecture for monitoring digests

A config-driven, multi-deployment monitoring engine that leads with judgment: the readout comes first, the evidence follows, and a language model never decides what matters.

The design
problem

Most automated digests are newsletters: a wall of story cards ranked by recency, with the actual judgment, does anything here need attention?, left to the reader. A reader with ninety seconds needs the conclusion first.

The hard case is the quiet day. A system that can honestly say nothing crossed the bar today earns the right to be read carefully when something does, so that case has its own test.

The output structure One edition · fixed order · sample content
Subject
Monitoring Digest, Edition 47
TUE · 06:00 · daily
Readout

One item crossed the priority bar overnight; three on standing watch. All monitored sources reporting.

Priority finding 1

A coordinated set of posts misattributed a policy reversal to the organization, gaining traction on two regional networks overnight.

What~40 near-duplicate posts, in-language, first seen 02:10; amplified by two mid-size accounts.
WhyThe claim is factually wrong and spreading; left alone it becomes the reference version within a day.
StepPublish a dated correction on the owned channel; brief regional spokespeople with the agreed line.
Standing watch
01Recurring narrative questioning funding allocation, stable volume, no new vectors.awareness
02Low-level impersonation account, reported, awaiting platform action.tracking
03Sentiment dip after a leadership announcement, within normal range.awareness
Coverage. Scanned: listening feed · news API · 6 regional RSS. Dark: one social API (auth refresh pending), edition degraded visibly, not silently.
1

Readout first. The conclusion leads; evidence follows. Ninety seconds is enough to know whether to act.

2

What / why / step. Every priority finding carries all three, never an alert without a recommended move.

3

Standing watch, not filler. Awareness items sit apart from action items, so the priority bar stays meaningful.

4

Coverage note closes the loop. What was scanned and what went dark, the reader always knows the evidence base.

How signals are routed Watch one signal move through the gate
Deterministic routing · live Code assigns the tier, the model only writes
Signal in
Raw signal arrives, source, no verdict yet.
Determinism first The load-bearing decision

"Tier assignment is computed in code, before any model call. The model writes the analysis for each tier, it never assigns the tier."

, the same rule as my harmful-information pipelines: the model summarises what passes the gate; it never decides what passes.
SOURCESfeeds, APIs, listening, per client
TERMSpriority keywords + weights → thresholds
LENSnarrative-risk ▸ brand-reputation
CADENCEdaily · weekly · per deployment

Multi-deployment by config. One engine, many deployments, each is a YAML file. The expertise lives in the config: terms, weights, and per-lens prompt content are the product; the engine just runs them. Per-deployment keys isolate one deployment's credit exhaustion from the rest.

Reliability rules Carried over from a live emergency
01, Send at most once

Committed state files survive scheduler retries and same-day races. A confirmed send is the only thing that writes state.

02, Fail closed

An empty feed or malformed output blocks the send rather than shipping a confident edition on a narrowed base. A skipped edition is recoverable; a wrong one in an inbox is not.

Personal project · Python, GitHub Actions, Claude API · built in a Claude Code session from a written specification · repository private. Engineering write-up only, this page describes a system, not a service.

Interested in the thinking behind this system? A code-and-prompt walkthrough is available on request. Get in touch →