How Kahramana turns signal noise into decision structure.
This page explains the live public methodology at a level that is real, auditable, and useful. It stays high-level where proprietary detail matters, but it does not hand-wave the logic that drives public proof, posture, and tracked outcomes.
The public proof system reflects the same underlying versions used to normalize opportunities, assess risk, and derive posture. The exact internals are not exposed in full, but the workflow and classification rules remain deterministic and consistent for the same published record.
The public methodology is there so traders can inspect how posture, classification, and proof integrity are derived before they ever start a trial.
How signals are detected
Kahramana groups public signals into a few recurring categories: launch signals, structure signals, wallet behavior, and migration signals. Those categories are derived from normalized market events, score context, guardrails, and routing state. They are meant to help a trader understand what surfaced, not to imply that every surfaced setup should be executed.
Early market-structure changes around newly forming opportunities or launch-style setups.
Liquidity, score breakdown, and policy context that indicate whether a setup is coherent or fragile.
Supportive or suspicious wallet patterns that change confidence without pretending wallet activity is destiny.
Cross-venue or liquidity-shift context that can reinforce, weaken, or invalidate a thesis.
How scoring works
Scoring is deterministic for the same normalized input. The system considers structural context, risk context, momentum or follow-through context, and policy framing. A higher score means the setup looks stronger under the current scoring version. It does not mean a move is guaranteed, and it is not a promise that live execution is supported.
Guardrails and posture
Kahramana does not flatten every signal into a trade idea. The public posture is derived from the same support logic used inside the product. A setup can remain signal-only, become paper-ready, stay guarded-live, or be blocked outright.
Visible for review, but the path is not execution-ready.
Paper execution is supported on this path and remains the default posture.
Live eligibility exists only when the runtime, venue, credentials, and policy checks line up.
The system intentionally says no because a guardrail, liquidity limit, support boundary, or risk policy was triggered.
The posture logic shown publicly corresponds to the support derivation used in code, including guardrail events, capability policy, and routed execution posture. Blocking a trade is part of the product, not an error condition.
Outcome tracking
Public outcomes are measured from stored published proof records across the active tracking windows. Today those checkpoints are 5m, 30m, 4h, 24h. The system stays explicit when checkpoints are still pending or when data is incomplete, instead of backfilling a flattering story.
Limitations still matter. Public tracking depends on stored checkpoints, and some paths can legitimately remain pending or insufficient if the window has not completed or the outcome data was not available at the checkpoint.
Classification rules
Public proof classification uses the stored checkpoints rather than cherry-picked spikes. The current implementation follows the classification utility used by the proof system: later completed checkpoints outrank earlier incomplete ones, and the outcome is labeled as win, loss, neutral, pending, or insufficient data according to the latest defensible checkpoint.
The public explanation here reflects the same logic implemented in the proof classification utility used to render proof pages and the performance page.
What Kahramana does not do
The system is built to improve decision quality and make proof auditable. It does not remove the need for operator judgment.
The system is built to improve decision quality and make proof auditable. It does not remove the need for operator judgment.
The system is built to improve decision quality and make proof auditable. It does not remove the need for operator judgment.