Methodology/AI grounding
AI grounding

Reducing LLM hallucination
with grounded historical data.

A trading assistant that answers from training data alone is guessing. This is what that means in practice, why it happens, and how grounding a model's response in pre-computed historical evidence closes the gap.

Why models hallucinate market statistics

Large language models are trained on a fixed corpus up to a cutoff date. Ask one "how has AAPL historically behaved after a setup like this" and it has two options:

Option 1 — Decline
Decline to answer with any specificity, since it has no real computation to draw on.
Option 2 — Guess
Generate something that sounds statistically plausible based on patterns in its training data.

The second option is where hallucination comes from — not malice or carelessness, but the model doing exactly what it's built to do: produce a plausible continuation of the prompt.

The output can look completely credible. A confident sentence like "similar setups have historically shown a 65% positive rate over the next week" reads identically whether it's grounded in a real computation or invented to match the shape of a plausible-sounding answer. There's no signal in the text itself that distinguishes the two. The model isn't lying — it doesn't have access to the actual historical record for that specific symbol, that specific date, and that specific price condition, so it produces its best approximation instead.

This is a structural limitation, not a model quality problem. A better model trained on more data still has the same gap: it has broad knowledge about markets in general, but no live computation of what a specific symbol's price action actually looked like relative to its own history, and no record of what happened next in genuinely comparable historical conditions.

What "grounded" actually means

Grounding means the model isn't asked to recall or estimate a statistic — it's given the statistic directly, in the prompt, and asked to reason from it.

The distinction matters because it changes what the model is doing at the point of generation. Instead of completing a pattern from training data, it's reading a number that was computed upstream and reporting or interpreting that number.

Konseki's output is built for exactly this. Each response includes a commentary object with pre-written natural language fields — headline, summary, risk, takeaway — alongside the raw numeric data they're derived from. A model can quote these directly, rephrase them, or use them as reasoning scaffolding, but in every case the underlying claim traces back to a real computation rather than the model's own estimate.

When an assistant says "similar setups had a worst historical outcome of −7.6% over five trading days," that number isn't generated by the model — it's read directly from the response:

// what the model is given, not what it generates
"forward_outcome": {
  "5": {
    "returns": {
      "worst_return": -0.076
    }
  }

}

The number is verifiable, sourced, and specific — not a statistical generalization the model produced from pattern-matching its training data.

Why this needs to be pre-computed, not fetched live

Grounding only works if the data injected into the prompt is actually correct for the specific symbol and date being discussed. That requires the same cross-market historical search described in the precomputation piece — comparing a symbol's current price path against a decade of history across hundreds of symbols, scored across seven structural dimensions. An AI assistant calling this kind of system needs the answer in milliseconds, at the moment a user asks a question, not after a multi-hour batch computation.

This is why Konseki's snapshot architecture matters specifically for the AI-builder use case. The expensive search already happened after the prior market close. What the assistant calls at request time is a stored result, not a live computation — so the grounding data arrives fast enough to sit inside a normal conversational response.

What the model still has to get right

Grounding removes one failure mode, not all of them. A model given accurate historical data can still misinterpret it, overstate its confidence, or drop important caveats when summarizing. This is why Konseki's output doesn't just include raw numbers — it includes the qualifiers that prevent a model from accidentally manufacturing false confidence on top of real data.

FieldWhat it gives the model
analysis.evidence_countHow many historical matches were actually found, so a model reasoning from five matches sounds different than one reasoning from fifty.
reliability tagReflects evidence count and match diversity together, so a thin or concentrated match set doesn't get reported with the same confidence as a broad one.
commentary languageWritten in confidence-hedged language — "historically leaned," "tended to" — for the model to draw on directly rather than inventing hedged phrasing itself.

None of this prevents a model from being careless with the data it's given. But it means the data it's given is honest about its own limitations, which gives a well-prompted model the material it needs to be honest too.

What this looks like in practice

Chat assistant
Stock Q&A with historical grounding. User asks "how has AAPL behaved after setups like this?" — your assistant fetches the Konseki JSON and responds with actual historical outcome distributions, not general market knowledge.
Research copilot
Pre-trade context generation. Before a user reviews a position, inject the Konseki JSON into a system prompt. The model surfaces relevant risks, positive rates, and match quality without the user having to ask.
Alerts & digests
Automated morning briefings. Fetch Konseki data for a watchlist every morning, pass each symbol's JSON to a model, and generate a structured briefing: what setups are elevated risk, what looks historically constructive.
Watchlist screener
Triage at scale, comment on what matters. Use tags.direction and tags.risk to filter hundreds of symbols programmatically. Pass only high-quality setups to the model for commentary — scale without burning tokens on weak signals.
Signal explanation
Turn raw signals into evidence-backed narratives. When your trading system fires a signal, use Konseki to generate a natural language explanation of what history says about this setup — so users understand the evidence behind the call, not just the outcome.
Portfolio risk scanner
Narrate risk across an entire portfolio. Run Konseki across all holdings, flag positions where historical context shows elevated downside risk or poor match quality, and let the model generate a full portfolio risk narrative in one response.
Earnings context
Grounded pre-event analysis. Before a catalyst event, inject historical context for how the stock has behaved in similar technical setups heading into earnings. Grounded pre-event analysis — not generic sentiment or training data guesses.
Position sizing
Reason about size and stops from real data. Inject MAE/MFE and full distribution data into a prompt and let the model reason about appropriate position size and stop placement — grounded in what history actually shows, not rules of thumb.
Backtesting narrative
Make backtest results readable. Fetch historical snapshots and use a model to generate natural language analysis of how a strategy performed — turning raw backtest output into something non-technical users can actually understand and act on.

In each case, the mechanism is the same: the model is reasoning over evidence it was handed, not recalling a pattern it half-remembers from training.

That's the actual difference between a hallucinated statistic and a grounded one — not how confident the sentence sounds, but whether a real computation sits behind it.

Ready to see it in practice

Read the schema.Then query it yourself.

Every field on this page is documented in full in the API reference.