AR-APP-001·PL-01 — The facility, drawn as a plan. Stylised brand illustration of the laboratory, not a photograph of a physical facility. The charts and figures inside the plate are simulated.

Record AR-APP-001 · Application Roadmap

Five stages, twenty-five modules,
and an honest label on every one.

This page is the construction drawing for the AlphaRail Foundry application. It sets out the five stages of the intended product, every module inside each stage, and — attached to each module — a level that states plainly whether the thing is built and working today, demonstrated as an interactive preview of intended behaviour, or currently nothing more than a description. There are no dates on this page, and there is no attempt to make the picture look further along than it is.

Status Planning document Stages 5 Modules 25 Levels 3 Updated 2026-07

Read this as a specification, not as an announcement

Everything below describes intended behaviour. A module at Level 2 or Level 3 is a design decision that has been made and written down; it is not a commitment to ship, a claim that engineering is under way, or a promise about scope. The parts that exist are marked Level 1 and can be operated right now from the pages linked throughout.

01bSpecification ExpansionAR-APP-001·SPEC

The plan grew.
Here is exactly where.

The five stages below still describe how the application gets built. What sits inside them has expanded a great deal, and the expansion is documented in full in the Application section rather than summarised away here. Six laboratories, each with its own record.

I Strategy Foundry Twenty families, ten executable modules each, five specialist families, a five-stage module builder and six configuration depths. Open → II Branch Architecture Up to thirty branches, each with a complete structural definition, plus branch groups, seven rotation models and an auto-calculated deployment planner. Open → III Trade Flow and Concurrency Five processing modes, eight concurrency ceilings, weekly volume configuration, seven allocation models and six daily allocation methods. Open → IV Risk and Sizing A 0.25%–20% range in quarter-point steps, fourteen assignment modes, eleven concurrent risk pools and ten compounding bases. Open → V Results and Scoring One transparent quality score, ten weighted components, eight hard disqualification safeguards and a generated executive conclusion. Open → VI Wizards and MARS Governance The framework library with four honest fidelity classes, and the governance laboratory: gates, seven tiers, cycle pools and throttle. Open →

None of the six is finished. The level marks throughout the rest of this page apply to the original module set; the specification pages carry their own build state, and the facility status page remains the single place that states what can be operated today. The capability matrix maps every specified capability to the plan intended to carry it.

01Facility BlueprintAR-APP-001·BP

The application, drawn
as a facility plan.

The five stages are not a feature list arranged for a marketing page. They are a workflow with a direction of travel: you build a framework, you put it under pressure, you find out what broke, you impose an authority that limits the damage, and only then do you iterate. Each bay below carries its modules with the functionality level attached to each one, so the drawing shows the gaps as clearly as it shows the structure.

Why the plan reads left to right

Each stage consumes the output of the one before it. A diagnosis module has nothing to diagnose until a simulation has produced a population of outcomes, and a simulation has nothing to run until a framework has been fully specified. The order is a dependency, not a preference.

The bays are not equally advanced

Test, Diagnose and Govern each contain working analytical modules today because they operate on model outputs. Build and Refine are almost entirely absent because both require persistence — somewhere to keep a framework once you have made one.

Nothing here reads a market

Every Level 1 module operates on the deterministic preview engine. None of them touches price data, a broker, or your account. That single limitation is the reason several modules that look nearly finished are recorded as Level 2.

02Functionality ClassificationAR-APP-001·CLS

Three levels,
defined precisely.

The classification exists because “coming soon” is not a status. A level is assigned by one test: what happens when a visitor clicks the thing. If a real computation runs and a real result is produced, it is Level 1. If a control responds and demonstrates the intended shape of the feature without doing the underlying work, it is Level 2. If nothing responds because there is nothing there yet, it is Level 3 and the page says so in prose rather than offering a button.

Level 1

Fully functional

It runs, here, now

A control you move changes a number that was computed from your input by the preview engine on this device. There is no server, no account and no stored state, but the computation is genuine and the result is reproducible: the same inputs always give the same outputs, because the engine is deterministic and seeded.

The honesty limit on Level 1 is not whether it works but what it is working on. Every Level 1 output is an illustrative model result, marked as such at the point of display.

In this build

  • Parameter rails — all 159 controls, with live recomputation
  • Dropdowns, toggles and radio groups across every laboratory page
  • Configuration presets and reset-to-default
  • Live illustrative calculations from the deterministic engine
  • Dynamic metric cards that retone as thresholds are crossed
  • Dynamic charts redrawn from current state
  • Branch selection across the four management populations
  • Trade-flow mode selection and cycle inspection
  • Regime selection across the eight classified states
  • Risk controls, gates and tier ladders
  • Monte Carlo demonstration at preview path counts
  • Research archive filtering and search
  • Accordions, tabs and the contents rail
  • Responsive navigation to 360px
  • Form validation with inline field errors
  • The motion toggle, respected site-wide

Level 2

Interactive preview

The shape is real, the work is not

A Level 2 module has a working interface driven by demonstration data. You can operate it, and what you see is an accurate representation of how the finished module is intended to behave — the steps, the states, the warnings, the vocabulary. What it does not do is the underlying work: no file is read, no configuration is persisted, no document is produced.

Level 2 is the most easily misread status on the site, which is why every such module carries the marker inside the module rather than in a footnote.

In this build

  • CSV column mapping — ten steps, nine validation states, demonstration file
  • Saving a strategy or a laboratory configuration
  • Report creation and document assembly
  • Parameter optimisation over a defined search space
  • Loading a complete preset from the Wizard framework library
  • Applying a MARS throttle result to a live configuration
  • Historical comparison between two saved studies
  • Collaborative workspaces and shared laboratories
  • Broker export field mapping beyond the demonstration schema

Level 3

Described only

Written down, not written

A Level 3 module is a specification. The problem it solves has been described, the interface has been sketched in prose, and the reasons it is hard have been stated. There is no interface to operate, and the site deliberately does not offer a button that would imply otherwise.

Most Level 3 items share one root cause: they need infrastructure that does not exist in a static site — a server, a database, an identity system, or a data feed.

In this build

  • Live brokerage integration of any kind
  • Production-scale backtesting against market data
  • Production Monte Carlo jobs at institutional path counts
  • Complete user accounts, roles and permissions
  • Cloud persistence of studies, mappings and results
  • Billing, subscriptions and entitlement
  • Full CSV processing of a real trade history
  • Live account monitoring and telemetry
  • Automated trading or order routing
  • Production risk authority acting on real capital

The line that will not move

Automated trading and production risk authority appear in the Level 3 list because they are described in the architecture, not because they are queued for construction. The section on what will not be built explains why both sit outside the scope of this phase entirely.

03Level DistributionAR-APP-001·DST

Where the twenty-five
modules actually sit.

Both figures below are computed directly from the module register that generates the blueprint, so they cannot drift from it. Read them as a progress statement: a minority of the intended application exists, a substantial middle band has been designed and demonstrated, and roughly a third is still prose.

Figure 1 · Module levels within each stage Project register

Composition of each stage by functionality level.

Figure 2 · Total modules by level Project register

The whole application counted once.

How to read the shape

The working modules cluster where the preview engine can carry the whole job on its own: Monte Carlo, friction, execution diagnostics, regime analysis, gates and tiers. Every one of those takes a configuration and returns an analysis, and none of them needs to remember anything between visits. That is why they exist.

And where it is thin

The absent modules cluster around two capabilities: persistence and market data. Build and Refine are the two stages that assume you can keep something, and they are also the two stages with no Level 1 modules at all. That is not a coincidence; it is the same missing infrastructure counted twice.

04Stage 01 · BuildAR-APP-S01

Construct the framework
before arguing about it.

The Build stage turns an intention into a specification: identity, signal conditions, the branches that will manage the resulting positions, entry and exit geometry, sizing policy and flow rules. It is the stage with the least working software and the clearest design, because the hard part is not the interface — it is having somewhere to put the result.

The five modules in the Build stage, their functionality level, what each does and where the idea is demonstrated today
ModuleLevelWhat it doesDemonstrated in

Today you can specify a framework in the sense that matters analytically — you can set every one of the 159 parameters in the parameter laboratory, choose an archetype, choose branches and watch the consequences propagate. What you cannot do is name that specification, save it, return to it next week, or hand it to somebody else.

The framework library goes some way toward the missing piece by publishing twelve fully described frameworks as records, each with an edge thesis, preferred regimes, stop and exit concepts and the execution problem the shape creates. Those are read-only documents rather than editable objects, but they show the schema a Strategy Foundry would need to write into.

What is genuinely missing

A persistence layer. There is no identity, no storage and no way to serialise a framework, which means the Strategy Foundry and the Entry and Exit Builder cannot exist in any meaningful form on a static site. The Branch Laboratory, Risk Laboratory and Trade-Flow Builder are closer — their analytics already run — but each of them still ends with a result you cannot keep.

Framework library Branch architecture Trade flow Parameter laboratory

05Stage 02 · TestAR-APP-S02

Put the specification
under pressure.

Test is the stage where a framework stops being a description and starts being a distribution. Two of its five modules are fully working today, because resequencing and friction modelling need no market data — only a specified framework and an argument about how outcomes are generated.

The five modules in the Test stage, their functionality level, what each does and where the idea is demonstrated today
ModuleLevelWhat it doesDemonstrated in

The Monte Carlo Core is the most complete module in the application. It runs real resampling over a configured outcome ladder, produces a path field, a completion probability, a lock probability, drawdown percentiles and gate dwell figures, and it does all of that from your current parameter state rather than from a stored result. The only thing separating it from the production module is scale: preview path counts are chosen so a browser stays responsive, and the tail percentiles of a few hundred paths are not the tail percentiles of fifty thousand.

Friction Modelling is similarly real. Spread, slippage, commission and swap are charged against the working stop rather than against the trade, which is the reason the same cost assumption is trivial on a four-hour framework and fatal on a five-minute one. The execution record works through that arithmetic in full.

What is genuinely missing

A Simulation Engine that reads bar data. Everything currently called a simulation is a model of relationships between parameters, not a replay of history — no prices, no fills, no queue, no gaps. Until OHLCV data can be loaded and a framework's rules evaluated against it, nothing on this site is entitled to the word backtest, and the site does not use it.

Monte Carlo core Friction and execution Data laboratory Portfolio exposure

06Stage 03 · DiagnoseAR-APP-S03

Locate the failure,
do not merely observe it.

Most trading software reports that a system lost money. Diagnose is the stage that answers the follow-up question: which population, in which market state, at which point between the decision and the fill. Two of its modules already run at full fidelity because they operate on the structure of a result rather than on its provenance.

The five modules in the Diagnose stage, their functionality level, what each does and where the idea is demonstrated today
ModuleLevelWhat it doesDemonstrated in

Execution Intelligence is fully operational against modelled trades. It decomposes expectancy into the gross edge, the friction charge and the excursion cost, computes capture efficiency and giveback, and places outcomes into the six execution quadrants. On a real trade history it would do the same arithmetic on your excursions instead of on the engine's — the analysis is finished, the input is not.

Regime Analysis holds the framework constant and changes the market. Eight classified states, each with its own volatility band, persistence and transition behaviour, and a permission matrix that says which frameworks are allowed to operate in which state. The classification itself is authored rather than fitted, and the record says so.

What is genuinely missing

A Results Center — the place where a diagnosis is stored, versioned and compared against the one you ran a month ago. Diagnostics that cannot be retained are diagnostics you have to redo, and the value of execution analysis is almost entirely in the trend across successive samples rather than in any single reading.

Execution intelligence Regime analysis Tail diagnostics Structural metrics

07Stage 04 · GovernAR-APP-S04

Capital authority
above signal quality.

Govern is the stage that decides how much of a framework you are permitted to run, independently of how good the framework looks. Its structure is drawn from the MARS system: a gate derived from decline against the equity peak, a tier ladder capped by that gate, and a throttle that converts capital state and evidence into an authorised risk pool.

The five modules in the Govern stage, their functionality level, what each does and where the idea is demonstrated today
ModuleLevelWhat it doesDemonstrated in

The gate model and the tier ladder both run today against modelled equity, and the Monte Carlo module reports how long a path spends in each gate — which is the honest way to describe what a governance layer costs and what it buys. In favourable conditions it costs compounding; in unfavourable ones it buys the difference between a recoverable decline and a terminated account.

An important boundary applies to this whole stage. The structure is published; the calibration is not. Gate boundaries, pool percentages and the tier tables belong to the MARS workbook product, and every figure on this site that applies governance uses an illustrative ladder rather than the workbook's own numbers. That is stated wherever governance appears.

What is genuinely missing

Any connection between the model and an actual account. The Throttle can compute an authorised pool but cannot apply it, Exposure Capacity can model concurrent open risk but cannot read your open positions, and Compliance — a rule engine that records why an action was blocked — requires persistence and an audit store that do not exist.

MARS intelligence Gates and drawdown Exposure capacity Gate dwell

08Stage 05 · RefineAR-APP-S05

Iterate without losing
the audit trail.

Refine is the stage that separates research from tinkering. Every change to a framework produces a new version, every version keeps the reasoning that produced it, and comparison happens between recorded studies rather than between a current result and a memory of an earlier one. It is the emptiest stage in the application, with four of its five modules at Level 3.

The five modules in the Refine stage, their functionality level, what each does and where the idea is demonstrated today
ModuleLevelWhat it doesDemonstrated in

The research archive is the closest thing to this stage that exists. It holds records with a status, a method, an abstract and a verdict, including failed ones, and it is searchable and filterable. What it does not do is generate those records from your own work — they are authored research documents, not artefacts of a saved study.

Parameter Optimisation deserves a specific warning rather than an enthusiastic description. An optimiser that reports the best setting found is an instrument for producing overfitted configurations. The intended module reports the neighbourhood instead: how performance behaves at settings adjacent to the chosen one, and whether the peak is a plateau or a cliff edge.

What is genuinely missing

Everything that requires a saved object. Comparison needs two stored studies, cloning needs a parent to clone, reports need a document pipeline, and optimisation needs somewhere to put a search that takes longer than a page view. All four wait on the same persistence layer that blocks the Build stage.

Research archive Record index Wizard library Parameter laboratory

09Build DependenciesAR-APP-001·DEP

What must exist first,
and why the order is fixed.

Roadmaps usually present stages as items that could be tackled in any order if the resources appeared. This one cannot. Each stage consumes something the previous stage produces, and building out of order produces modules that look finished and answer nothing. The ladder below states the precondition for each stage in the form of the thing that has to exist before the work is even coherent.

Data before simulation

A simulation engine with no validated dataset behind it is a random number generator with opinions. Column mapping, type validation, fee decomposition and R derivation are unglamorous work, and every result downstream inherits whatever was wrong with them.

Simulation before diagnosis

Diagnosis operates on a population of outcomes with excursions, branch tags and regime attribution attached. Run it on a single history and it will explain that history in convincing detail, which is the failure mode it exists to prevent.

Diagnosis before governance

A throttle compresses risk when the account is in decline. If you cannot yet say which population caused the decline, the compression falls equally on the branch that was working and the branch that was not — the governance layer becomes a blunt instrument applied to a problem it never identified.

The cross-cutting dependency

Persistence sits underneath all four transitions. Accounts, storage and versioning are not a stage; they are the floor every stage after Build stands on. That is the single largest piece of missing work in the project, it is infrastructural rather than analytical, and it is the reason the level distribution looks the way it does. Nothing in the Refine stage can begin until it exists, and the Build stage is limited to read-only documents without it.

10Deliberate ExclusionsAR-APP-001·EXC

What will not be built,
and that is a decision.

These are not items that fell off the end of the roadmap. Each one has been considered and excluded, and each exclusion follows from what the Foundry is for. A research environment that also told you what to buy would stop being a research environment on the day it started.

No trade signals, ever

No alerts, no watchlists, no “setups of the day”, no entry notifications, in any tier. The moment a tool issues a signal, the user stops evaluating frameworks and starts following instructions, and every diagnostic on the site becomes decoration around an obedience relationship. This is a permanent exclusion rather than a phasing decision.

No managed accounts

The Foundry will not manage money, pool capital, accept deposits, or act as an introducing agent for anyone who does. It is not a regulated financial firm, it does not intend to become one, and building a product that implied otherwise would be a straightforward misuse of the analytical vocabulary on this site.

No automated execution in this phase

There will be no order routing, no broker credentials, no API keys and no position management against a live account for the foreseeable scope of this project. Read-only account import is a plausible future capability and appears in the register at Level 3; sending an order is not on the roadmap at all.

No performance guarantees

No claimed win rate, no expected return, no “systems validated by our engine returned X”. The engine reads no market data, so it has nothing to make such a claim from; and even a production backtesting module would only ever be able to describe a past sample. Anything that resembles a guarantee on this site is a bug, and reporting it is welcome.

One near-miss worth naming

A “suggested configuration” button — press it and the optimiser fills your rails with the best settings it found — is the single most requested feature of tools like this and the most reliable way to manufacture an overfitted system. If anything of that kind is ever built, it will return a neighbourhood and a stability score rather than a set of numbers to copy.

11Honest Distance AssessmentAR-APP-001·DST2

How far away is this?
Measured in work, not months.

There are no dates on this page and there will not be any. A date given by a project that has not started the infrastructure work would be an invented number, and inventing numbers is the specific behaviour this site is built to argue against. What can be stated honestly is the ordering of the remaining work and the relative size of each piece.

Remaining work ordered by dependency, with relative size and what unblocks when it is complete
OrderWorkRelative sizeWhat it unblocksState
1Accounts, storage, versioningLargest single piece. Infrastructural, not analytical.Saved studies, comparison, cloning, the entire Refine stageNot started
2Real CSV ingestion and validationModerate. The workflow is designed in full; the parser is not written.Diagnosis against your own trades rather than modelled onesDesigned
3Framework serialisation and the Build stageModerate. Depends entirely on item 1.Strategy Foundry, Entry and Exit Builder, saved branch setsSpecified
4Market data and a real simulation engineVery large. Data licensing, storage, and a rules evaluator.Anything entitled to be called a backtestNot started
5Server-side Monte Carlo at production scaleSmall once item 1 exists. The mathematics already runs.Tail percentiles that mean something at the extremesPreview running
6Report generation and exportsSmall. Templating over results that would already exist.Branded reports, shareable studiesNot started

What you can rely on

The Level 1 modulesThey work now, they will keep working, and they are free to use without an account. Nothing on the roadmap is a precondition for them.
The educational materialThe learning centre, the research archive and the framework library do not depend on the application being built at all.
The labellingIf a module moves between levels, the register on this page moves with it. The figures above are generated from that register, not typed by hand.

What you should not rely on

Any of it shippingThis is a specification maintained alongside a working preview. It is not a funded engineering programme with a delivery commitment.
The order holdingDependencies fix the order in principle. In practice a piece of work can prove larger than expected and displace everything behind it.
Scope staying constantModules can be cut. A module described here and later removed is more honest than a module shipped in a form that does not do the job.

12Limitations of this DocumentAR-APP-001·LIM

What a roadmap
cannot tell you.

This page is the most speculative document on the site, and it should be read with the same scepticism the rest of the Foundry applies to a flattering equity curve.

A specification is not an estimate

Every module here has been described carefully enough to be built. None of them has been costed, scheduled, staffed or prototyped beyond what is visible on this site. Detailed descriptions are frequently mistaken for advanced progress, and they are not the same thing.

Level 2 flatters the project

A polished preview of a feature looks close to done. In several cases the interface is the easy tenth of the work and the remaining nine tenths — parsing, validation, storage, correctness under bad input — has not begun. The CSV workflow is the clearest example.

Module counts are a weak measure

Twenty-five modules divided into three levels produces a tidy figure that implies each module is comparable in size. They are not. The Simulation Engine alone is larger than the entire Govern stage, and counting it as one module of twenty-five understates the distance considerably.

The engine's limits carry forward

Every Level 1 module inherits the boundaries of the preview engine: no market data, no fills, no order book, symmetric slippage, and a shock-loss term with very little real sample behind it. A production version of the same module would not automatically fix any of that.

MARS calibration stays out

Even a fully built Govern stage would model the structure of the governance layer rather than publish the workbook's gate boundaries, pool percentages or tier tables. Those belong to a separate product and are not part of what the application would expose.

None of this makes a strategy profitable

A complete application would improve the quality of the questions you can ask about a framework. It would not identify an edge, guarantee that one persists, or protect an account from a market that stops behaving the way the last sample behaved.

If you want to influence the order,
say so now.

The build order above is a dependency argument, not a fixed contract. Within the constraints — data before simulation, simulation before diagnosis, diagnosis before governance — there is real room to decide which module inside a stage gets attention first. Registering interest is how that input arrives, and it takes about a minute.

Register interest Planned application tiers Frequently asked questions

Demonstration form · nothing is transmitted or stored · no launch date is promised