Building the Ledger
Performance numbers only matter when the sample is real. We do not publish win-rate claims from sparse or unstable samples. Until the ledger reaches a meaningful decision-grade threshold, this page explains how outcomes are collected, classified, and published.
Current ledger status
These are operational commitments, not marketing metrics. We do not display headline win-rate or loss-rate percentages here while the decision-grade sample is still building.
The count of decision-grade resolved outcomes is still below the publication threshold. Individual rows on radar and proof pages still show their own state.
When checkpoints resolve, outcomes are shown on public proof pages and the radar feed using the same classification rules as everywhere else.
Losses are not filtered out for comfort. If a completed checkpoint is a loss under the rules, it stays visible on the proof record.
Aggregate win-rate style claims wait for enough decision-grade resolved outcomes to avoid fake precision.
Publication threshold
Kahramana will publish aggregate performance only after at least 30 decision-grade resolved outcomes inside a stable methodology window. Until then, this page stays methodology-first and avoids headline win-rate or loss-rate statistics that read like live performance marketing. (This threshold is explained here for transparency; it is not enforced as a separate backend rule beyond the existing public performance pipeline.)
Methodology in plain language
- Signal observed: a public proof row exists because the system recorded a signal worth tracking under the current rules.
- Decision-grade eligibility: some observations are tracked broadly; decision-grade is the stricter slice used when we talk about serious operator utility—not every watch counts the same way.
- Outcome window: checkpoints run on fixed windows so everyone is judging the same clock, not a moving goalpost.
- Resolved outcome: the latest defensible completed checkpoint determines what we can say today; pending stays pending.
- Win / loss / neutral: labels come from those checkpoints and the published thresholds—wins are not cherry-picked spikes and losses stay labeled losses.
- Proof record publication: the proof page is the durable record observers can share and re-read.
- No post-publication edits: we do not rewrite history on published proof to match a nicer story later.
Why we withhold thin statistics
- Small samples lie loudly: a handful of trades can produce extreme percentages that reverse next week.
- Crypto outcomes are noisy: liquidity, funding, and venue behavior add variance that headline percentages hide.
- Early wins or losses can mislead: the first moves are not a stable estimate of process quality.
- Refusing fake certainty is part of the product: if we printed hero win rates from almost no data, we would be selling theater, not auditability.
What you can review right now
Aggregate performance billboards can wait. The public surfaces below already carry posture, checkpoints, and integrity context row by row.
Questions we expect
Because the decision-grade resolved sample is still too small to mean anything useful. We would rather show nothing aggregate than show a ratio that behaves like a scoreboard.
No. When a loss is the honest classification, it stays on the proof record the same way a win does.
Published proof is treated as an integrity surface: we do not silently rewrite outcomes after the fact to make history look cleaner.
It is the stricter slice of tracked observations that matches how we talk about operator-grade setups—see methodology for the full distinction versus broad tracking.
After enough decision-grade outcomes have resolved inside a stable methodology window so the aggregate is not dominated by noise. This page will evolve when that bar is met.