Editorial intelligence
Monitor
A workspace for following developing stories, grouping related coverage, and tracking events across multiple feeds.
I designed and built this project independently, using my own resources.
01 / Context
The problem behind the project
Editors need a way to follow several developing stories without losing related posts, event context, or the thread of a changing situation.
Monitor is the editorial discovery workspace in a larger newsroom workflow. Feed items, earthquakes, and related coverage need to become a usable picture of an event rather than a collection of disconnected links. The editor needs to compare sources while the story is still developing.
That puts two kinds of uncertainty in the same interface: a changing real-world event and asynchronous machine analysis. I keep source content, enrichment, event grouping, and editorial decisions distinguishable so a model result does not become an unreviewed publication decision.
02 / Implementation
Design and implementation
I build the ingestion, enrichment, and editorial workspace, bringing related coverage into a live, multi-column interface.
I built a Rust backend and React workspace around PostgreSQL and pgvector, authenticated ingestion, analysis callbacks, event relationships, and real-time feeds. PostgreSQL holds authoritative relational and vector state; the older Qdrant path is a migration compatibility concern rather than the primary persistence model.
Merriman handles feed delivery and editorial extraction/synthesis, Mistify supplies language and semantic helpers, and the editorial CMS owns drafts, review, scheduling, and publication authority. Monitor’s job is discovery and organization; it does not duplicate the complete CMS or publishing engine.
The clustering provider experiment uses stable per-post assignment so retries stay with the same provider. Candidate retrieval and event persistence remain shared, allowing semantic same-event evaluation without rewriting the ingestion and editorial models.
03 / Architecture
Architecture and workflow
Ingest source material
Receive feeds and bounded server integrations, preserving source identity and persistence independently of enrichment.
Enrich asynchronously
Request language, category, embedding, and clustering work and process acknowledged results.
Organize developing events
Relate posts to events and expose live columns and event views for editorial inspection.
Hand off deliberately
Selected material enters a separate drafting/review workflow. Discovery and model analysis do not grant publication authority.
04 / Approach
Engineering decisions
Keep the editor in the loop
Posts, related coverage, and event context share a workspace so a person can assess what matters and follow a story over time.
Separate collection from interpretation
Source ingestion and language or semantic enrichment are separate concerns, allowing the editorial interface to build on reusable processing services.
05 / Evidence
Evidence and outcomes
The PostgreSQL-backed provider experiment exercised candidate retrieval, a stubbed semantic response, and event persistence, including an error path that did not silently switch back to a different provider. The source record describes local integration evidence, not a completed production A/B quality result.
The native newsroom work carries Monitor into a shared macOS application alongside the editorial workspace while keeping product sessions and lifecycles separate. The same editorial model therefore informs both browser and native operating surfaces.
06 / Current scope
Where it stands
The editorial workspace is in development. Its implementation repository is private.
Same-event quality needs labeled pairs and final event communities. Cluster counts, a few compelling examples, or a model’s confidence are not enough to establish editorial recall or precision.
The implementation source is not linked from this page. Deployment, provider routing, and completed editorial acceptance are separate from the architecture described here.