From our research notebook

A Multi-Timeframe Indicator EA

We bring recurring project requirements into one composite example, showing how we organise context, confirmation, entry timing and risk.

We have brought several recurring development requests together in this example. It is a composite, not the disclosure of one client strategy. The starting request was familiar: act when indicators across several timeframes agree.

We unpacked what agreement meant

We asked whether the conditions had to be true together or whether an earlier setup could wait for a later trigger. We also separated the timing rule for the entry candle from the timing rule for higher-timeframe context. Without those answers, two implementations could both appear to follow the brief and still place different trades.

We assigned each decision to a clear part of the system

In the composite design, context describes the market, the setup remembers valid agreement and the trigger chooses the permitted event. Risk then decides whether the account can accept an order. Position management follows the broker's confirmed result, with its own rules for stops, break-even and trailing.

We started the review with understandable scenarios

We use examples such as an expired setup, missing higher-timeframe history, a repeated trigger and a valid signal blocked by risk. Each has an expected answer that can be compared with a record. Broader performance testing becomes meaningful after the software and the written interpretation agree.

Explore the technical detailOpen the full method, worked examples and implementation questions. We have kept this material here so you can follow the reasoning as far as you need.

This case study is not a description of one client system. It combines recurring requirements from eight completed records involving indicator agreement, higher-timeframe context, lower-timeframe triggers, risk-based sizing, and position management. Names, markets, parameter values, links, and proprietary rules are excluded.

The purpose is to show how a familiar request—“trade when several timeframes agree”—can be turned into an architecture that a trader can inspect and a developer can test.

Composite case study · CASE-01

How a trading brief becomes software

The work moves from a clear request to state logic, risk control, repeatable tests, and documented delivery.

  1. 01
    BriefSeparate higher context, setup, lower trigger, exits, and risk permission.
  2. 02
    State mapDefine values, bars, validity, expiry, conflicts, and once-per-event rules.
  3. 03
    Risk layerCalculate size, verify protection, and cap sequence and account exposure.
  4. 04
    EvidenceReplay labelled scenarios and compare logs before broader historical tests.
  5. 05
    DeliveryDocument inputs, assumptions, blocked states, recovery, and acceptance checks.

The request

The recurring brief had a higher-timeframe condition for market context, one or more indicator conditions for confirmation, and a faster timeframe for entry. It also asked for stop and target management, optional risk-based volume, and controls over repeated positions.

Written that way, the method sounds complete. It is not yet testable. “Agreement” could mean simultaneous conditions, a remembered setup, or the latest signal from each timeframe. “Closed candle” could apply to the trigger only or to every layer.

The questions

We first separate market meaning from interface options. For every condition, the specification needs the source, timeframe, exact bar, valid state, expiry, and reset. For the group, it needs AND/OR logic, precedence, and the event that is allowed to evaluate a trade.

The risk questions follow before coding the order path: where the protective distance comes from, how the lot is normalized, how much combined exposure is allowed, whether an opposite signal closes or reverses, and which safety control can veto a valid setup.

  • Are higher-timeframe conditions filters, setups, or direct signals?
  • Must confirmations be simultaneous, or may earlier states remain armed?
  • Which candles are final, and what event creates a new decision?
  • What cancels a setup before the lower-timeframe trigger arrives?
  • What happens when the signal is valid but risk permission is denied?

The architecture

The composite solution uses separate modules. A context module reads the chosen higher bars and produces a stable state. A setup module records whether the required agreement exists and when it expires. A trigger module evaluates the lower timeframe once per permitted event. A risk module decides whether an order is allowed and calculates the intended exposure.

Position management begins only after a confirmed broker result. It supervises the protective stop, target, break-even or trailing state without changing the historical entry signal. Shared logs record both positive states and blocks, so “no trade” can be explained rather than guessed.

The validation path

Validation starts with labelled scenarios, not a long equity curve. The test set includes a valid agreement, an expired setup, a current-bar signal that disappears, a missing higher-timeframe history segment, a duplicated lower event, a blocked risk state, and a rejected or modified order.

Only after those behaviours match the specification does broader historical testing become useful. The goal of the first stage is behavioural equivalence: the code and the written method must make the same decision from the same snapshot.

The lesson

The most important improvement was not another indicator. It was the separation of responsibilities. Once context, timing, risk, and management were independent, changes became safer and test failures became easier to locate.

This composite reflects recurring engineering experience only. It does not reproduce an underlying client strategy and it is not evidence of future trading performance.

Questions you may have

Is this a description of a product sold by POLARIS?

No. It is a composite educational case derived from recurring anonymized development requirements.

Why not publish the indicators and thresholds?

They belong to different private projects and are not needed to explain the engineering lesson.

What was the first acceptance target?

Behavioural equivalence: the specification and the EA should produce the same state and action from the same timestamped data.

POLARIS / R08

A replayable three-timeframe case

Scroll the diagram horizontally or open it at full size.

A replayable three-timeframe case
Educational design example — values and states are not live performance.

Illustrative replay: each layer keeps its own input and timestamp.

Open full diagram ↗

Evidence in practice

A replayable three-timeframe case

This is a constructed teaching case, not a client result. H1 context is bullish after a completed close above a moving average. M15 setup becomes valid when a synthetic oscillator crosses above zero and lasts for two M15 bars. M5 triggers when a completed candle breaks the previous M5 high. Risk permission is independent.

Three paths through the same state machine
Time Input State before → after Outcome
10:00 H1 bullish confirmed No context → context H1-10 Wait
10:15 M15 oscillator cross No setup → setup S15, expires 10:45 Wait
10:25 M5 break; risk allowed S15 valid → request E25 Order confirmed
10:45 Alternative path: no M5 break S15 → expired No trade
11:20 New setup and M5 break; daily limit hit Candidate → risk veto No order; event consumed at expiry
11:30 Restart Restore vetoed event and account state No duplicate entry

The first version of this example re-read H1 after the M5 trigger. In a boundary test, H1 changed between those two reads, so the log combined states that never coexisted. The correction creates one immutable snapshot after all source timestamps pass readiness checks. The repeated test then produced the same decision trace.

Module inputs and outputs are explicit: data layer returns value plus source time and readiness; context and setup layers return versioned states with expiry; risk returns allowed, resized or vetoed; execution returns a request ID and confirmed account state.

What to verify

  • Replay the permitted trade, expired setup and risk-veto paths from frozen synthetic bars.
  • Require every transition to contain source time, state version and reason.
  • Fail the old split-read implementation and pass the immutable-snapshot version in the boundary test.

Limits of this example

The figures and outcomes are constructed to demonstrate method. They do not reveal a private strategy or claim historical client performance.

Research quality record

Editorial ownership and primary references

Reviewed by POLARIS Research

Evidence scope

This is a composite case drawn from recurring implementation patterns. It is not a description of one identifiable client engagement.

Primary references

These references support platform behaviour or research concepts. They do not validate POLARIS performance and do not guarantee future results.

Related research and applications

Explore the next relevant layer

Move between focused research, system engineering and portfolio construction without losing the context of this page.

Multi-timeframe logic without ambiguity →Expert Advisors and automated trading systems →MT4 to MT5 conversion without strategy drift →

Related research