Why backtest narration is a different problem from live narration
Every other use case built on Konseki data — chat answers, screening, portfolio risk, position sizing — operates on today's snapshot, reasoning about a setup that exists right now. Backtest narration is structurally different: it needs to reason about a setup that existed on a specific date in the past, using only the information that was actually available on that date. That distinction sounds minor. It's the entire reason this use case requires its own approach rather than just pointing a model at historical data and asking it to comment.
A model asked to explain why a backtested trade entered on a given date "made sense" needs to be reasoning from what the data looked like on that date — not from data that has since been revised, not from a model trained on information that postdates the trade, and not from a live recomputation that reflects the current universe rather than the universe as it stood then.
Get this wrong and the narrative becomes a story about why the trade looks reasonable in hindsight — a different and far less useful thing than an explanation of why it looked reasonable at the time.
Why immutable snapshots are what make this possible
Konseki's daily output is stored as a permanent, dated artifact rather than recomputed on demand:
This is the same architecture described there, and it's what makes backtest narration tractable at all. Querying a specific historical date returns the exact output the engine produced on that date:
?lookback=15
&date=2026-03-14
// returns the exact output the engine produced
// on March 14th — same matches, same scores,
// same distributions. Nothing changes based on
// what's happened since.
A narrative built on the live-recomputed kind of reconstruction is describing a hypothetical, not a historical fact, even though it can be made to look identical to one.
Avoiding lookahead bias in the narrative itself
Lookahead bias in a backtest engine — letting future data leak into a past decision — is a familiar risk and usually guarded against in the trade logic. It's less commonly guarded against in the narrative layer sitting on top of the backtest, and that's exactly where it tends to creep back in.
The fix is mechanical: the narrative generation step should only ever receive the Konseki response for the exact historical date being narrated — never today's snapshot, and never a model's general knowledge of how the broader period played out.
What a useful backtest narrative actually explains
A backtest report listing entries, exits, and a return series answers "what happened." A narrative layer built on the dated Konseki snapshot for each entry can answer the more useful question: "why did the strategy logic consider this a setup worth entering, given what was knowable at the time."
| What the narrative surfaces per trade | Source |
|---|---|
| Why the entry was justified at the time | similarity_score and match_quality of the matches available on that date. |
| How strong the evidence was at entry | The forward outcome distribution and tags.reliability available at entry. |
| How the trade actually played out | Comparison of actual outcome vs. what the historical distribution would have predicted. |
This is where the narrative becomes diagnostic rather than just descriptive. A strategy that performed well overall but whose individual trades were frequently entered on thin, low-reliability matches is a different and more fragile result than one where every trade was backed by high match quality and strong evidence counts. A summary statistic like a Sharpe ratio doesn't surface that distinction. A narrative built trade-by-trade from the dated snapshot data does.
What this looks like in practice
A backtesting tool that logs, for each trade, the date of entry alongside the strategy's logic, can fetch the Konseki response for that exact historical date for the relevant symbol and lookback window — not today's snapshot, the dated one. That response becomes the input to a model generating a short explanation of the entry: what the historical match set looked like at that point in time, how reliable that evidence was, and how the trade's actual result compared to the distribution that was available when the decision was made.
Run across a full set of backtested trades, this produces something closer to a readable case-by-case review than a results table — one that's still grounded entirely in what existed on each entry date, because the underlying data architecture has no other state to offer.