Direct answer
Assessing Schaff Trend Cycle means collecting enough information to (1) define what the indicator is calculating, (2) recreate the calculation from the same inputs, and (3) judge how dependable the output is under different data conditions. Since you are not assuming real-time prices, focus on the data needed for the indicator’s computation and for verifying that different sources are measuring the same thing.
At a minimum, you need: the indicator mechanics (so you know which series are inputs), the underlying time series (price data and timestamps), the timeframe and parameter settings used, and quality/timeliness checks (so you know what the indicator is reacting to rather than artifacts). You also need at least one limitation or failure mode to explain why results can diverge.
Mechanism and definition: what data the indicator depends on
A practical way to start is to treat Schaff Trend Cycle as a transformation of market price history into an oscillator-like series. To assess it, you need to know which price field is used (commonly something derived from OHLC data), and how that field is sampled over time.
The data inputs you should gather are:
- Underlying price series: the exact source of prices (for example, the specific dataset or data vendor that provides candles or ticks). Include whether values are raw, adjusted, or already processed.
- Timestamping and timeframe: the sampling interval (e.g., 5-minute, 1-hour, daily) and the time zone convention. Misaligned time zones can cause a recomputation to differ.
- Computation settings: any parameter choices used to generate the indicator values. If a platform allows multiple parameter sets, you must record which ones were used.
- Update rule: whether the indicator uses fully formed candles only, or whether it recalculates intra-candle. This affects timeliness and comparability.
To separate stable mechanics from variable conditions, record the indicator’s “stable” parts (formula and settings) separately from the “variable” parts (data source, sampling interval, and whether prices are adjusted).
Evidence and example: what to verify so it is independently checkable
Because you may not rely on a single platform, the key evidence is whether you can reproduce the indicator series from the same dataset and settings.
A concrete, checkable workflow is to:
- Fix assumptions: Choose one timeframe, one price field (as specified by the indicator definition you are using), and one parameter set. Write these down explicitly.
- Freeze the dataset: Use a specific historical window with start and end timestamps. If your dataset includes revisions (e.g., adjusted data), note the version or retrieval time.
- Recompute and compare: Calculate the indicator on your side (or in a different tool) using the same inputs. If values differ materially, treat that as an assessment result: it indicates a mismatch in price data, timeframe alignment, parameter usage, or update rule.
For example, if Platform A computes the indicator on candle closes but Platform B computes it on the latest partial candle, you might observe differences even when the parameter set matches. Without recording the update rule, you cannot attribute differences to the indicator itself.
Limitations and risks: what can go wrong
Even with perfect documentation, assessment has material limitations.
- Data regime changes: Historical relationships can break when market conditions change. The indicator output may behave differently across volatility regimes.
- Nonstationarity: The statistical character of price series can vary over time, so an indicator that looks stable in one period may not generalize.
- Parameter sensitivity: Small changes in indicator settings can lead to noticeably different oscillator values. If parameter choices are not recorded, assessments become non-reproducible.
- Execution and costs (conceptual): If someone tries to convert indicator readings into decisions, execution frictions and spread/fees can change real outcomes. That means correlation between the indicator and outcomes is not the same as a reliable forward expectation.
- Failure mode from inconsistent inputs: The most common failure is comparing outputs computed from different price fields, time zones, or candle types (close vs. typical price, fully formed vs. partial). In that case, the assessment answers the wrong question.