Continuous monitoring — partly built, switched off

Monitoring is the always-on half: re-scan the sources, notice what is new, and surface what matters — a fresh campaign forming, a news story breaking, a risk emerging. Checked against the code and the live database on 17 August 2026.

What exists today

Capability	Status	The honest detail
Newsroom ingestion	built	a production-grade service reads newsroom feeds and sitemaps; deliberately, it only collects — nothing it ingests is auto-analyzed
The re-scan scheduler	built, ships off	a background loop re-scans registered sources on a cadence, with admin controls and cost awareness. It defaults to off, and the smarter tier-aware cadence is deferred
Observations	populated	about 37,500 raw observations about content are stored, written by several stages
Risk signals	populated, per-piece only	about 4,600 risk signals exist — written during per-piece analysis, not by any standalone watching pass
Relationship events	populated, per-piece only	about 1,300 events recording owner-customer-partner edges, also written during analysis
A signals/alerts surface	empty	the dedicated signals table has zero rows — built, never wired
The daily recognition pass	missing	the ruled daily look at what changed — new campaign clusters, notable news — does not exist

What a build would decide first

• What "worth surfacing" means. The raw material is already flowing (observations, risk signals, relationship events); what is missing is the pass that reads it and decides what a person should see today.
• The news trigger. A newsroom press release or a trade article is often the first sign of a campaign — the recognizer and the monitor meet exactly here.
• Cost discipline. The scheduler ships off for a reason; turning monitoring on is a cost-cadence decision per source tier, not a switch.

Where to look next

• The campaign pipeline — what the daily pass would feed.
• The conformance report — where the model and the live data disagree.