The short answer to "how would you do the reports?"

Reliable Reports Are a Systems Problem

Trust is not a property of the prose. It is a property of the process that produced it.

The problem

Most attempts to make reports reliable focus on improving the writer: a smarter model, better prompts, a more careful analyst. That approach has a ceiling, because reliability was never a property of writing. A report's worst failure mode is not clumsy prose. It is a wrong claim that nothing catches, and a next edition that quietly forgets the claim was ever made.

So I stopped trying to improve the writer, and built the system around it instead.

The architecture — the writer goes last

Raw data Signals Contradictions State diff Backtests Decisions LLM Publication

A deterministic layer computes the market signals, the contradictions between them, the diff against the previous edition, and event-study backtests of the signals' own history. By the time the language model writes, the analysis already exists. The model renders decisions. It does not make them. It cannot invent a trend the data did not show.

The publication rules — enforced, not aspired to

These are constraints, not a style guide. The report cannot be produced without satisfying them, so reliability does not depend on anyone's discipline on a deadline day.

The report keeps score on itself

From the live July 2026 edition — the honest ledger, verbatim in substance
Scenario probabilities are frozen at publication and Brier-scored when they resolve. The calibration ledger opened with the July edition; its first entry resolves in August. The track record accrues in public.

Where this sits in the landscape

LayerThe question it answersIts unit
Generation (crowded)How do we generate a better report?a draft
Grounding & provenance (table stakes)Can I justify this sentence?a citation
Evaluation (growing fast)Did the model produce a good answer?an output
Publications (this work)Does this publication deserve trust over time?an edition

The first three layers evaluate outputs — a request, a response, a score. A publication is a different unit, because it has the one thing an output does not: memory. It remembers what it claimed, what it scored, and what it corrected. Every mechanism on this page only makes sense for a unit with memory.

How to evaluate a system like this

Not by asking "is this report good?" — a single report is just an assertion. The evaluation is longitudinal: how does the publication behave across editions? Did the calls survive? Were the probabilities appropriately confident? Were corrections disclosed? Reliability is earned across editions, and everything above exists to earn it mechanically.

See it live

The one-line version: reliable reports do not come from better writers. They come from better publication rules — decided once, enforced by software, and scored in public across editions. The language model writes last. The platform is the editor.