Methodology
How Syntalium evaluates markets
A plain-English explanation of the evaluation rules, market condition taxonomy, setup hierarchy, freshness contract, and SNAP proof boundaries.
01
The closed-candle rule
Syntalium evaluates completed market data — candles that have fully closed — not data from a candle that is still forming.
This eliminates a category of distortion common in signal systems: repainting. A system that reacts to unfinished candles can appear to have predicted a move that it was actually still forming at evaluation time. By requiring the candle to be closed before evaluation, the system captures a fixed, verifiable state.
The result is a record of what was observable at evaluation time, not what the chart later showed it could have been.
02
Market condition taxonomy
The system classifies each evaluation cycle into one of five market condition labels. These are structured observations — not commands to buy or sell.
Market structure is coherent. Evaluation criteria are met for normal analysis. Not a trade instruction.
Elevated uncertainty or conflicting signals. Conditions are in transition. Not a trade instruction.
The system is not publishing a setup for this cycle. Users should not force an entry.
Market conditions do not meet publication criteria. No setup is available for this cycle.
Data required to evaluate market condition is missing, stale, or withheld by safe-mode rules.
03
Setup hierarchy
A setup state is only displayed when a real public signal has been published. Plan fields — entry zone, stop loss, take profit targets, and leverage range — are withheld unless a LONG SETUP or SHORT SETUP is active.
LONG SETUP
A real published signal exists and its direction is long. Entry zone, stop, targets, and leverage are shown only when this state is active.
SHORT SETUP
A real published signal exists and its direction is short. All plan fields are shown only when this state is active.
WAIT
No setup is being published for this cycle. Market condition may be valid but no directional setup is available.
NO TRADE
Market conditions actively fail publication criteria. No setup is available and no entry should be forced.
UNAVAILABLE
The signals endpoint is unavailable, the data is stale, or safe-mode is active. Entry and plan fields are withheld.
04
Setup eligibility checklist
Before acting on any published setup, a user should verify each of the following. This is a minimum due-diligence framework — not a guarantee of outcome.
- 01Check the entry zone — is price still within range?
- 02Check setup status — is the signal still active (not expired or invalidated)?
- 03Check freshness — is the underlying data FRESH?
- 04Check the published expiry time — has the setup window passed?
- 05Verify the SNAP ID — confirm payload integrity before relying on the record.
- 06Review your own risk plan — stop distance, position size, and total exposure.
05
Data freshness
Every published record reports the freshness of the underlying data. Stale data means the evaluation was performed on inputs that are older than the expected threshold. A setup published against stale data may not reflect current conditions.
Data age is within the expected threshold. Evaluation is based on current data.
Data is older than the freshness threshold. The display is accurate to the last published cycle, but it may not reflect current conditions.
Freshness cannot be determined. The data source is unavailable or the endpoint is not responding.
06
Safe mode
When required data is stale, incomplete, or does not meet quality thresholds, the system may withhold new setup publications rather than produce a record based on degraded inputs.
In this state, the platform displays UNAVAILABLE or NO TRADE rather than inventing a position based on unreliable data. Users should treat safe mode as a signal to wait for fresh data, not as an instruction to act.
07
SNAP proof
Each evaluation cycle produces a canonical payload: a deterministic, ordered representation of the data and decisions the system recorded at that timestamp.
A SHA-256 hash is computed over that payload and published as the SNAP ID. The SNAP ID can be submitted to the public verification endpoint at any later time to confirm that the archived payload still matches the stored hash.
Verification flow
- 01The system records a canonical payload for the evaluation cycle.
- 02A SHA-256 digest is computed over the canonical UTF-8 bytes.
- 03The payload and digest are archived and the SNAP ID is published.
- 04A user submits the SNAP ID to /verify.
- 05The backend recomputes the digest and returns VERIFIED, MISMATCH, PAYLOAD_MISSING, or NOT_FOUND.
08
Proof boundaries
Verification is a precise, limited contract. Understanding what it covers and what it does not cover is essential to using the system accurately. SNAP verifies recorded payload integrity. It does not verify model correctness, upstream data accuracy, exchange execution, user fills, profitability, or future market direction.
What SNAP proves
- The canonical payload was recorded at the stated timestamp.
- The SHA-256 hash of that payload matches the stored expected digest.
- The archived payload has not been silently modified since publication.
What SNAP does not prove
- Trading profitability or expected returns.
- That a user executed at the published entry zone.
- That an exchange filled an order at a specific price.
- That a setup was suitable for any individual user.
- Future market direction.