The problem with full-context screening
A single Konseki response for one symbol carries a complete picture: outcome distributions, match quality scores, MAE/MFE, reliability tags, and pre-written commentary. That's exactly the right amount of detail for grounding a single conversational answer or a pre-trade review. It's the wrong amount of detail for deciding, across a 300-symbol watchlist, which five symbols are actually worth a model's attention this morning.
Passing the full JSON for every symbol into a model just to ask "is anything interesting happening here" is an expensive way to answer a cheap question. Most symbols on most days will show unremarkable historical context — moderate everything, no notable risk, nothing a trader needs flagged. Spending model tokens to read and discard that output at scale doesn't add value, it just adds cost and latency.
What the tag fields are for
Every forward outcome window in a Konseki response includes a tags object with categorical fields — direction, consistency, reliability, risk, and outlier. These aren't meant to replace the underlying distribution data; they're a compressed, programmatically filterable summary of it.
"tags": {
"direction": "bullish_strong",
"consistency": "moderate",
"reliability": "high",
"risk": "normal",
"outlier": "none"
direction resolves to values like bullish_moderate, bullish_strong, bearish_moderate, or neutral. risk resolves to values like high_tail or normal, reflecting whether the historical outcome distribution showed meaningfully more downside tail risk than typical.
The point of these fields is that they can be read and filtered with simple conditional logic, before any model call happens. A screener doesn't need to understand percentile distributions or match quality scoring to ask whether a symbol clears a bar — that's a direct field comparison, not an interpretation task:
// no model call needed for this check
if (tags.direction == "bullish_strong"
&& tags.risk != "high_tail") {
// flag for stage two
How the triage actually works
The practical pattern is a two-stage pipeline:
Whether that's "show me everything with elevated tail risk" or "show me everything with a strong, consistent bullish signal," the filtering criteria can change per screening question without touching how either stage works.
Why categorical filtering beats threshold filtering on raw numbers
It's tempting to skip the tag fields and filter directly on raw numbers instead — say, positive_return_rate > 0.6. This works, but it reproduces logic that's already been computed and encoded in the tags, and it's easy to get subtly wrong.
Filtering on tags.reliability == "high" alongside tags.direction gets closer to "this is a real signal" than filtering on the raw return rate alone would — without a screener having to separately reason about evidence_count, diversity.score, and the return distribution all at once.
What this looks like end to end
A morning screener job fetches Konseki data for the full watchlist, filters in code for symbols where tags.direction indicates a strong directional lean and tags.risk doesn't flag elevated tail risk, and passes only that filtered subset — typically a handful of symbols out of hundreds — to a model for narrative commentary.
The output is a short, model-generated briefing covering only the symbols worth a trader's attention that day, generated at a fraction of the token cost of running every symbol through the model unconditionally.
The tag fields don't replace the deeper distribution data — they're what makes it possible to decide, cheaply and at scale, which symbols deserve that deeper data's full attention in the first place.