News Curator with Verified Intelligence

Ingest many kinds of sources. Score and classify every item. Draft the summary. Then audit the summary against the source text — separately for fact, language and search — and refuse to publish if the audit fails.

That last sentence is the product. Summarisation has been commodity for two years. What has not been solved is the part every professional services firm actually needs: the ability to answer, months later, which source supported which claim — and what you knowingly let through.

The problem with AI-generated research briefings

A research or knowledge team produces the same artifact every week. A sector briefing. A regulatory monitor. A competitive-intelligence digest. A client-facing newsletter. The work is mechanical in shape and expensive in hours: read 200 sources, discard 190, understand 10, write 1,200 words, get it reviewed, ship it.

Every firm has tried to point a language model at this. Most attempts stall in the same three places.

The output cannot be defended. A model returns a fluent paragraph containing a number. Nobody can say where the number came from. In an internal memo that is annoying. In a client deliverable it is a liability, so the deliverable goes back to a human for full re-reading — and the automation has saved nothing, because verification was always the expensive half.

The tradeoffs are invisible. Real pipelines compromise. A headline runs long, a claim is only partly supported, a section has thin coverage. A system that hides these produces output indistinguishable from output with no problems at all. A reviewer cannot prioritise what they cannot see.

The shape is non-deterministic. One week the briefing has a "Companies to watch" section, the next week it does not, because the model had nothing to say. Every downstream consumer — the website, the slide generator, the search index — now needs defensive code. The automation has pushed its cost onto everyone else.

None of these are model-quality problems. A larger model writes better prose and fails all three in exactly the same way. They are architecture problems, and they are what this platform is built to solve. The same failure pattern shows up across agent systems, for the same reason: most multi-agent systems fail on architecture, not model quality.

The governing principle

Every quality gate in the pipeline is negotiable, except one — and the one is waiver-proof precisely so the others can be lenient.

The model-driven auditors get a pass budget. When an auditor stops converging — it keeps flagging the same three-character headline overrun on pass four — its findings are downgraded to advisories and the pipeline moves on. A finished, accurate story is not thrown away over a cosmetic defect.

That leniency is only safe because something further down is absolute. The final publication gate runs no model, has no pass budget, and cannot be waived. If one of its checks fails, nothing publishes.

The result is a system that is simultaneously pragmatic and safe: it tolerates imperfection, records every imperfection it tolerated, and enforces a hard floor beneath all of it.

How the pipeline works

Nine stages. Each writes a durable artifact to disk before the next begins — which is what makes the pipeline both resumable and auditable.

Rendering architecture diagram…

Read this diagram as text

• →Collect — stages 1 to 3. Twenty-one registered sources are ingested with their provenance attached, filtered down to the domain, then fetched in full so later stages have real evidence to check against.
• →Rank — stages 4 and 5. Every item is scored on six weighted dimensions and classified against a closed vocabulary, then selected under diversity constraints on domain and story type.
• →Draft — stage 6. Each selected item is expanded against a length-bounded schema, one story at a time.
• →Verify — stages 7 and 8. Fact, language and search audits run in separate loops, alongside mechanical checks for numbers, entities, repetition and shape.
• →Gate and publish — stage 9. Four deterministic checks run with no model and no waiver, then the document is rendered against a published contract.
• →The dashed line is the recovery path: a story that cannot be made supportable sends the pipeline back to selection for a bounded replacement rather than shipping a gap.

1. Ingest with provenance attached

A collector interface — collect(start, end) returning normalised items — with six implementations today: RSS and Atom feeds, XML sitemaps, the arXiv API, Hacker News via Algolia, and the Tavily and Exa search APIs. The date-aware collectors matter more than they sound: because they are queried by date range rather than scraped from a rolling feed, a historical window returns the same result today as it will in six months.

Provenance is attached at ingestion, not inferred later. Every source carries a class — first-party, research-lab, editorial, custom — a trust score, and whether it is native to the domain. Twenty-one sources ship by default; the whole registry is replaceable with one environment variable.

→ source-meta.json

2. Relevance filter

Items outside the domain are dropped before any expensive work happens.

→ filtered-meta.json

3. Full-text acquisition

Every surviving item has its full source text fetched — not the feed excerpt, and not only for items whose excerpt looked thin. This is the most consequential decision in the pipeline: the fact-checking stages can only be as good as the evidence they are given, and a two-line description cannot support a 120-word summary.

Fetches are written incrementally and cached per URL, so an interruption partway through several hundred items keeps everything retrieved so far.

→ full-fetched.json

4. Score and classify against a closed vocabulary

Every unique item is rated on six independent 0–100 dimensions, then combined into a single ranking score on fixed weights. The weights live in code, not in a prompt — two runs over the same ratings rank identically.

Ranking weights, fixed in code rather than in a prompt

Dimension	Weight
Impact	24%
Relevance	18%
Practical value	18%
Novelty	16%
Credibility	14%
Overall judgement	10%

Classification happens in the same pass, against a closed vocabulary rather than free text: one of eleven story types, up to eight tags from a fixed 25-term taxonomy, named entities, a primary topic, and a written rationale. A closed vocabulary is what makes output aggregatable — you can count security items per quarter only if nothing ever gets tagged "sec." instead.

If the model backing this stage fails repeatedly, the run stops and preserves every rating it completed. Failed calls are never backfilled with heuristic scores, so an inference outage cannot silently weaken a published issue.

→ rating-full-fetched.json

5. Diversity-constrained selection

Ranking alone produces a monoculture — five items from the same domain, all research papers. Selection therefore optimises signal subject to constraints: a minimum number of distinct domains, a minimum number of distinct story types, and a cap on research-heavy items that relaxes only when nothing else is available.

Selection is also recoverable. A candidate that fails downstream — the source text turns out to be unusable, drafting cannot produce a supportable story — sends the pipeline back here for a bounded replacement attempt rather than shipping a gap.

→ publishing-candidates.json

6. Evidence-bound drafting

Each selected item is expanded against a bounded structured schema: headline, summary, why-it-matters, category, importance, read time. Every field has a hard length limit, and the limits are sized against the model's output budget by the test suite — an unbounded schema promises more than the model can emit and surfaces as a truncated response rather than a clean validation error.

7. The verification triad

Three audits run against every story, in separate loops, with separate budgets.

• Fact audit — every claim is extracted and given an evidence status: supported, partially supported, unsupported, or contradicted, each with the basis for that verdict.
• Language audit — clarity, tone, structure.
• Search audit — headline quality and discoverability.

The same triad then runs a second time at the report level, over the assembled executive summary, trends, companies and research highlights — because a set of individually accurate stories can still be summarised into an inaccurate overview. The report title is generated last, after the stories and body have cleared their gates, so the most-read line in the document describes what the document actually says.

→ publishing-content.json — one entry per draft, per audit, per revision.

8. Deterministic grounding

Mechanical checks that involve no model and cannot be talked out of a verdict, running alongside the auditors. They are described in full below.

9. The publication gate, then publish

Four deterministic checks, then rendering against a published document contract.

→ final-qa.json

The rule that makes verification real

Running a fact check once, at the start, and then editing the text afterwards is not fact-checking the text you publish. So every prose revision — made for readability, made for search — re-enters factual verification before it can proceed.

Rendering architecture diagram…

Read this diagram as text

• →A drafted story enters the fact audit first. Claims that are not supported by the retrieved evidence go to factual revision and come straight back for re-checking.
• →Once the fact audit is clear, the language audit and the search audit run in their own loops, each with its own pass budget.
• →Both of their revisions return to the fact audit rather than moving forward, because a prose edit made for readability or for a better headline can reintroduce an unsupported claim.
• →Only the fact audit can release a story to the publication gate, so the text that ships is the text that was fact-checked last.

Factual, language and search work stay in separate loops with separate budgets; only the fact audit can clear a story for the next stage.

Where code checks, and where judgement checks

Models are good at judgement and bad at arithmetic. Code is the reverse. Each gate is given the work it is actually reliable at.

Numeric grounding. Every number in the generated text must appear in the retrieved evidence. Units are normalised first, so "3 billion", "3b" and "3.0 billion" compare equal, and "20 to 30 percent" expands correctly. A number in the summary that is not in the source is caught arithmetically, not judged.

Entity grounding. A named entity mentioned in a story must be present in the source evidence for that story.

Repetition detection. Near-duplicate sentences within a story are found by similarity threshold, not by asking a model whether it repeated itself.

Length and shape. Word counts, headline character limits, section bullet ranges and coverage minimums — all read from one shared source of truth, so a gate and the contract it feeds cannot disagree.

The gate that cannot be waived

Publication gate: no model, no pass budget, no waiver

• ranking — stories are ordered by descending importance, and ranks match that order.
• publication_floor — no selected item sits below the minimum signal score.
• report_contract — every hard structural requirement of the document holds.
• report_integrity — source attachment and report validation complete without error.

Then the document is rendered against a published contract — exact frontmatter keys in an exact order, every body section always present in the same sequence. The contract is enforced twice: the renderer refuses to return a non-conforming document, and the writer refuses to write one.

An optional section with nothing to say is still emitted, carrying _None this week._ — because "absent" and "empty" are different things to a parser, and only one of them is a shape. Downstream consumers never need defensive code.

What a reviewer can answer afterwards

This is the test that separates an audit trail from logging. Six months after an issue ships, without rerunning anything:

The audit trail, read back long after the run

Question	Answered by
What shipped, and in what order?	Approved stories with ranks, word counts and headline lengths — final-qa.json
Which sources support this claim?	Per-story source URLs, plus the exact retrieved text — full-fetched.json
What did we knowingly let through?	Every advisory carried into publication, attributed to the gate that raised it and the reason it was waived
Did every check actually run?	A named result for all four checks, so a skipped check is distinguishable from a passed one
How did this story evolve?	Every draft, audit and revision in sequence — publishing-content.json
Why did nothing ship this week?	The record is written on failed runs too, with stopped_at naming the stage that ended the run

That highlighted row is the one that matters commercially. Most systems can tell you what they produced. Very few can tell you what they compromised on — and a governance function will ask.

Deployment properties

Inference runs locally. The platform drives local models through Ollama. Source content and generated drafts never leave the execution boundary, and no per-token cost couples briefing depth to budget. For a firm handling client-confidential material this is usually the deciding constraint rather than a feature.

Model roles are separable. Rating, editorial selection and verification each take their own model, all defaulting to a shared base. A stage that needs more capability can be pointed at a larger model without disturbing the others.

State is files, not a database. Every stage's output is human-readable JSON in a per-period directory. Restarting reuses already-drafted stories and already-clean audits. No migrations, no server, and no way for the audit trail to be invisible.

Configuration is total. Every model, timeout, threshold, path and loop budget is settable by CLI flag or environment variable, with flags overriding the environment.

Failure is explicit. Hard validation failures stop publication. There is no degraded mode that emits an unreliable document.

Extension has three sizes. A feed-based source is configuration. A new source type is one class with one method. A different deliverable replaces the contract module and inherits the whole verification spine unchanged.

In practice

Two consecutive real runs of the reference deployment.

Reference deployment: consecutive weekly runs

Stage	Week 30	Week 31
Items collected	98	192
Passed relevance filter	98	191
Fully rated and classified	98	191
Ranked candidate pool	24	24
Published stories	10	10
Replacement rounds needed	0	4
Advisories recorded	34	46
Deterministic checks failed	0	0

Week 31 is the more instructive column. Four replacement rounds means four times the pipeline drafted a story, could not get it to a supportable state, went back to selection, and pulled a different candidate. Forty-six advisories means forty-six known imperfections were allowed through — each recorded, attributed and reviewable. Zero deterministic failures means the hard floor held.

An issue that ships with 46 recorded advisories is more trustworthy than one that ships with none recorded, because the second one is not cleaner. It is just quieter.

Where it fits

The pipeline is domain-agnostic; the vertical is the source registry and the prompts.

• Competitive and market intelligence — continuous monitoring of competitor announcements, launches and funding, classified into a taxonomy that aggregates across quarters.
• Regulatory and policy monitoring — first-party regulator sources with hard provenance, where an unsupported claim is a genuine professional risk.
• Sector and practice briefings — the recurring internal digest, produced at consistent depth rather than at whatever depth the assigned analyst had time for.
• Client-facing publications — a deterministic document contract and a per-claim evidence record are what make an AI-assisted deliverable reviewable at the speed of a spot check rather than a full re-read.
• Internal knowledge digests — the same machinery pointed at internal wikis, tickets and long-form documents.

Extending it

Three extension points, in ascending order of effort.

Add a source. One class with a collect(start, end) method returning normalised items. Feed-based sources need no code at all — they are configuration, including their trust class and quality score.

Change the domain. The relevance filter, the rating rubric, the taxonomy and the drafting instructions are prompts and vocabularies. The scoring weights, diversity constraints and loop budgets are configuration.

Change the deliverable. The published contract is a single module that both renders and validates. A different document shape — a slide outline, a client memo, a structured feed — replaces that module and inherits the entire verification spine unchanged.

Why the architecture is the moat

Anyone can call a model and get a summary. The difficulty is everything around it.

Retrieving evidence good enough to check against. Keeping factual verification downstream of every prose edit. Giving mechanical checks the work models are bad at. Tolerating imperfection without hiding it. And leaving behind a record that answers questions asked months later by someone who was not there.

That is roughly 10,500 lines across 28 modules and 44 tests, and none of it is the model call. The same discipline shows up in the multi-agent orchestrator reference architecture and in the playbook for production LLM applications: the model is the easy part, and the governance around it is the product.

If you are automating a recurring research deliverable and need it to survive review, start a conversation.