Skip to content

Cookies are off until you say otherwise

Non-essential cookies stay off unless you accept them, and rejecting them leaves the site fully usable. What runs either way is only what the site cannot work without: the anti-abuse check on our forms, the record of the choice you make here, and the access cookie on internal routes. Site analytics is cookieless and loads only after you accept. Cookie policy

Quant24
Start in Sandbox — free

Product

Ten steps from a sentence to an approved package: the Goal Spec, six validation engines, the Auditor, the capital ladder and the Evidence Ledger.

  1. 1

    You

    It starts with a sentenceBring a goal, an idea you want tested, a strategy you already trade, or a single narrow objective. The Strategist asks at most one round of questions and writes down, in plain language, every assumption it made to fill in the rest.
  2. 2

    The Strategist · goal interpreter

    Your goal becomes a measurable contractThe sentence becomes a Goal Spec: an objective with a metric, a benchmark, a tolerated risk and a universe. A goal that cannot be measured cannot be tested, so it comes back with a proposed reformulation instead of a confident guess. Every interpretation is recorded as such.
  3. 3

    The Strategist · researcher

    It researches before it designsThree kinds of piece: procedures it can execute, data scored for solidity and deduplicated by event rather than by article, and instrument parameters — tick size, margins, session times, historical slippage by hour. Quantitative data is the signal; text only modifies it, never the other way round.
  4. 4

    The Strategist · design team

    A team of agents designs the candidatesA hypothesis designer proposes a handful of strategies, each with entry rules, exit rules and an economic mechanism declared before anything runs. A regime model classifies the market into states and joins the package only if it beats a trivial baseline.
  5. 5

    The validation engine

    Six tests, in parallel, over a sealed holdoutThe history is split once, and the most recent slice is sealed so the design process never sees it. Running the strategy over that slice is the forward test — today, not in three months. The engine does not opine; it produces numbers.
  6. 6

    The Auditor

    A gate that can veto everythingIt reviews the process, not the score: look-ahead, survivorship, how many hypotheses were tried, whether costs were modeled in every engine, whether the holdout stayed sealed, plus an adversarial pass by a second language agent. A weak result ships with its diagnosis; a dishonest process goes back to design.
  7. 7

    The Strategist · compiler

    A package, with capital proportional to the evidenceAn executable, versioned package: execution rules, a risk envelope, strategic context, falsification conditions declared up front and an expiry date. The starting capital level comes out of the posterior. Code compiles the package; the language agent never edits it.
  8. 8

    You

    You approve with all the evidence on the tableThe Evidence Ledger arrives with the package: every decision with its reasoning and the alternatives rejected, every source with a score and a timestamp, the known unknowns, and enough detail to reproduce the run. Synthetic and real are labeled separately and never mixed.
  9. 9

    The Executor

    Three layers execute with machine disciplineExecution in code with its own circuit breakers, a risk guardian with a mathematical veto over size and exposure, and a strategic layer that reviews context on a fixed cadence. The package travels as a versioned event, and no layer can skip the risk layer.
  10. 10

    The continuous cycle

    Real evidence takes overEach executed session feeds a second posterior that gradually replaces the synthetic one. Capital moves up or down the ladder on measured performance, never on a streak. If the strategic agent stops adding measurable value, a kill switch drops the system to execution plus risk.
  1. F0current
  2. F1next
  3. F2next
  4. F3next
  5. F4next
  6. F5next
  7. F6next
  8. F7next
F0

goal_spec.yaml
goal_spec:
  objective:
    benchmark:
    target_metric:
    target_value:
    secondary_metrics:
  horizon:
  capital:
  risk_tolerance:
  universe:
  constraints:
  user_mode:
  ambiguities_resolved:

Probability of meeting the goal, with credible interval

not available in this build

These steps show the mechanism, not a run. Where the probability of meeting the goal and its credible interval would appear, nothing is shown: the validation engine that computes them does not exist in this build and arrives in a later phase. No number in this section came out of an engine, because there is no engine.

CFTC Rule 4.41(b)(1)(i) — Hypothetical performance disclosure

These results are based on simulated or hypothetical performance results that have certain inherent limitations. Unlike the results shown in an actual performance record, these results do not represent actual trading. Also, because these trades have not actually been executed, these results may have under-or over-compensated for the impact, if any, of certain market factors, such as lack of liquidity. Simulated or hypothetical trading programs in general are also subject to the fact that they are designed with the benefit of hindsight. No representation is being made that any account will or is likely to achieve profits or losses similar to these being shown.

From a sentence to an approved package

The ten steps above are the whole journey. What follows is the detail behind the three parts that decide whether any of it is worth trusting: the tests, the ladder and the ledger.

The six engines, one sentence each

The history is partitioned exactly once, and every engine shares that partition:

  • training share, percent: 60% for training, with nested walk-forward folds inside it.

  • test share, percent: 20% for the out-of-sample test.

  • holdout share, percent: 20% held out — the most recent stretch of the record, sealed, and never touched during research or design.

  • E1 — Walk-forward out of sample. The strategy is backtested over the test segment with nested folds, reporting Sharpe, Sortino, maximum drawdown, Calmar, profit factor and the same metrics broken down by regime.

  • E2 — Sealed holdout. The strategy runs bar by bar over the holdout with the same cost model, the same historical slippage and the same circuit breakers the execution layer will use; this is the forward test, and comparing it against E1 is how degradation is detected.

  • E3 — Monte Carlo over trades. 1000 reorderings of the holdout trades, each trade's return preserved, producing a distribution of Sharpe, drawdown and annual return instead of a single lucky sequence.

  • E4 — Monte Carlo over regimes. The same resampling, but conditioned on the transition matrix of the regime model: what happens if the current state persists, reverts, or flips earlier than expected.

  • E5 — Stress test. The worst events actually in the record — the deepest drawdown of the instrument, the widest overnight gap, the sharpest correlation shock across the universe — run against the circuit breakers and the sizing rules.

  • E6 — Bayesian posterior. A prior from E1, deflated by the number of hypotheses tried, a likelihood from E2, an uncertainty adjustment from E3 and E4, and a tail from E5. It outputs the probability of meeting your goal with a 90% credible interval and a degradation flag.

Two things follow from that list, and both are deliberate. First, E3 and E4 are resamplings of the same holdout: they describe uncertainty, they do not add independent evidence, and the Auditor checks that nobody treats them as if they did. Second, the number of hypotheses tried travels with the package and deflates the Sharpe. Trying twenty ideas and reporting the best one is how a backtest lies; counting them is how it stops.

The ladder decides the capital, and the evidence decides the ladder

Five rungs, and the posterior picks the entry point:

  • Below 55%, the strategy runs in paper and accumulates real evidence without capital at stake.
  • Between 55% and 70%, it starts at a micro allocation.
  • Above 70%, and only if the stress test was survivable, it scales.
  • The top rung asks for a stable posterior accumulated from executed orders, and is never granted on synthetic evidence — that one is enforced in the type system, not in a policy document.

Both thresholds are calibrable parameters. They are published because a threshold you cannot see is a threshold you cannot argue with.

Underneath every rung, the same drawdown cascade applies:

  • A drawdown of 2% in a day and no new positions open.
  • A drawdown of 4% in a week and size is halved.
  • A drawdown of 8% in a month and everything pauses for a manual review.

None of the ladder runs in this build. The validation engine that would place a strategy on a rung is built in a later phase, so today the ladder is a specification and an interface, not a working mechanism — and every rung that touches real capital is blocked besides, with the reason written on it: requires broker connection. The stack page says what exists and what does not, line by line.

The Evidence Ledger

The package is the output; the ledger is the reason you can check it. Every decision carries its reasoning and the alternatives that were rejected. Every source carries a score and a timestamp. Every metric carries the label of where it came from — synthetic or real — with no ambiguous third state. The known unknowns are written down rather than omitted, and the run is reproducible from the seed, the versions of each procedure and the hash of the data.

That is what makes disagreement possible. You can look at a package, decide the mechanism is thin, and reject it — with a specific reason, taken from the ledger, instead of a feeling.

How long it takes, and what the demo will show

Minutes, not weeks — the design target, not a measurement. The session is designed to run backtest and synthetic forward test in parallel, which is where the compression comes from. The site does not publish a stopwatch number, because the honest figure is the one measured on your run: when the engine exists, each run will show the duration it actually took, phase by phase.

The interactive demo on this page will replay a full session end to end — prompt, Goal Spec, the six engines, the posterior with its interval, the resulting rung — on synthetic data, labeled as such at every step. It is not built yet, and we are not going to give it a date.

What this build is, and is not

Pre-launch. No broker connection, no capital and no exchange market data. Nothing described on this page runs yet: the validation engine E1–E6 and the Executor are built in a later phase, so there is no session to replay and no result to label. When the Executor does run, it will run as a simulation over a replay of the sealed holdout, labeled as a simulation. The numbers on this site today are product parameters we declare and market figures we cite, each one carrying its source.