Market Data
InputMulti-timeframe raw market data feed
ResponsibilityIngest, timestamp and hold a chronologically correct record
OutputA shared, versioned market-data context for every downstream stage
Safety boundaryCannot open, close or evaluate any trade
The pipeline begins with continuous ingestion of market data across the instruments Tantoryn AI tracks, processed across multiple timeframes to give every downstream stage the same consistent, time-ordered context.
This layer has no trading opinion of its own. Its only job is to keep a clean, chronologically correct record that later research and runtime components can rely on without re-deriving it themselves.
Candidate Generator
InputThe Market Data layer's chronological context
ResponsibilityDetect formalized, rule-based candidate conditions
OutputA structured candidate object — a hypothesis, not a decision
Safety boundaryCannot score, rank or approve its own candidates
The Candidate Generator (CG) is the first analytical layer. It identifies formalized market candidates — structured conditions in the data that are worth evaluating further — before any ML scoring happens.
A candidate is not a trade decision. It is a hypothesis, produced by explicit, versioned rules rather than by a model. We do not publish the exact proprietary thresholds behind candidate formation; that logic is the part of the system we keep closed by default.
ML Decision Layer
InputA candidate object already formed by CG
ResponsibilityScore and rank the candidate's estimated quality
OutputA model score/rank attached to the candidate
Safety boundaryCannot open a trade or override the risk gate
Machine-learning models evaluate candidates that CG has already formed. Their role is narrow and specific: score and rank a candidate's estimated quality, not invent one from raw market data.
Critically, ML cannot directly open a trade or bypass risk control. A high model score is necessary but never sufficient on its own — every candidate still has to clear the independent risk and lifecycle gate below.
The model architecture behind this layer is under active research and revalidation, so this page intentionally does not describe a specific model family as final. What is fixed is the boundary: ML evaluates, it does not decide alone.
Risk / Lifecycle Engine
InputA scored candidate that has passed ML evaluation
ResponsibilityApply risk checks, exposure limits and lifecycle rules
OutputAn approved signal / virtual trade, or a rejection
Safety boundaryThe only stage authorized to approve a signal; independent of ML
This is the final approval gate, and it is independent from the ML layer by design. It applies risk controls, exposure checks and lifecycle management before anything is allowed to become a signal.
Lifecycle management covers concepts such as stop-loss and take-profit framing, and how an open position is tracked and unwound over time — not just how it is opened.
We describe this engine's role and purpose here without exposing its exact internal risk parameters, which remain closed by default.
Runtime
InputApproved signals plus continuous live market state
ResponsibilityExecute, observe and reconcile virtual trades continuously
OutputRecorded virtual-trade lifecycle events, delivered via Telegram
Safety boundaryREAL_ORDERS hard-disabled; no real-money execution path
The runtime is what keeps the pipeline running against live markets continuously: live market observation, virtual trade execution, and recovery/reconciliation logic that keeps state consistent after restarts or interruptions.
Production and shadow/observation channels are kept isolated from each other at a high level, and delivery to users happens through Telegram.
We do not publish private IP addresses, service names, credentials, ports or security topology. Runtime descriptions on this site stay at the level needed to understand what the system does, not how to attack it.
The Boundary That Matters
Every stage above can be described publicly at a high level because none of them, on their own, reveals the proprietary logic that makes candidates or scores useful. What stays closed is the exact rule set, thresholds and weights — the parts where disclosure would reproduce the edge rather than explain the architecture.
See what the runtime actually produced: live MAIN/SHADOW reports →
