How to Build a Finance News Intelligence Engine for a Video Channel

A finance news intelligence engine is a stateful system that watches a defined set of channels and sources, detects which stories are breaking out relative to their own baseline, measures whether audiences are actually searching for them, scores the candidates, and produces a brief in which every claim is tied to a source row. The key word is stateful: the engine remembers every signal, verdict, claim and lesson across videos, so each new decision is made with more evidence than the last rather than starting from a blank chat window.

I built one of these from a 68-page specification written by the owner of a finance documentary channel. The spec described how the channel should think; the engine is that thinking running as a command-line program on a single database. This post explains how to build a finance news intelligence engine that is honest about its evidence, and the three design rules that kept it from becoming an expensive random-topic generator.

What problem does a finance news intelligence engine solve?

Finance video channels fail in a predictable way: they chase whatever is loud this week, produce a video three days after the audience moved on, and cannot say afterwards why a topic worked or did not. A human researcher can avoid this for a while; a system can avoid it consistently. The engine replaces three recurring questions with measured answers:

• Which stories are performing abnormally well right now, relative to the channels that covered them?
• Is there audience demand for an explainer, or only noise among insiders?
• What exactly can we say about this story, and where did each statement come from?

Each of those maps to a stage in the pipeline and to a table in the database.

How do you detect which finance stories are breaking out?

Raw view counts are useless because a large channel's ordinary video beats a small channel's best one. The engine snapshots every video on a watchlist of channels at intervals, computes each channel's own rolling baseline, and flags videos performing far above it. On my watchlist the detector surfaced videos running at 47 to 132 times their channel baseline. Those became the candidate queue, and they were topics no keyword tool would have flagged, because the audience interest had not yet turned into search volume.

Two implementation details that mattered: store snapshots, not just current counts, so velocity can be computed; and normalise per channel, never globally.

How do you measure demand without a keyword API?

Keyword research APIs looked like the obvious answer until I verified they were plan-limited in ways that made the numbers unreliable for niche finance topics. The engine measures demand with search result pools instead: for each candidate it issues a set of related queries, collects the result pool, and scores how fresh, how dense and how authoritative the existing coverage is. Thin, stale coverage on a topic with a breakout signal is the gap worth filling. Dense, recent coverage from large outlets means the story is already saturated.

This is a proxy, and the engine labels it as one. But it is a proxy the engine can recompute at any time, on any topic, without a paid plan.

Why must every verdict cite database rows?

The engine runs several judgement stages with a language model: a topic debate between opposing role cards, an audience-twin review that reads the brief as a target viewer would, and a script review. The rule that makes these useful rather than decorative is that a verdict which does not cite engine rows is invalid. If the model says a topic is strong, it must point to the signal rows, the demand rows and the candidate score it is relying on. If it cannot, the verdict is rejected and the stage reruns.

This single rule changed the character of the outputs. Vague enthusiasm disappeared, because enthusiasm has no row to cite. Disagreements between role cards became disagreements about evidence, which a human can adjudicate quickly.

How do you keep the script tied to sources?

When a topic graduates to a project, the engine creates a claims ledger and a sources ledger for it. Every factual sentence that will be narrated is a claim row linked to one or more source rows. The script review stage checks that no narrated claim is missing from the ledger. Two episodes registered so far carry 129 and 17 cited claims respectively, and the published description is generated from the sources ledger. For a channel discussing real companies and real people, this is the difference between a documentary and a liability.

How does the visual side fit into an intelligence engine?

A second specification extended the engine with a visual intelligence layer, because the owner wanted visual decisions to be as accountable as editorial ones. It adds:

• A shot and attempt ledger: every planned shot, every generation attempt and its diagnosis.
• A visual bible plus registries of metaphors and distinctive images, so the channel's look stays consistent and does not repeat itself.
• Hero-frame-first generation: a still-image engine produces the key frame, which then drives an image-to-video step.
• A generation law enforced in code: one generation plus at most one diagnosed retry per shot. A third attempt raises an error. This is tested, not merely documented, because the point is to stop budgets evaporating on rerolls.

A card renderer for data visuals gained animated money-flow diagrams for the kinds of stories where cash moving between entities is the whole explanation.

How I built this: FME, the Finance Media Intelligence Engine

FME is the 108-section specification implemented as a stateful command-line engine on a single SQLite database. The database holds channels, snapshots, signals, candidates, opportunities, projects, claims, sources, lessons, costs and logs, and nothing is reset between videos. The workflow for one topic is:

1. Ingest: snapshot the watchlist channels and their video metrics into the database.
2. Signal: run the outlier detector against per-channel baselines and probe demand for each flagged candidate with search result pools.
3. Judge: run the topic debate and audience-twin stages against role cards; reject any verdict that does not cite rows.
4. Brief: score the surviving candidates and write a brief whose claims are linked to sources.
5. Project: open a checkpointed project with its claims and sources ledgers, plan shots in the visual engine under the generation law, and export the script, description and shot plan.
6. Learn: after publishing, record the lesson rows and the costs so the next topic starts with more evidence.

Design decisions: one database as the single source of truth, per-channel normalisation, search pools over keyword APIs, citation as a hard validity rule, and a retry cap enforced in code. The outcome is an engine that found its own queue of 47x to 132x outliers, produced two fully cited episodes, and keeps every cost and lesson on the record. The downstream production side, where the brief becomes a rendered video, is described in how I make documentary videos with AI on a local GPU.

FAQ

Why a command-line engine rather than a dashboard?

Because every stage needs to be scriptable, resumable and testable, and a command line with a database gives that for free. A dashboard can be added on top of the same tables; building it first would have delayed the parts that produce value.

Does the engine pick topics automatically?

It ranks and briefs them. The owner makes the final call, with the brief, the debate transcript and the cited rows in front of them. Full automation of the choice was not the goal; accountable recommendation was.

Could this work for non-finance channels?

The structure is domain-neutral: watchlist, baselines, outliers, demand proxy, cited briefs, lessons. The role cards, the visual bible and the claim standards are what make it finance-specific, and those are data, not code.

How does it keep costs under control?

Every model call and generation is logged with its cost against the project. The generation law caps visual rerolls, and the citation rule stops judgement stages from running in circles. The costs table is reviewed alongside the lessons after each episode.

If you want an intelligence layer like this for your channel or newsroom, tell me about it on the contact page.