We explain what our development experience covers, what each kind of work produces and which questions we need to settle before starting a new project.
Our projects did not all begin with a new Expert Advisor. Some started with an indicator that needed connecting, an MT4 system that needed moving, or existing code that no longer behaved as expected. We built this capability map to make those different kinds of work easier to discuss.
We start with the job the software must do
A request for “automation” can mean an alert, a scanner, an order engine or a tool that manages positions opened elsewhere. We first identify the input, the decision and the expected output. That tells us what we can build and what evidence would show that it works as agreed.
Experience helps us ask better questions
Indicator integration brings questions about accessible buffers and changing signals. Migration brings questions about account mode and order handling. A portfolio manager brings questions about position ownership and shared limits. The matrix links each capability to a concrete output, its dependencies and an acceptance check, so the conversation goes beyond a list of technologies.
We keep feasibility specific to the project
Having worked in an area gives us a useful starting point. It does not settle whether a new private indicator exposes usable data or whether a proposed rule is clear enough to test. We work through those dependencies with the person behind the idea, while keeping client rules, source code and access details confidential.
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.
A capability matrix is more useful than a long list of strategy names. It shows the type of technical problem a team has already learned to define, build, test, or repair. The matrix below is based on recurring work patterns in our archive, not on disclosure of any single client project.
It is also not a product catalogue. A new collaboration still begins with the market idea, the intended use, the platform, the risk boundaries, and the evidence available.
Engineering map
How one request moves through development
First define the intended behaviour, then build the operating logic, and finally check that the result behaves as requested.
01
DefineMarket idea, platform, inputs, states, risk boundaries, and acceptance criteria.
02
EngineerSignal logic, order handling, synchronization, controls, logging, and recovery.
03
ValidateReproduction, historical checks, operational tests, and behaviour comparison.
CapabilityTypical problemPOLARIS focus
EA development
Turning a discretionary or written method into repeatable rules.
Specification, state logic, order handling, testing, and readable controls.
Indicator automation
Converting a visual signal into an alert, scanner, or executable condition.
Buffer/state interpretation, closed-bar rules, repaint checks, and signal timing.
MT4 / MT5 conversion
Moving established logic while platform APIs and execution models differ.
Behavioural equivalence, symbol handling, testing, and migration checks.
Multi-timeframe systems
Keeping higher- and lower-timeframe decisions synchronized.
Closed-bar policy, event timing, history readiness, and session boundaries.
Risk & trade management
Sizing, supervising, or closing positions under defined account rules.
Risk-based lots, exposure limits, daily controls, recovery, and emergency states.
Dashboards & scanners
Monitoring several symbols, timeframes, or conditions without losing context.
Efficient refresh, clear states, alerts, filtering, and operational readability.
Renko & custom data
Running logic on non-standard charts or transformed price series.
Brick construction, duplicate-event control, synchronization, and historical consistency.
Grid, hedge & basket control
Managing linked orders where exposure can grow or interact.
Hard limits, basket accounting, exit authority, stress behaviour, and transparent risk.
Python / MT5 integration
Moving data or decisions between MetaTrader and an external process.
Data contracts, failure handling, timing, logging, and safe fallbacks.
Debugging & modernization
Finding why an existing tool freezes, duplicates, differs from its test, or no longer compiles.
Reproduction, logging, isolation, compatibility, and controlled refactoring.
Session, news & execution filters
Preventing valid logic from trading in unsuitable operational conditions.
Timezone, calendar state, spread, slippage, liquidity, and order-result checks.
Portfolio supervision
Coordinating risk when several independent systems share one account.
Combined exposure, interaction, priorities, shared limits, and monitoring.
The recurring foundation
Different strategies still share the same engineering foundation: deterministic inputs, explicit state changes, controlled order handling, defined risk, useful logs, and a test plan that matches the intended environment.
This is why a system with simple entry logic can be a serious development project, while a complicated-looking strategy may remain impossible to test until its definitions are cleaned up.
What this matrix does not publish
The matrix deliberately stops before proprietary formulas, client rules, source code, account details, and project links. It describes engineering coverage, not the private implementation of a strategy.
For a new enquiry, the useful starting point is a concise description of the market idea, platform, inputs, outputs, risk boundaries, and what would count as a correct result.
Questions you may have
Is every capability available as an off-the-shelf product?
No. The matrix describes engineering experience. Scope and suitability still need to be defined for each collaboration.
Does POLARIS publish client source code or specifications?
No. Private implementations, identities, and proprietary parameters remain confidential.
POLARIS / R02
Turn a capability claim into a scoping decision
Scroll the diagram horizontally or open it at full size.
Educational design example — values and states are not live performance.
Illustrative deliverables; these are not claimed client records.
A client should be able to see what a capability produces, what it depends on and what would count as a successful delivery. The matrix below makes that distinction explicit. ‘Supported’ means the archive and current engineering practice provide a relevant starting point; it does not promise that every request is feasible before discovery.
Audit-ready capability matrix
Capability
Observable output
Main dependency or limit
Acceptance check
EA development
Versioned EA, settings and decision log
Rules must be observable; profitability is outside software acceptance
Frozen scenarios produce the agreed signals and orders
Indicator automation
Named buffer or object mapped to signal events
Source output must be accessible and repaint behaviour known
Captured values and EA events agree at decision time
MT4 / MT5 conversion
Event-by-event parity report
Account mode, symbol data and platform semantics can require approved changes
Signal, size, fill, modification and exit traces reconcile
Multi-timeframe systems
Timestamped context, setup and trigger states
Every series needs a bar policy and readiness test
Missing or late bars never enter a valid snapshot
Risk and trade management
Sizing, exposure and stop-authority record
Requires reliable symbol properties and account-wide ownership
Boundary, gap, partial-fill and restart tests pass
Dashboards and scanners
Candidates with source time, expiry and reason
A display refresh cannot be treated as trade permission
Stale rows, ties and duplicate events resolve deterministically
Renko and custom data
Versioned, replayable bar sequence
Synthetic bars are not executable market prices
Clean start and restart produce the same completed bars
Grid, hedge and basket control
Gross exposure, basket loss and intervention state
Recovery is never assumed; exits may fail
Depth, trend, gap and rejected-close scenarios respect hard limits
Python / MT5 integration
Versioned message schema and acknowledgement trail
Transport, clock and model artefact must be defined
Stale, duplicate and incompatible messages fail safely
Debugging and modernization
Reproduction case, cause and regression test
A symptom without reproducible inputs may remain conditional
The failure is reproduced before the fix and absent afterwards
Session, news and execution filters
Permission state with clock and data age
Broker time and calendar revisions must be handled
DST, stale news and late-tick boundaries match the contract
Portfolio supervision
Ownership ledger, shared reservations and veto log
Independent EAs must cooperate with one authority
Duplicate events and restarts converge to one account state
Example A is supportable after discovery: ‘open once on a confirmed closed-bar indicator cross, size by stop loss, and block the entry above a shared account limit.’ It maps to indicator automation, EA development and risk management, with concrete replay tests.
Example B remains conditional: ‘use an opaque compiled indicator, a proprietary Python model and guaranteed sub-millisecond execution at every broker.’ Until the indicator output, model contract, hosting path and broker constraints are available, nearby archive experience cannot fill those unknowns.
What to verify
Mark every requested row supported, conditional or unproven and attach its evidence type.
Name the platform, external dependencies, deliverables and one acceptance test before estimating scope.
Keep an empty evidence cell visibly unknown; do not convert similarity to proof.
Limits of this example
The public archive shows categories of work, not source code, acceptance records or current capacity for every variation. The matrix is a discovery tool, not a promise of performance.
Research quality record
Editorial ownership and primary references
Reviewed by POLARIS Research
Evidence scope
Counts and lessons use an anonymized internal archive. Client identities, code, account data and private specifications are excluded.
