kaldamus

Documentation

Deep-dives into how every persisted entity in the pipeline is derived, mutated, and retired — grounded in the code and the model schema — plus the talks that trace how the pipeline got built.

01

Entity reference

Ten pages, ordered along the pipeline's own flow: raw ingestion → generated narratives → the causal graph layer → forecasting → historical tracking → news → the config surfaces driving all of it → how the system checks itself.

01 · Prediction, Event

Ingestion: Prediction → Event

The raw Kalshi market row and the transform that turns it into the enriched, permanent record everything else reads — plus the one timestamp field the whole freshness system is rooted on.

one row becomes one row
02 · EventSummary, EventScript, Prophecy, GenerationStats

Summaries, scripts & prophecies

Three narrative artifacts and one cost receipt, sharing a single backend-agnostic generator pattern — no dedup, no join table, no corpus-wide identity resolution anywhere in this family.

three narratives + one cost receipt
03 · Factor, EventFactor, EventDependency, FactorObservation

Factor discovery

Every event that clears the priority gate gets a fresh LLM read of its causal drivers. What survives across runs isn't the reading — it's the canonical Factor those readings converge on.

two entities, one LLM call
04 · EventGraph

Event graph

A singleton, fully-disposable recomputation of what events, dependencies, and factor joins already say — plus one structural, falsifiable check: does the market price an effect above its cause?

three shapes, one singleton row
05 · EventForecast, EventForecastHistory

The kaldamus probability

A second, independent probability per event — assembled from causal structure and researched evidence through a deterministic log-odds engine structurally forbidden from reading the market price.

five moving parts, one number
06 · EventHistory

Event history

One probability point per traded event, per UTC day, then compacted back down — a file that used to grow unbounded now has a ceiling by design.

one row, three blocks
07 · NewsArticle, NewsBrief, NewsDispatch

Scan, assess, dispatch

A rolling scan of the open web becomes one wire-desk article a day. What survives between the three stages isn't prose — it's a persisted trace an eval can recompute without trusting the model.

three entities, one daily edition
08 · EnrichmentConfig, EvalConfig, GenerationConfig

Externalized configs

The one page about hand-edited, git-tracked files rather than generated rows — the three parallel registries that decide what every other job in this reference actually does.

three parallel registries
09 · EvalReport, QualityReport, ConfigSnapshot

EvalReport, QualityReport, ConfigSnapshot

One nightly run scores the pipeline against itself and writes three different kinds of row — one keeps a bounded history, one keeps none of its own, one can never legally change.

three entities, three permanence models
10 · SummaryReport, BreaksReport

Pipeline diagnostics

Every full run ends by asking two blunt questions of itself — what's in here, and what fell through the cracks — and answers both in pure Python, no LLM, no network, no history.

two singleton reports, one job
02

Talks & retrospectives

A different format entirely — arrow-key slide decks, not scrolling reference docs — tracing the narrative of how the pipeline got built rather than how any one entity currently behaves.