Welcome. This is the front door of your Paras knowledge portal. Paras (also called sponaitech-trading) is the complete automated futures-trading system you are building solo with AI automation. It is not one program — it is three Windows desktop apps sitting on top of one shared C# 'kernel', plus a written Constitution that every line of code must obey. This page is the big-picture orientation: what Paras is, why it exists, how the pieces fit, and how to use this portal. Later lessons go deep on each part.

Read this first sentence twice, because it reframes everything: a normal trading platform is built to FIND winners; Paras is built to KILL losers. The whole architecture — pre-registered trial budgets, statistical deflation gates, three independent engines that must agree, a compliance engine that makes your worst habit physically impossible — exists to make 'this strategy is fake' the cheap, default, honest answer. An impressive backtest is treated as a suspect until proven otherwise, never as a discovery.

Notice the deliberate shape: PULSE watches, SENTINEL discovers, AXIOM executes — and they are kept apart on purpose. Only AXIOM is ever allowed to emit an order; SENTINEL never touches a trading venue. The thing that makes the three apps trustworthy together is the single shared kernel underneath them.

Concrete example. You have a hunch: 'ES opening-range breakouts work better when the prior day closed strong.' In a normal platform you'd tweak parameters until the equity curve looked great and start trading. In Paras you write it as a spec with that exact mechanism and a fixed trial budget. SENTINEL runs it, counts the trial, and the deflation gate asks: 'given how many variations you tried, is this edge real or just luck?' If the three engines disagree, or the deflated metric is below threshold, it dies — and the death is logged so you never waste money re-testing the same dead idea. If it survives, AXIOM trades the identical kernel logic, and the compliance engine refuses to let a hot streak talk you into doubling size. The hunch was a base metal or it was gold; Paras tells you honestly which, cheaply.

Why does this exist for YOU specifically? Paras is a one-person operation that relies on AI automation. You run it on a single personal Windows machine — no VPS, no VPN (Topstep bans them), budget kept at or under $200/month, and zero marginal AI token cost at runtime (a Claude Max plan for build sessions, local Gemma/Ollama for runtime inference). The system has to be honest and self-disciplining precisely because there is no team to catch a mistake. The architecture IS the second pair of eyes.

How to use this portal. This is your single go-to library for everything about Paras, written for understanding — plain-English first, then precise. Each lesson cites its source docs so you can always check it against the specs of record (docs/00–09 and CLAUDE.md). Start here, then branch into the deeper lessons. Two terms to fix in your head now: a 'model' always means an edge-class trading model (a strategy) — never an AI model; and the 'data plant' (the always-on engine, canonically the 'Paras DataPlant') is the run-mode of SENTINEL that owns ingestion — PULSE only watches it, the SENTINEL dashboard is the on-demand research lab you open when you want to do research.

Locked decisions & the why

Jump to a module

Paras is named after the Parasmani — the touchstone of folklore that turns base metal to gold. The honest version doesn't promise gold; it touches every metal and reveals which were gold all along. Most aren't — that is the point. The Constitution is what keeps the touchstone honest. SENTINEL (research lab) and AXIOM (execution fortress) share one C# kernel, and these 11 principles govern both. Think of them as the system's risk-management rules, the same way Topstep's rules govern your funded account: break one and the result is invalid no matter how good the equity curve looks.

A useful way to hold all 11 in your head is four clusters, drawn from the Constitution quick-reference card: (1) Honesty & counting — Principles 1, 2; (2) The sacred order path — Principles 3, 4, 5; (3) Truth & immutability — Principles 7, 9, 11; (4) Restraint — Principles 6, 8, 10. We'll take them one at a time, but keep the clusters in mind — they explain why the principles defend each other.

Locked decisions & the why

You are building a system that will one day place real orders on a funded Topstep account with your own money on the line. The danger is never the obvious bug — it is the reasonable-looking shortcut: a quick LLM call to 'improve' a sizing decision, a Topstep dollar amount hard-coded 'just for now', a backtest engine that drifts a little away from the live engine. Each of those is individually defensible and collectively fatal. The Hard Rules exist so that none of them is ever a judgment call. They are pre-decided. This lesson walks each rule: what it bans, why it exists, how it is enforced, and what to watch for.

All of these come straight from the 'Hard rules (never violate)' section of CLAUDE.md, and each traces to a locked decision (D-xxx) in tracking/DECISIONS.md. Nothing here is invented — if a detail isn't in those docs, it isn't on this page.

Now the deep dive — each rule with its mechanism and the concrete failure it prevents.

Locked decisions & the why

Think of building a Paras module the way you'd think about taking a trade with a checklist you cannot skip. You don't enter the order, then decide your stop, then check the rules, then size it — you do those in a fixed order, every time, and if any step fails you don't trade. The Paras Method is that checklist for code. A module is not allowed to move to the next ring until the current ring's exit criteria are demonstrably met. ULTRACODE is the smaller loop you run inside every single task (even a one-line fix): orient yourself, write a plan, build it test-first, prove it with real numbers, and record what happened. 'Done' without proof and a recorded trail is not done.

There are two nested loops. The OUTER loop is the Paras Method — six rings a module passes once, in order, on its way from idea to verified. The INNER loop is ULTRACODE — five phases every individual task runs, possibly many times within a single ring. The rings tell you WHAT stage the module is at; ULTRACODE governs HOW each piece of work inside that stage is executed and proven. Both are always on. Neither is a flag you opt into.

Now the inner loop. ULTRACODE is the standing execution mode — always on, for the main session and every subagent. It exists because the Constitution's first three principles (honest discovery, every trial counted, parity by construction) die first at the PROCESS level: an untested edit, an unrecorded run, an unverified 'done.' Every task — from a one-line fix to a whole milestone — runs the same five-phase loop.

Here is how the two loops fit together in practice. Suppose you're building the SessionClock for the kernel. The MODULE walks the six rings once: ring 1 you write and review its public interface and data contract; ring 2 there's no new schema so it's light; ring 3 you write the half-page concurrency plan (the clock is injected, never reads wall time); ring 4 you build it test-first with FsCheck property tests covering DST-transition Sundays; ring 5 you wire it into the real engine via the interface; ring 6 the test gate goes green under test-sentinel and you hold the ceremony. But INSIDE ring 4, every commit — adding a method, fixing a property-test counterexample — runs the full ULTRACODE loop: orient, plan, build, prove (a TEST_LOG row), record. Many ULTRACODE loops live inside one ring.

Quality is not enforced by good intentions — it's enforced by five hard Laws and by routing every gate to a second pair of eyes. The five ULTRACODE Laws are: U1 Plan before touch; U2 One ring at a time; U3 Prove, don't claim; U4 Independent verification; U5 Record everything. The one that surprises most newcomers is U4: the author NEVER grades their own gate. The builder model (Opus 4.8) implements and writes first-round tests, but the verdict that the gate is green comes from a separate auditor agent in a separate context — test-sentinel for test quality, parity-auditor for engine agreement, phase-gatekeeper for exit criteria, design-reviewer for ring 1, constitution-guardian on disputes.

Proof has a single home: tracking/TEST_LOG.md. Every gate-relevant suite run appends a row — date (PT), milestone·module·ring, suites run, the exact command, the result, the MEASURED numbers (coverage %, property cases, scenario count), determinism/golden status, the auditor verdict, and the artifact path. This is the source of truth for engineering verification, the same way ops/ledger.duckdb is the source of truth for research trials. One concern, one home (Principle 7). The bars never move to fit the code: kernel components and engines must hit ≥90% line coverage; compliance-engine monitors must hit 100% branch coverage plus 10/10 adversarial scenarios; a property test with trivial generators is a FAIL.

Finally, the method doesn't rely on you remembering to do all this. Enforcement is layered into the harness: the root CLAUDE.md keeps the ULTRACODE rules always in context; a SessionStart hook injects STATE + the memory index + the ULTRACODE banner at every boot; a PreToolUse guardrail hook warns on Constitution-boundary violations (advisory, D-061); a PostToolUse hook auto-journals every Write/Edit/Bash to ops/journal/; a PreCompact hook protects against losing state if compaction fires before a handover; and the /ultracode command lets you audit any session against the Five Laws on demand. The discipline is wired in, not willed.

Locked decisions & the why

You're a solo operator leaning on AI to build and run a trading system. That is powerful and dangerous. Powerful because the machine can move fast; dangerous because fast + sloppy is exactly how you end up with impressive-looking results that are quietly wrong — the precise failure the Constitution exists to prevent. This lesson is the antidote: the disciplined cadence by which things change in Paras and the small set of files that let YOU, the operator, keep up with what changed and why without reading the whole repo. ULTRACODE (docs/06) names the reason plainly: the Constitution's principles 'die first at the process level — an untested edit, an unrecorded run, an unverified done.'

There are three things to understand, in order: (1) how a decision gets made and LOCKED so it's never relitigated; (2) how an actual change flows from idea to done — through the gates, with proof; and (3) how you, the operator, stay current using a handful of tracking files. We'll take them one at a time, then look at the real example happening in the repo right now.

PART 1 — HOW A DECISION GETS LOCKED. A 'decision' here is not a code change. It's a choice about how the system works that you never want to argue about a second time: 'all three apps are WPF,' 'the kernel is a pure library,' 'Topstep rule values live in config, never as constants.' These live in tracking/DECISIONS.md as numbered, dated entries (D-001, D-002, ... up to D-094 today). Each one states the decision, cites the doc section it comes from, and gives the rationale. The file's own header is blunt: 'Do NOT relitigate these inside build sessions.'

Real example of supersession done right: D-070 originally said 'Fable 5 grades every gate.' When Fable was retired (2026-06-15), the team did not quietly delete D-070 — they wrote D-080, dated, stating it 'supersedes D-070,' and re-routed grading to independent auditor subagents. The old entry stays, annotated. That's the discipline: history is never rewritten, only extended.

PART 2 — HOW A CHANGE FLOWS. Every task in this repo — from a one-line fix to a milestone — runs the same five-step loop (ULTRACODE, docs/06 §1.2). It is not optional and it has no fast path; the standing default is maximum effort on every substantive task. The loop is what turns 'I changed some code' into 'this change is real, proven, and recorded.'

Two more rules sit on top of the loop and are worth knowing because they're sacred. First, the failure doctrine: a red gate is a recorded FAIL — you NEVER weaken the threshold, delete the test, or quietly retry until it goes green. A determinism or parity mismatch is STOP-EVERYTHING, not a flaky test. Second, gates run in order: you do not start a phase before its predecessor's exit criteria are demonstrably met. These two together are why Paras 'kills bad strategies cheaply' instead of nursing them along.

PART 3 — HOW YOU KEEP UP. You should never have to read the whole repo to know where things stand. The system writes its own status into a fixed set of files, each with one job. The most important habit you can build: open these in the right order. STATE.md first (always), then drill into the others only when you want the story.

WORKED EXAMPLE — the rhythm in action, right now. The repo is mid-milestone (M1 'First Light'). Watch how a single discovery flowed through every part of this lesson during the soak test on 2026-06-18. (1) DISCOVERY: the 72h soak surfaced that the market calendar over-closed the market — Juneteenth was marked a full holiday and the evening-skip rule extended the closure to Sunday, even though the market actually reopened Thursday afternoon. (2) DECISION LOCKED: rather than a one-off patch, the operator locked D-094 — a HARD RULE that the market model must be asset-class-agnostic and per-instrument (so US equities, FX, crypto can be added later by config, not a rewrite) — with the soak finding written in as the motivating evidence, and a matching risk R-09. (3) RECORDED, NOT YET BUILT: the fix and an independent calendar-correctness audit were QUEUED post-soak, explicitly NOT built mid-soak (because D-082 forbids rebuilding the running plant). (4) KEEP-UP: all of this is legible to you by reading STATE.md's NEXT ACTION block and the D-094 entry — you can see what changed, why, and what's pending, without touching a line of code.

Notice what the example does NOT do. It does not silently edit the calendar and move on. It does not re-argue settled choices. It does not weaken the soak gate to make the run pass — the same session shows a soak FAIL recorded honestly (exit code 14, freshness stall) with 'RECORDED FAIL (failure doctrine — do NOT weaken the gate)' and a root-cause-then-re-soak plan. That is the rhythm working exactly as designed: discover, lock the durable choice, prove honestly, record so the operator can keep up.

Locked decisions & the why

Plain English first. There are really only four moving parts. One engine runs all the time in the background (the DataPlant). One tiny tray light watches that engine and tells you in one glance whether your data is OK (PULSE). One heavy research window you open only when you want to do research (the SENTINEL dashboard). And one trading window you open only during market hours (AXIOM, built later). The mental model that fixes everything: the always-on thing is the headless engine, NOT a window. PULSE watches the engine so you never have to open anything to know the data is healthy. (DAILY_OPERATING_MODEL §1)

Now the day. WHAT THE MACHINE DOES ON ITS OWN (automatic, §4): about every 120 seconds the REST self-heal tops up bars to current; around 18:00 PT the plant's nightly DATA job runs gap-sync → consolidate higher timeframes → quality check → D1 cross-audit (reconciliation), and PULSE shows 'nightly top-up complete'; continuously the tape recorder archives the sub-minute stream for later execution research; and nightly a verified backup of the vault runs (D-071). If the machine was OFF at 18:00, the next plant start catches up the missed quality/audit window. None of this needs you. Your only standing job during the day is the PULSE glance — and you only act on red.

WHAT NEEDS YOU (research-time, hands-on). Two recurring AI reviews surface work for you to read but stay inert until you or a code budget gate act. The NIGHTLY CLAUDE RESEARCH LOOP (~05:30 PT, headless, docs/04 §1.2) renders an honest verdict on every finished experiment against its gate, scans for anomalies, appends findings to ops/learnings.md (negative results are findings), writes ops/reviews/<date>.md, and proposes ≤5 follow-up specs into specs/proposed/ — but those proposals are INERT: the runner's code budget gate promotes proposed→queued, never Claude, and a budget INCREASE needs your sign-off recorded in the ledger. The WEEKLY GAP SESSION (docs/04 §1.3) compares shadow/sim fills to backtest expectations — fill deltas, slippage drift, suppression frequency, live-vs-backtest expectancy — and can RECOMMEND recalibrate cost model / suppress strategy / retire to the G5 pool, which you confirm. You read these reviews; the system never silently acts on them.

A NORMAL DAY, end to end. Sunday night CME reopens and you boot the box; the plant starts, buffers the live stream, reads its per-symbol checkpoint and pages TradeStation forward — PULSE goes pulsing blue ('gap-filling'), then settles green; you did nothing. Through the trading day PULSE stays green; at 14:00 PT it goes calm slate (CLOSED) for the CME maintenance break and back to green at 15:00 — that's normal, not a fault. Around 18:00 PT the nightly DATA job runs and PULSE flashes 'nightly top-up complete.' Overnight the vault backs up. At ~05:30 PT the Claude research loop verdicts last night's experiments and leaves you a review to read in the morning. When you want to BUILD or do research, you /paras-start, work one ring through the ULTRACODE loop, prove it with a TEST_LOG row and an independent auditor, and /paras-handover before context hits 60%. When you want to TRADE (post-M1), you open AXIOM — its own live tick feed, independent of the plant — and close it at the cash close. Your standing duty all day is one glance at PULSE, acting only on red.

Locked decisions & the why

Paras is named after the Parasmani — the legendary touchstone that turns base metal to gold. The honest version of that legend is the point of this whole system: it touches every metal and reveals which were actually gold all along. Most aren't. The system's real job is to kill bad strategies cheaply. To do that it is built as three separate Windows applications sharing one pure C# kernel. Think of it as a factory with three rooms: a heartbeat lamp by the door (PULSE), a research laboratory in the back (SENTINEL), and a hardened trading vault out front (AXIOM). Each room has exactly one responsibility, and nothing crosses between them except along carefully guarded paths.

Why three apps instead of one big program? Because their jobs have completely different rhythms, risk profiles, and failure modes. The data heartbeat must run 24/7 and stay tiny and trustworthy. The research lab runs overnight in heavy batches and must never feel like a trading dashboard. The execution app touches real money on live data and is designed, by law, to be read-heavy and tempt-proof. Welding those into one process would let a research bug or a UI freeze take down live trading — exactly the kind of coupling Paras forbids. Separation is a safety feature.

Here is how data and decisions actually flow between the three rooms. Market history enters through SENTINEL's data pipeline (TradeStation WebAPI v3) and lands in one DuckDB vault — the single source of truth for bars. The always-on ingestion engine that owns that vault is canonically called the DataPlant (the run-mode 'Sponaitech.Sentinel --run'), and it is the only process that writes to DuckDB. PULSE never opens DuckDB at all; it reads a lightweight status file the plant publishes (pulse-status.json + an event log) and renders the heartbeat. SENTINEL's research side runs experiments against that vault, pushes them through the gates, and the rare survivor that clears all six gates is promoted. Only promoted strategy-cells cross into AXIOM. AXIOM then runs its OWN live TradeStation stream (it does not borrow SENTINEL's data feed), generates signals with the shared kernel, and is the only app in the entire system allowed to emit an order to a venue.

A concrete walk-through makes the boundaries vivid. Suppose you have a hypothesis: 'opening-range breakout on ES, only when the prior session was a trend day.' You write it as a pre-registered spec YAML with a one-sentence mechanism and a trial budget — that satisfies G0. SENTINEL runs it overnight against the DuckDB history: first a fast screen against a random-entry null (G1), then a rigorous run with pessimistic fills (G2), then the deflation service checks whether the edge survives the number of trials your family has already burned (G3), then the kernel result is reconciled three ways against LEAN and TradeStation (G4 — any mismatch is STOP-EVERYTHING), then walk-forward and a one-shot frozen holdout (G5), and finally a promotion review (G6). If — and it usually won't — the cell survives all of that, it is assigned to AXIOM. The next market morning AXIOM's PRE_FLIGHT checks pass at 06:00 PT, the strategy arms, a signal fires, the compliance engine confirms the order is within Topstep limits, and AXIOM places the bracket. PULSE, the whole time, just sits by the clock glowing green because the data plant kept feeding the vault.

Notice how the three apps each express the system's personality differently in their UI. PULSE is a well-made instrument-panel lamp: four (now five) calm states, monospace numbers, zero gamification. SENTINEL's dashboard is a laboratory's glass wall — most of what it shows is dead hypotheses displayed with dignity, because the corpus of verified 'no' is the asset; there is no celebration, no green-by-default, no leaderboards. AXIOM is designed against the user, lovingly: read-heavy by law and tempt-proof by design, because the operator's documented failure mode is intervening after success. The only large affordance in AXIOM is the kill switch — because flattening reduces risk. None of the three has a button that increases risk.

Locked decisions & the why

Plain English first: the Data Plant is the headless, always-on program (run-mode `Sponaitech.Sentinel --run`, canonically named 'Paras DataPlant', D-091) that goes out to TradeStation, pulls down price bars, stores them in a single database file, repairs any gaps after an outage, records the live tape, runs a holiday-aware quality audit each night, and publishes its heartbeat so the PULSE tray app can show you a green/amber/red glance. It is not the research dashboard and it is not PULSE — it is the engine those two watch and read from.

WHY it exists: a one-person, AI-automated trading lab runs unattended overnight and over weekends. Data feeds go down, the machine reboots, CME closes for maintenance, holidays produce zero bars, half-days produce short sessions. A naive pipeline would either crash, silently skip data, or — worst of all — paper over a gap so the missing bars look fine. Constitution Principle 7 says there is one source of truth per concern: bars live in DuckDB, and nowhere else. The plant is the machinery that keeps that one source honest without you babysitting it.

bars(symbol, res, end_utc, o, h, l, c, v, ingest_utc, source)        -- PK(symbol,res,end_utc)
econ_calendar(event_utc, event, importance, instruments_json, source) -- scheduled times only (point-in-time honest)
data_quality(symbol, res, day, missing_bars, dup_bars, gap_max_min, ok)
instruments(symbol, tick_size, tick_value, point_value, session_json, max_contracts)

HOW honesty is enforced in the storage shape itself: the `econ_calendar` model has NO Actual/Released/Realized/Value/Forecast/Previous field — storing a released number would let a backtest 'know' an outcome it couldn't have known in advance (a point-in-time honesty violation). Gates may use only the SCHEDULED event time. A reflection test asserts this contract cannot silently regress. The same spirit runs through the whole plant: it would rather show you an amber 'behind' or a red fault than fabricate a clean-looking bar.

Locked decisions & the why

Here is the trap that kills most home-built trading systems. You write a strategy in your charting platform (EasyLanguage on TradeStation). The backtest looks great. So you re-write it — by hand — in whatever code actually sends the orders. Now you have TWO implementations of 'the same' strategy. They drift. A rounding difference here, a bar-timing difference there, a fill assumption that doesn't match. The version that backtested gold is not the version that trades, and you only find out after it bleeds money live. Paras refuses to let that gap exist. All trading logic lives in one place — the kernel — and both the research lab and the live trader call into that exact same code.

WHAT the kernel is: a pure C# library. 'Pure' here is a precise engineering term, not a vibe. The kernel is allowed to do trading math and nothing else. It has no venue SDKs, no HTTP clients, no UI, no LLM calls, no Topstep rule values baked in, and — critically — no wall-clock reads. The clock is injected. Why does that matter? Because purity is what makes both three-engine parity and live/backtest identity possible. A function that only depends on the data you hand it, and nothing hidden, produces the same answer every time, on every engine, in backtest or live. The moment the kernel could read the real clock or hit a network, it could behave differently in the lab than in production — and parity would be a lie.

HOW a strategy is built: by composition, not by writing a monolith. Every strategy is a stack of those four small, pure, individually-testable components. A context gate (or several) decides the regime; one trigger decides the moment; filters can veto; one execution policy lays out the bracket. Each component is a deterministic function of MarketState — the read-only snapshot of current/recent bars (an M5 window plus an M1 window), the DailyContext (prev close, ATR20, opening-range stats, gap), the open position, and the injected clock. No I/O, no randomness, no wall-clock reads inside a component. That discipline is exactly why each piece can be unit-tested in isolation and why the whole composition behaves identically across engines.

WHERE the strategy is declared: a versioned YAML spec, not buried in code. The spec names the mechanism (required — no mechanism, no run), the instrument, the primary timeframe, the session, and then lists the context gates, trigger, filters, and execution policy with their parameters. SpecLoader validates it against a JSON Schema and treats unknown keys as errors. The spec's hash is recorded with every experiment row, so every result is traceable back to the exact configuration that produced it.

id: orb-inplay
version: 0.1.0
mechanism: "On in-play days the opening range resolves directionally often enough to clear friction."   # required — no mechanism, no run
instrument: ES
timeframe: M5
session: ES_RTH_PT
context:  [{type: InPlayGate, orwMult: 1.0, gapAtrMin: 0.30, warmup: 10}]
trigger:  {type: OrBreakoutTrigger, orMinutes: 30}
filters:  [{type: OneTradePerDayFilter}]
execution:{type: FixedRiskBracket, rr: 2.0, contracts: 1}
trial_budget: {family: orb-inplay, max_cells: 8}     # pre-registered (Principle 2)

WHY there are two engines, not one: cost. You want to screen thousands of candidate strategy 'cells' per night cheaply, but you also want a small number of survivors measured with brutal realism. So the kernel ships two engines that share components but differ in fidelity.

The RigorousEngine is where realism is enforced. Each M5 bar expands into its M1 children to resolve which side of a bracket hit first (the LIBB-equivalent intrabar problem). If M1 is missing for a period, the engine applies a pessimistic rule — the stop fills before the target whenever both lie within the bar — and logs a data-quality row. Fill models are pluggable and recorded with the run: market orders fill at next bar open minus slippage against you; stop orders fill at trigger minus slippage (never better); limit orders fill only on trade-through by at least one tick (a touch is not a fill). Costs default to $2.20/side + 1 tick/side — pessimistic placeholders that get replaced by Phase-0 calibrated values the day real fill data is reconciled.

WHAT proves it: three-engine parity. Trusting that the kernel matches reality is not enough — Paras proves it. The same spec is run three ways: (1) the kernel itself, (2) generated EasyLanguage on TradeStation, and (3) generated QCAlgorithm on LEAN. All three emit the same canonical trade record (trade_id, spec_id@version, spec_hash, engine, cell, side, qty, entry/exit time and price, exit_reason, gross/net P&L, MAE, MFE, bars_held). A three-way differ (ParityDiffer) aligns the trade lists by entry time within ±1 bar and classifies every difference.

WHY expansion does not threaten any of this: instruments and sessions are config, not code. ES/CL/GC in PT sessions is the seed set, not a boundary. Adding NQ, currencies, or overnight CL sessions is an instrument-table row plus a SessionTemplate plus spec YAMLs — zero kernel changes. Strategies are expected to differ per (ticker, session); that is the experiment_cell coordinate, not an exception. M1 is the one canonical stored resolution, and a BarConsolidator derives M5/M15/M30/H1 from it, so all three engines consolidate from the same source bars. The closed-bar rule is non-negotiable: a component may only see completed higher-timeframe bars — reading a forming M30 bar's 'close' mid-bar is look-ahead and a parity killer.

WHAT TO BE AWARE OF as the operator. Parity is fragile by design — it catches drift precisely because the bar is set so high. The known parity killers are concrete: (1) session-clock bugs — SessionClock must derive boundaries from time-anchored templates, never from calendar-date detection (the DAYBREAK v0 lesson; overnight sessions cross midnight and date-based logic breaks silently); (2) indicator-definition drift — each component pins ONE indicator definition (e.g. Wilder vs simple ATR smoothing) and the EL/LEAN generators must implement that same definition, or the 0.1% per-bar tolerance fires; (3) look-ahead from reading forming higher-timeframe bars; (4) the sub-M5 floor — signal generation below M5 is off by default because fixed friction against a shrinking per-bar range pushes breakeven win-rate up sharply and inflates trial counts against the DSR hurdle. None of these are bugs to 'work around' — they are the failure modes parity exists to surface.

Locked decisions & the why

Let's clear up the single most important confusion first, because it trips up everyone: there are TWO completely different AIs in Paras, and this lesson is only about ONE of them. The docs describe them as 'Two AIs, two clocks, one asymmetry: research thinks, runtime can only say no.' This page is about the second one — the runtime sidecar.

WHY does this thing exist at all? Because the most expensive failure in your trading was never a bad strategy — it was greed, override, and tilt. The compliance engine (deterministic code) already enforces the hard rules. The sidecar is a second, softer layer: a fuzzy reviewer that can catch the cases rules miss, and a thing to argue with at the exact moment you'd otherwise do something stupid. Critically, it is built so it CAN'T help you do the stupid thing even if you beg it to.

HOW it works: the sidecar has four runtime jobs, and the design principle is 'each given the cheapest tool that does it.' Two of the four jobs don't even use an AI model — they're deterministic templates. The AI is only reached for the fuzzy second-opinion and for the override conversation. Here are the four tiers.

Let's make the veto concrete. Before any trade, AXIOM assembles a small context pack (≤ ~1.5k tokens) and hands it to the sidecar. Notice it contains NO price prediction — it's a snapshot of compliance stress, market conditions, and live-vs-backtest drift. The model's only allowed reply is the tiny schema.

// What AXIOM hands the sidecar (assembled by code, not the model):
{
  "intent":     {"strategy":"orb-inplay@0.1.0","side":"long","qty":1,
                 "entry":6852.25,"stop":6845.0,"target":6866.75},
  "compliance": {"dll_remaining":640,"mll_floor_distance":1210,
                 "consistency_headroom":1080,"trades_today":0},
  "market":     {"session_minute":47,"in_play_score":1.4,"regime":"trend_up",
                 "calendar":["none"],"spread_ticks":1},
  "strategy_live": {"last20_expectancy_ticks":1.7,
                    "backtest_expectancy_ticks":2.1,"gap_status":"within_tolerance"}
}

// The ONLY thing the model may say back:
{ "veto": false, "confidence": 0.0-1.0, "reason": "<= 30 words" }

// System prompt core:
// "You are a risk veto. You may only output the schema. You cannot approve,
//  encourage, or resize. Veto when the context pack shows compliance stress,
//  stale data, regime/calendar conflict, or live-vs-backtest divergence.
//  When uncertain, veto."

Three details in that example carry the whole philosophy. (1) The reply schema has no 'approve' field — there is literally no place for the model to say yes; 'veto: false' just means 'I have no objection,' and the deterministic system proceeds on its own authority. (2) The instruction ends 'When uncertain, veto' — the asymmetry is baked into the prompt. (3) Every verdict is journaled, and the weekly session audits the sidecar's veto quality by checking the counterfactual P&L of trades it vetoed — so the AI itself is held accountable with measured evidence.

There is a second, formal version of this output called the Structured Verdict Contract (D-067). It's schema-constrained JSON enforced at the DECODER level — Ollama structured outputs / GBNF, never just asking nicely in the prompt — with a five-tier verdict STRONG_GO | GO | NEUTRAL | CAUTION | NO_GO, plus regime, confidence, up to 3 evidence items drawn only from the provided context, and an expires_at. The load-bearing rule: even a GO-class verdict carries ZERO permissive power. A 'STRONG_GO' does not approve anything; it's read-only advisory context for a deterministic sizing policy and the UI. Any mapping from verdict to behavior is deterministic, versioned config, and must pass the full G0-G6 gates to ever go live.

The mental model to carry away: AXIOM is a fortress of deterministic code that does the trading. The AI sidecar stands at the gate holding a single red flag. It can wave the flag (veto), read the gauges aloud (narrate), argue with you when you try to climb the wall (resist), and write up what happened after hours (reflect). It does not have keys, it does not have a green flag, and it never touches the controls. That asymmetry — a reasoner that can only say no — is the entire safety value.

Locked decisions & the why

AXIOM is the execution fortress — the app that places live orders through your Topstep account. But the part that matters most is not the part that trades; it is the part that refuses. Between every signal your strategy generates and every order that reaches the venue sits one gate: the TopstepComplianceEngine. Its entire job is to protect you from yourself by saying NO before money is at risk. This lesson teaches what the Topstep rules actually are, why each one exists, and exactly how the engine enforces them.

First, the mental model. A Topstep account is not your money — it is a funded evaluation seat with hard guardrails. Break a guardrail and the account is gone (a 'breach'). Topstep enforces this on its side; if you wait for Topstep to enforce it, you have already lost the account. AXIOM's compliance engine enforces the same rules locally, in advance, and even stricter — so the venue's enforcement should never be the thing that catches you.

There are three rules that decide whether you keep a funded account: the Trailing Maximum Loss Limit (MLL), the Daily Loss Limit (DLL), and the Consistency rule. Learn these three cold — everything the engine does is in service of them.

Why these three exist is worth internalizing, because the engine is built around the WHY, not just the numbers. The MLL exists because prop firms cannot let a trader give back all their gains and then keep digging — the trailing floor caps the firm's total downside per seat. The DLL exists to stop the classic blowup spiral: a bad morning becomes revenge trading becomes a wiped account. The consistency rule exists so that one lucky lottery day cannot pass an evaluation — Topstep wants repeatable skill, not a single gambling spike. Each rule maps directly to a way humans destroy accounts; the engine's locks are the operator's own blowup autopsy turned into code.

Now: how the engine enforces them. The compliance engine is Layer 3 of AXIOM, and it wraps EVERY order intent. No order reaches an execution adapter (Layer 4 — TopstepX) without first passing through it. The contract is a single function call on each intent that returns one of three verdicts.

// Every order intent, BEFORE any venue/adapter call:
Check(intent) → Allow | Deny(reason) | DenyAndHalt(reason)

//  Allow         → the intent may proceed to the execution adapter
//  Deny(reason)  → this entry is blocked; the day continues
//  DenyAndHalt   → block, flatten everything, and HALT the day (terminal)

// And on the data side, every fill/quote tick updates the monitors
// that feed the next Check(). The engine is always watching.

Notice what is missing from those three verdicts: there is no 'Approve' that grants anything. The engine can only let an intent pass or stop it. It is a one-way valve. This is the architectural expression of the Constitution's principle that the system 'adapts by saying NO more often — never by quietly becoming a different system.'

A concrete walk-through on a $50K Combine. You start the day with the MLL floor sitting $2,000 below your balance and the DLL at $1,000. You take two losing trades for -$600 total. The 80% DLL soft gate is at $800, so new entries are still allowed but you are close. A third signal fires; its stop-out would be another -$450, taking the day to -$1,050. The engine projects that this crosses the $1,000 DLL — DENY. Suppose instead the day had gone well and you booked +$1,500 in profit. That single day is now exactly 50% of the $3,000 profit target: the consistency ceiling. Your personal profit lock (a Paras overlay, default 2R) would already have blocked new entries earlier, letting the open trade exit on its own signal — so you never blow past the consistency line by accident.

Two phrases in that example matter: 'Paras overlay' and 'versioned config.' The 80% DLL soft gate and the personal profit lock are NOT Topstep rules — they are Paras choices, stricter than Topstep, applied on top of whichever account profile is active. The config file is explicit about which numbers are Topstep's and which are ours, so you never confuse a house rule for a firm rule.

Because these numbers are safety-critical and Topstep moves them, the config carries its own discipline. It is re-verified against help.topstep.com WEEKLY (folded into the calendar-news check via the /verify-topstep-rules skill), each run appends a dated entry to the file's _verificationLog even when nothing changed, and a rule change is treated exactly like a RiskConfig change — it activates at the NEXT PRE-FLIGHT, never mid-session. The file also carries an operator note that you must still confirm account-specific items (promo payout caps, exact XFA scaling steps, minimum trading days) against your OWN dashboard before any eval or live order, because values can differ by promo.

Enforcement does not depend only on the per-intent Check(). The session itself is a state machine, and two paths exist that the engine can trigger no matter what a strategy wants: the HALT path and the FLATTEN path.

Surrounding the engine are the hard locks — four design rules taken straight from the operator's own blowup autopsy. They are non-negotiable because they remove the human failure modes entirely rather than relying on discipline in the moment.

One more structural fact: AXIOM is multi-account ('pod') from day one, even with a single account today. Each venue account gets its OWN compliance-engine instance — independent DLL, MLL, and consistency state, because the pod contract is per seat. A ledger-recorded allocation map assigns each promoted strategy-cell to exactly one account, and new seats are added one at a time, profit-funded, each receiving a strategy uncorrelated with the existing book (the G6 correlation check is the gate). One TopstepX API subscription covers all linked accounts.

Locked decisions & the why

This is the operator's field manual for running a Topstep account. The companion lesson 'Topstep Rules & the Compliance Engine' teaches the architecture; this one is the playbook — the path you actually walk, the rules you must never cross, what AXIOM does for you at each one, and the dos and don'ts that decide whether you stay funded. Everything here is grounded in config/topstep-rules.json, docs/03_AXIOM_SPEC.md, docs/05_BUILD_ROADMAP.md, and the two research dossiers. Where the docs say 'verify against your own dashboard,' so does this lesson — nothing here replaces that check.

Start with the mental model. A Topstep account is not your capital — it is a funded evaluation seat with hard guardrails. You pay a small monthly fee to rent the seat and prove repeatable skill; pass the evaluation (the Combine) and you get a funded account that splits real profit 90/10 in your favor. Break a guardrail and the seat is gone — that is a 'breach.' The entire job of AXIOM's compliance engine is to enforce those guardrails locally, in advance, and even stricter than Topstep, so the firm's own enforcement is never the thing that catches you.

Now the three rules that decide whether you keep the account. Learn these cold — everything AXIOM does is in service of them, and every account death in the dossier traces back to one of them being crossed by a human in the moment.

Here is how AXIOM enforces all of this deterministically. The compliance engine is Layer 3 of AXIOM and it wraps EVERY order intent — no order reaches the TopstepX adapter without passing through it first. The contract is a single function call returning one of three verdicts. Note what is absent: there is no 'Approve' that grants anything. The engine is a one-way valve.

// Every order intent, BEFORE any venue/adapter call:
Check(intent) -> Allow | Deny(reason) | DenyAndHalt(reason)

//  Allow         -> intent may proceed to the execution adapter
//  Deny(reason)  -> this entry is blocked; the day continues
//  DenyAndHalt   -> block, flatten everything, HALT the day (terminal)

// Three deterministic enforcement moves map to the three rules:
//  MLL       -> projected-breach DENY (worst-case stop-out checked first)
//  DLL       -> 80% soft gate blocks entries; 100% flatten + HALT
//  Consistency-> personal profit-lock blocks new entries
//
// No LLM, verdict, or reflection may ever reach these inputs (D-067).

A concrete walk-through on a $50K Combine, 1 micro. You take two small losers for -$600 on the day. The 80% DLL soft gate sits at $800, so entries are still allowed but you are close. A third signal fires; its stop-out would be another -$450, taking the day to -$1,050. The engine projects that this crosses the $1,000 DLL and returns Deny — the trade is never placed. Now flip it: the day goes well and you book +$1,500. That is exactly 50% of the $3,000 target — the consistency ceiling. But your personal profit lock (default 2R) would already have blocked new entries earlier and let the open trade exit on its own signal, so you never blow past the consistency line by accident. At 1 micro, though, a normal day is $300–$500 and you rarely come near any of these — which is the entire point of the smallest-size policy.

Two phrases there are load-bearing: 'Paras overlay' and 'projected.' The 80% DLL soft gate and the personal profit lock are NOT Topstep rules — they are Paras choices, stricter than Topstep, applied on top of whichever account profile is active (parasOverlays in the config). And the MLL check is forward-looking, not reactive: the engine never waits for you to breach and then respond — by then the account is already dead. It checks the worst case before the trade exists.

Enforcement does not rest on the per-intent check alone. The session is a state machine, and two engine-triggered paths exist no matter what a strategy wants: the HALT path and the FLATTEN path. PRE_FLIGHT at 06:00 PT verifies the config hash matches yesterday's approved hash, venue auth, live data, loaded limits, sidecar health, and the strategy roster — any failure means no ARMED today. A hard violation (DLL at 100%, or a watchdog trip: market-data silence >10s in session, or a venue API failure with a position open) drives the session to HALTED and FLATTEN_AND_HALT. FlatTime drives an orderly END_OF_DAY flatten on our earlier clock. The doctrine is absolute: never an unattended open position.

The hard locks are why none of this can be undone in the moment. They come straight from the operator's own blowup autopsy and remove human failure modes entirely rather than relying on discipline under pressure.

The bottom line for the operator: at 1 micro, with AXIOM's projected-breach MLL check, the 80% DLL soft gate, the personal profit lock, and four hard locks that remove the buy button and freeze your config in market hours, the only way left to lose the account is one Topstep no longer lets a human reach — discretionary oversizing after a win. The dossier calls that 'the median outcome, not bad luck' for the unprotected trader. This playbook, and the engine behind it, exists so it can never be your outcome.

Locked decisions & the why

You already trade ES, NQ, GC, CL, and SI by feel — you read the tape, you know the setups. Model Discovery is how Paras turns that universe of trading ideas into a disciplined, countable pipeline. The job of this methodology is NOT to find clever strategies. The job is the opposite of optimism: it organizes every candidate so the system can KILL the bad ones cheaply, and so the few genuine edges face a higher and higher bar. This is the touchstone (Parasmani): most metals aren't gold, and that is the point.

Discovery answers three operator questions, in order. (1) Where do trading-model ideas come from and where do they live? (2) How do we organize them so we don't fool ourselves? (3) How does one idea become something testable that enters the gates? The answers are: a dedicated research hub, a four-level hierarchy ending in the "cell," and the /new-strategy ritual that writes a spec with a stated mechanism and a pre-registered trial budget.

THE HIERARCHY — four levels, each narrower than the last. This is the spine of discovery. Read it top-down: the top two levels are how humans think and budget; the bottom two are what actually gets tested. The Edge Class layer is an organizing / diversification layer ABOVE the Family, which is the budget unit.

WHY CELLS, AND WHY THE COUNT MATTERS. Each cell you run is one roll of the dice against randomness. Run enough cells and SOMETHING will look profitable by pure luck — this is the p-hacking trap, the thing that destroys most retail "systems." Paras' defense is built into the hierarchy: the trial budget is pre-registered per family BEFORE any run, and the more cells a family burns, the HIGHER the statistical bar that survivors must clear (the Deflated Sharpe Ratio, DSR). You don't get to keep searching for free.

WHERE THE IDEAS COME FROM — the master catalog and the seed backlog. Paras keeps a LIVING master catalog of trading models classified specifically for FUTURES DAY TRADING. It holds 123 models (well beyond the operator's own 42-rule grammar), each tagged Intraday / Overnight / Swing, with a Day-Trade Shortlist tab (44 intraday/keep) and one sheet per Edge Class. It is regenerated from raw per-class JSON — never hand-edited — so its provenance stays auditable. New ideas are added by dropping a JSON file into the raw store and re-running the generator.

FROM AN IDEA TO A SPEC — the component grammar. To be testable, a model can't be a vibe ("buy the brick wall"); it must be expressed in the kernel's four-layer component grammar. Every strategy is a composition of small, pure, individually testable pieces — deterministic functions of a read-only MarketState snapshot, with no I/O, no randomness, no wall-clock reads. This is what /new-strategy scaffolds, and what the spec schema validates.

# A model expressed as a spec (docs/01 §3). /new-strategy scaffolds this shape.
id: orb-inplay
version: 0.1.0
mechanism: "On in-play days the opening range resolves directionally often enough to clear friction."  # REQUIRED — no mechanism, no run (G0/D-031)
instrument: ES
timeframe: M5
session: ES_RTH_PT
context:  [{type: InPlayGate, orwMult: 1.0, gapAtrMin: 0.30, warmup: 10}]
trigger:  {type: OrBreakoutTrigger, orMinutes: 30}
filters:  [{type: OneTradePerDayFilter}]
execution:{type: FixedRiskBracket, rr: 2.0, contracts: 1}
trial_budget: {family: orb-inplay, max_cells: 8}     # pre-registered (Principle 2)

# The {instrument, timeframe, session} + trigger/execution params ARE the cell coordinate.
# Changing instrument to GC, or orMinutes to 60, makes a DIFFERENT cell — a separate counted trial.
# SpecLoader validates against spec.schema.json; unknown keys are ERRORS; the spec hash is recorded with every run.

THE PIPELINE — how a discovered model enters and what happens next. /new-strategy is the only door in. It scaffolds a schema-valid spec into specs/proposed/, satisfying G0 (a stated mechanism + a pre-registered budget exist before any run). From there the model runs the gate ladder. Each gate is a cheaper-first filter; the goal at every step is to kill the candidate as early and as cheaply as possible.

A WORKED EXAMPLE — your own grammar, end to end. Take REV-BUY-30 from the AxiomMTF backlog ("Low Is In — 30m Buy Reversal," ~100% lows-in in your notes). As a discovery candidate it is just an IDEA with no special status. To make it real: (1) /new-strategy scaffolds a spec; you write the one-sentence mechanism (why a 30m buy reversal with bigger-TF correlation should mark a durable low). (2) Discretionary feel — "humongous," "brick wall," "deeply oversold" — must be turned into deterministic, testable components (an IND4 regime gate, an oscillator threshold) before it can trade; parity demands it. (3) You resolve any carry-forward flag that touches the rule (e.g. the regime-classifier BBR/RRB inversion). (4) You pre-register a family budget, say max_cells: 6 across ES/GC × M5/M15. (5) It runs G0→G6 like everything else, every cell counted, the DSR hurdle rising as the budget burns.

Locked decisions & the why

Think of it like hiring for a critical role. You do not fly every applicant in for a full-day on-site (expensive) before reading their resume (cheap). You screen the resume, then a phone call, then a take-home, then the on-site, then references — each stage more costly, each one cutting the pool down so the expensive stages run on a handful of people. The Paras gate pipeline is exactly that, applied to trading strategies. G0 is the cheapest filter (does a written hypothesis even exist?) and G6 is the most expensive and most consequential (is this thing actually live-ready and does it add anything to the portfolio?). Cheap filters in front of expensive ones — that is the architecture.

WHY this ordering matters so much: realism and statistics are expensive, and overfitting is the enemy. Running a full M1-intrabar backtest with pessimistic fills and calibrated costs (G2) is far more compute than a fast array screen (G1). Running deflation statistics (G3) and three-engine parity (G4) is more ceremonial still. If you ran the expensive stuff on every idea you would (a) waste enormous compute and (b) — worse — multiply your trial count, which raises the statistical bar you must clear and makes it more likely you fool yourself. So the ladder is not just an efficiency trick; putting cheap filters first is how the system stays honest. Every run is a counted trial (Principle 2), so you want as few expensive trials as possible.

G0 — IS THE HYPOTHESIS PRE-REGISTERED? This is the cheapest gate and it costs zero compute, because nothing runs. The question is purely: before you backtest anything, is there a written spec YAML that states a one-sentence MECHANISM (a real reason this should work — 'on in-play days the opening range resolves directionally often enough to clear friction') plus a pre-registered trial budget for the family? If there is no mechanism, there is no run. Full stop. This is the gate that bans pure pattern-mining: you are not allowed to just data-dredge a thousand parameter combos and keep whatever looks good, because every one of those would be an untracked trial with no theory behind it. G0 is enforced at spec-load time — the mechanism field is required, unknown keys are errors. Fail routing for G0 is the bluntest in the system: no run.

G1 — ANY PULSE AT ALL? Now something actually runs, but cheaply: the FastScreen engine (array-based, single pass) ranks the cell against a RANDOM-ENTRY NULL. Here is the clever part. The null takes your strategy's exact same trade count and identical exits, but throws the entries in at random times within the session, and does this 100 times to build a distribution. If your 'edge' cannot beat what a monkey throwing darts at the same session would have done, you have no edge — you just have a side and an exit that happened to work. So the pass bar is two-pronged: you must beat the null's median (p50) AND independently clear at least +2 ticks net per trade. That +2-tick floor exists because beating a coin-flip by a hair is meaningless once friction is real. Fail routing is gentle here: record the result and you are done — most ideas die at G1, and that is the system working, not failing.

G2 — DOES IT SURVIVE REALISM? This is the first expensive gate, and it is where pretty backtests go to die. The survivor is re-run on the RigorousEngine: M1 intrabar resolution (so the engine knows whether your stop or your target was hit first inside the bar, not just that both were touched), pessimistic fills (market orders fill at next bar open minus slippage against you; stops fill at trigger minus slippage, never better; limits fill only on a trade-through by >= 1 tick — a touch is not a fill), and calibrated costs. Many 'edges' are really just artifacts of optimistic fill assumptions; G2 strips those away. Note the fail-routing here is unusually generous and deliberate: when an idea dies at G2, you LOG THE MECHANISM in learnings.md, because execution-realism findings are gold — knowing exactly which kind of edge evaporates under honest fills is reusable knowledge that improves every future hypothesis.

G3 — DOES IT SURVIVE DEFLATION? This is the statistics gate, and it is the one that protects you from yourself. The problem it solves: if you test enough strategies, some will look great by pure luck. The more trials a family has burned, the more suspicious a 'good' result should be. G3 hands the trade returns to the Python validation service (the only Python in the system, an arms-length FastAPI sidecar using reference implementations of Lopez de Prado / Bailey statistics — you do not re-implement these by hand). Two tests must both pass: the Deflated Sharpe Ratio (DSR > 0.95) given the family's trial count, and the Probability of Backtest Overfitting (PBO < 0.20) via CSCV (combinatorially symmetric cross-validation). DSR penalizes you for how many shots you took; PBO estimates how likely your in-sample winner is to underperform out-of-sample. Fail routing has teeth: the family's hurdle RISES (future ideas in that family must clear a higher bar), and the idea retires unless a genuinely NEW hypothesis emerges — you do not get to re-roll the same idea to a luckier seed.

G4 — DO THREE ENGINES AGREE? This is the parity court, and it is the only gate whose failure is a STOP-EVERYTHING event for the entire project. The same spec is run three independent ways: the kernel itself, generated EasyLanguage on TradeStation, and generated QCAlgorithm on LEAN (the LEAN oracle). All three emit the canonical trade list, and the ParityDiffer aligns them by entry time within +-1 bar and classifies every difference (missing / extra / px_delta / exit_reason_delta). The tolerances from doc-01 §6 are 'the law': indicator values within 0.1% relative per bar, entries >= 95% matched within +-1 bar, net P&L within 5% after documented semantic deltas, trade count within 3%. WHY so ceremonial: parity is the proof that 'the code that trades is the code that backtests' (Principle 3). An unexplained delta means one of your engines is wrong — which means you cannot trust ANY prior result until you find out why. So G4 is invoked only for survivors (it is rare and expensive), and its fail-routing is the harshest in the system: a parity bug contaminates everything until root-caused. You never loosen a tolerance to make G4 pass.

G5 — SURVIVES WALK-FORWARD AND THE FROZEN HOLDOUT? By now the idea is realistic (G2), statistically deflated (G3), and provably consistent across engines (G4) — but every one of those used the same body of historical data. G5 asks whether it survives data it has genuinely never seen. Two things happen. First, TradeStation walk-forward optimization (WFO) runs as an INDEPENDENT confirmation — a different platform, a rolling re-fit, checking the edge is not a single-period fluke. Second, and this is the sacred part: the frozen HOLDOUT months are opened. These are months of data that have been sealed since the start and touched exactly once, at G5 (D-032). The discipline is absolute — if you peek at the holdout earlier, or open it twice, it is no longer a holdout, it is just more training data and your out-of-sample claim is a lie. Fail routing: retire the cell. A clean failure on never-seen data is the most honest 'no' the system can give.

G6 — IS IT LIVE-READY, AND DOES IT EARN ITS SEAT? This is the final, most consequential, and most expensive-to-be-wrong gate — and notice it is the ONLY gate that is not purely mechanical. It is a promotion review: the operator plus Claude's weekly report. The decisive test is NOT 'is this the best-performing survivor on the leaderboard?' It is the portfolio-correlation check: does this strategy add UNCORRELATED daily P&L to the survivors already running? A second strategy that makes money on exactly the same days as your first one adds risk without adding diversification — it is not a new edge, it is leverage on the old one. Paras promotes for uncorrelated daily P&L across survivors, never for rank. Survivors that pass get an AXIOM shadow assignment (they trade on paper, in real time, against live data, before any real capital). Fail routing is patient: stay in the G5 pool — proven, but not yet promoted, waiting until the portfolio actually needs what it offers.

Worked example — the life of one idea. Say you observe that ES opening-range breakouts seem to work on high-gap days. (1) G0: you write a spec YAML with the mechanism 'on in-play days the opening range resolves directionally often enough to clear friction' and a trial budget — it loads, so it may run. (2) G1: FastScreen says the cell makes +3.1 ticks/trade and beats the random-entry null's p50 across 100 reps — passes. (3) G2: RigorousEngine with pessimistic stop-before-target fills and real costs drops it to +0.4 ticks/trade — it dies. You LOG the mechanism in learnings.md: 'ORB edge on ES is largely an optimistic-fill artifact; stop-before-target sequencing eats it.' That logged negative is a first-class result. Now imagine instead it had survived G2 at +1.8 ticks: it would face G3's DSR/PBO (is +1.8 real given 40 trials in this family, or luck?), then G4's three-engine parity, then G5's holdout months, and only then G6's question of whether ES-ORB P&L is uncorrelated enough with what you already trade to deserve a seat.

WHAT TO BE AWARE OF as the operator. (1) Order is sacred — a gate cannot be skipped, and a phase/gate cannot start before its predecessor's exit criteria are demonstrably met. (2) Fail-routing is not uniform: G1 just records, G2 logs a gold finding, G3 raises the family hurdle, G4 stops the whole project, G5 retires the cell, G6 parks it in the pool — know which 'no' you are getting. (3) Two gates are special-danger: G4 is the only STOP-EVERYTHING, and G5's holdout is a one-shot you can never un-spend. (4) G3's DSR threshold rises with trial count, so the budget gate (code, not Claude) is what keeps families from spamming the dice. (5) G6 rewards uncorrelated P&L, never leaderboard rank — your best-looking survivor is not automatically promotable. (6) FastScreen's approximate numbers must never leak past G1 into a G2+ decision.

Locked decisions & the why

Milestone board (snapshot from tracking/PROGRESS.md)

This page is your map. Paras is not built all at once — it is built as a chain of numbered phases, each with a written exit gate, and a hard rule that you never start a phase until the one before it is demonstrably done. This lesson explains the whole road (both tracks), why it is ordered the way it is, and exactly which milestone you are standing on today.

Plain-English first: think of Paras as two factories built in sequence. Track B (SENTINEL + the kernel) is the research laboratory — it has to exist and be trustworthy before anything is allowed to touch real money. Track A (AXIOM) is the execution fortress that places live trades — it forks off the research track only after the research engine can prove its own arithmetic. You are at the very start of Track B: the data plant (the thing that feeds everything) is alive but not yet certified.

How the roadmap works (the mechanism): every phase in docs/05 has an Exit criteria column. The phase is not 'done' because the code compiles or the tests pass — it is done when its exit criteria are demonstrably met AND an independent auditor (not the author) grades the gate green (D-080). Only then may the next phase open. This is the single most load-bearing rule in the whole build: B0→B1→B2→B3 is strictly sequential.

Example of the gate-lock in action — why M2 is hard-blocked right now: the kernel (Track B's brain) does not technically depend on whether the plant survives a soak. So the operator made a careful, narrow exception (D-082): M2 kernel groundwork — DESIGN/DATA rings and pure-kernel BUILD in an isolated git worktree — MAY proceed in parallel with the soak. But the formal M2 open, the ceremony, and any work that wires kernel components into SENTINEL or stops/rebuilds the running plant stay blocked until M1's soak is green and the independent assessment passes. That is the gate being respected precisely, not bent.

What to be aware of, operator-side: most of the remaining M1 work is YOURS, not the builder's. The 72h soak runs on your physical machine (run-as-Administrator, keep it awake on AC, High-Performance power plan). A failed soak is never weakened to green — it is root-caused and re-run. And the moment M1 closes, the post-M1 build queue is already specified (single-writer fail-fast guard D-086 first, then the PULSE control-face D-085) — but none of it lands mid-soak, because a rebuild during a soak invalidates the soak (D-082).

Locked decisions & the why

You're building Paras solo, leaning hard on AI to move fast. That speed is the whole point — and it's also the danger. An eager assistant, left to its own judgment, will quietly re-open the same questions every session and let the answers drift, until a thousand small 'reasonable' edits have turned the system into something else. DECISIONS.md is the antidote. Its own header is blunt: 'Do NOT relitigate these inside build sessions.' And CLAUDE.md gives the operating rule: 'If a build request conflicts with a locked decision, stop and flag it rather than silently complying.' This page is your map of the decisions that matter most, so you can recognize when one is being violated — and say so.

A 'decision' here is not a code change. It is a durable choice about HOW the system works that you never want to argue twice: 'all three apps are WPF,' 'the kernel is a pure library,' 'no LLM in any order path,' 'Topstep rule values live in config, never as constants.' We'll take them in five groups, in roughly the order they shape the system: (1) ARCHITECTURE — the bones; (2) the AI BOUNDARY — what the machine is and is not allowed to do; (3) DATA — the ground truth everything stands on; (4) MODEL & RESEARCH — how edges are found honestly; (5) OPERATIONS — how it's run, graded, and kept alive. For each, the choice, the why, and the consequence of reversal.

GROUP 1 — ARCHITECTURE: the bones. These five decisions fix the shape of the system. Everything else is built inside the box they draw. The keystone is D-001: there is ONE shared C# kernel; SENTINEL backtests it and AXIOM trades it — so the code that trades IS the code that backtests. That single choice is what makes a backtest result mean anything: if the live system ran different code, your backtest would be measuring a system you'll never actually trade. D-003 protects it by keeping the kernel a PURE library — no venue SDKs, no HTTP, no UI, no LLM, no Topstep values, no wall-clock reads (the clock is injected). Purity is what lets the same kernel run identically in a backtest, a parity court, and live.

GROUP 2 — THE AI BOUNDARY: what the machine is allowed to do. This is the most important group for a system whose whole pitch is 'AI-automated.' The line is absolute and it is drawn at D-005: NO LLM in any order path; the AI sidecar can only veto, narrate, resist, or reflect — never approve, place, size, or modify. The runtime AI's only power is to say NO. Why so strict? Because LLMs are reasoners and veto filters, never forecasters or order managers (Principles 4–5). An LLM that could place or size an order would be a non-deterministic component in the one place — the order path — where you need provable, repeatable behavior. The consequence of reversing this is catastrophic: a hallucination could become a live trade.

GROUP 3 — DATA: the ground truth. Every backtest, every indicator, every decision stands on the bars in the vault. So the data decisions are about provenance and integrity. D-010 makes TradeStation the primary source (free, deepest history). D-011 stores M1 from 2008 so stress regimes (2008, COVID) are in-sample. D-012 is the discipline that prevents silent corruption: ALL intermediate timeframes (M5/M15/H1...) are DERIVED from canonical M1 by one consolidator — never extracted separately. If you pulled M5 separately, it could silently disagree with the M1 it should aggregate to, and you'd never know which was right (Principle 7: one source of truth per concern). The most recent and most important data decisions, though, came from a hard lesson during the M1 soak.

GROUP 4 — MODEL & RESEARCH: how edges are found honestly. This group exists to stop the single most common way trading research lies to itself — torturing data until something looks profitable. D-031 is the gatekeeper: G0 requires a stated one-sentence MECHANISM — no mechanism, no run; pure pattern-mining is BANNED. D-030 makes every run a counted trial against a pre-registered budget, with re-rolls facing a higher hurdle (DSR), and that budget gate is CODE, not Claude. D-020/D-021 give you the two-speed engines and the three-engine parity court (kernel / TradeStation EasyLanguage / LEAN) where an unexplained delta is a STOP-EVERYTHING event. And D-087 makes 'the code that trades is the code that backtests' concrete at the feature level while explicitly DROPPING the seductive 'compose combos and see what works' idea.

GROUP 5 — OPERATIONS: how it's run, graded, and kept alive. These decisions are about the system staying trustworthy day to day. D-040 keeps Topstep rule values as versioned config (config/topstep-rules.json), re-checked WEEKLY (D-063) — never as constants — so a rule change is a config edit that activates at the next pre-flight, never a code change. D-041/D-042 lock the safety rails: automation only on Combine/Express (hard-blocked on Live Funded), no VPS/VPN, no manual order entry in AXIOM, config immutable during market hours, and the only 'override' opens a Gemma chat that can grant nothing. D-071 is the continuity doctrine — nightly VERIFIED backups, a drilled restore path ('a backup that has never been restored is a hope, not a backup'). And two decisions changed how the whole project is built and graded.

WHY THIS WHOLE FILE EXISTS — the deepest reason. Constitution Principle 11 says: 'The system adapts by saying no more often — never by quietly becoming a different system. Live params are immutable; adaptation = suppression, retirement, and new pre-registered hypotheses through full gates.' DECISIONS.md is the memory that makes Principle 11 enforceable. Without it, a solo operator and an eager AI would re-open settled questions every session and drift. With it, you can trust that the system you designed last month is the system running today — and that any change is dated, sourced, and traceable. The file is not bureaucracy; it is the thing that keeps Paras honest about its own identity.

Locked decisions & the why

Think of the register the way you think of a trading checklist before the open: it is not paranoia, it is the list of things that have actually killed accounts. In enterprise IT you called this a risk register too—a table of risk, mitigation, owner, and status. Paras keeps exactly that discipline, but with one twist that makes it Paras: every mitigation is anchored to a specific build gate or phase, so the control is something the code must demonstrably pass, not a line in a policy document nobody reads. The source of record is docs/05 §5 (the build-time risk register); the living working copy is tracking/RISKS.md, which you update in place and never delete from.

There are two layers. Layer one (§A, R-01…R-09) is the build-time register—the strategic risks to the whole project. Layer two (§B, T-01…T-06) is the Paras-Method testing risks: the precise failure modes the verify ring exists to catch, which are how R-01 actually shows up in practice. This lesson focuses on the six headline rows from docs/05 §5 that the operator must watch, then points at the testing layer underneath them.

Now the same six rows as a course, one at a time—what each is, why it earns a place, how its control works, and what you must watch.

Beyond the six headline rows, the register has grown three more build-time risks worth knowing—they show how a living register actually lives: R-07 (the LEAN-as-engine spike could pivot the architecture and break parity-by-construction—blocked unless its pre-committed four-part rule passes AND a dated superseding DECISIONS entry is written, because it touches D-021/D-024/Principle 3); R-08 (single-machine hardware failure could destroy the unrepeatable tape, ledger, and learnings—mitigated by the Continuity doctrine of tiered, verified, monthly-drilled backups, currently MITIGATING); and R-09 (market-calendar mis-modeling, found live during the M1 soak on 2026-06-18, where one CME-equity calendar over-closed @ES/@CL/@GC and flapped quality to warn—driving the per-instrument market-model hard rule D-094).

Underneath R-01 sits the testing layer (§B). These are the standing tests, not one-time checks, that catch how a fill-model bug actually manifests: T-01 determinism deltas (same spec + same bars must produce byte-identical trades), T-02 golden-fixture drift (canonical trade-lists must not change silently), T-03 parity-bug contamination (the stop-everything court), T-04 cost-model optimism (costs pessimistic by default until calibration), T-05 AI sidecar leaking into the order path, and T-06 verdict/reflection leakage into behavior. A standing architecture test greps and audits to prove no verdict- or reflection-derived value reaches execution, sizing, filters, or gates.

Locked decisions & the why

You're running a trading-research system solo, local-only, on your own desktop. That's a deliberate choice (budget-true, security-first, no VPS) — but it concentrates all the risk in one box. docs/09 opens with the blunt truth: 'Paras runs entirely on one personal Windows machine. That machine will eventually fail.' The job of this doctrine is to turn that inevitable event from a catastrophe into a chore. The only thing that ever leaves the machine is the private GitHub remote (code, docs, tracking — no market data, no secrets), which was already accepted at D-060. Everything else is protected locally, on purpose.

There's one insight that shapes the entire design, so learn it first: the startup gap-sync is the migration healer. Because the data plant self-heals any gap from its last checkpoint (docs/02 §1.2), a restored backup that is days stale simply gap-syncs forward to NOW on first start. That means your backups never need to be perfectly fresh — they need to be VERIFIED and RESTORABLE. Freshness is automatic; restorability is the thing you must guarantee. Hold that thought; it's why 'verified' matters more than 'recent' everywhere below.

PART 1 — WHAT WE PROTECT, AND WHY NOT EVERYTHING. The doctrine refuses to back up everything blindly. It sorts artifacts into five tiers by how replaceable they are, because spending effort protecting a thing you can rebuild with a script is wasted effort. Understanding the tiers tells you instantly why a lost ledger is a disaster but a lost LEAN checkout is a shrug.

PART 2 — THE BACKUP DOCTRINE (3-2-1, adapted local). The classic rule is three copies, two media, one offline. Paras adapts it for a local-only operator. Cloud storage of market data was declined (your preference); the residual fire/theft risk is documented and accepted in §6, with the Tier-0 TEXT corpus already offsite on GitHub. Three layers do the work:

PART 3 — THE RESTORE DRILL (non-negotiable). A backup you've never restored is a guess about the future. The doctrine therefore mandates a drill: MONTHLY during build phases, QUARTERLY once operating — restore the latest snapshot to a scratch folder, open it, run the §5.5 verification queries, and file a TEST_LOG.md evidence row. Crucially, the drill is graded by the auditor (ULTRACODE Law U4), NOT by whoever wrote the backup job — the author never grades their own gate. And the very first restore test is not optional polish: it is an M1 exit criterion (runbook M1.8: 'Nightly backup job + one tested restore').

// §5.5 Post-restore verification queries (also the restore-drill script):

-- bar coverage advances after gap-sync, counts >= manifest:
SELECT count(*), max(end_utc) FROM bars GROUP BY symbol, res;

-- the irreplaceable tables must match the manifest EXACTLY (never regenerate):
SELECT count(*) FROM experiments;
SELECT count(*) FROM trials;
SELECT count(*) FROM gate_results;

-- data-quality job over the restore gap -> zero ok=false days post-heal
-- one tape Parquet file from the snapshot opens and row-counts > 0

PART 4 — THE SECRETS INVENTORY (the recovery checklist). Tier-4 things — the DPAPI-encrypted tokens — can NEVER be copied; DPAPI binds them to this machine+user by design. So they are not backed up; they are RE-ENTERED. The §4 table is the recovery path: every secret has a row naming where it lives and the exact procedure to re-enter it on a new machine. The standing portability rule is strict: adding a secret anywhere in the system WITHOUT a row here is a review-blocking violation. Secrets live only behind the DPAPI TokenStore abstraction — never in code, config files, or git, ever.

PART 5 — THE MIGRATION RUNBOOK (target: under half a day, mostly unattended). When the machine dies, you don't improvise — you walk §5. The pre-condition is guaranteed by the doctrine itself: a verified B-2/B-3 backup exists. Then six steps:

PART 6 — THE PORTABILITY RULES (why migration is even possible). The runbook only works because every module obeys six standing design laws from M0 forward, enforced at code review. These are what make the new machine accept your code with a single config line instead of a rewrite:

• No absolute paths in code — all paths resolve from configuration relative to the repo/data root. A different drive letter on the new machine = one config line, zero code changes.
• No machine assumptions — no hardcoded hostname, username, core counts, or screen geometry; discover at runtime or read from config.
• Every prerequisite is scripted — if a task requires installing anything, the SAME change updates scripts/setup-machine.ps1 (winget-based, idempotent).
• Every secret is inventoried — secrets live only behind the DPAPI TokenStore, each with a §4 row and a re-entry procedure. No secret in code, config, or git, ever.
• One data root — all mutable state lives under ops/ (+ the DuckDB files), never in %APPDATA%, the registry (sole exception: the PULSE Run key, recreated by the setup script), or scattered folders.
• Backups are part of the plant, not an operator chore — the nightly job is code with tests; only B-3 (plug in the external disk) involves a human.

Locked decisions & the why

Paras has its own vocabulary, and a lot of it overloads words you already know from trading and IT. 'Model' here means a trading strategy, never an AI model. 'Cell' is one counted experiment, not a spreadsheet box. 'Gate' is a pass/fail checkpoint, not a network device. Getting the vocabulary right is the difference between reading a dashboard and being able to act on it — so the terms below are grounded strictly in the specs (docs/00–06) and the in-repo glossary card. Nothing here is invented.

The next two ideas are the spine of how Paras organizes research: the hierarchy that classifies a trade idea (Edge Class → Family → Model → Cell), and the experiment_cell coordinate that pins down exactly what got tested. Get these two right and the dashboard reads like a sentence.

The gates are the seven checkpoints (G0–G6) every model crosses in order, like belt tests — you cannot skip ahead. They get progressively harder and more expensive, so the cheap tests kill bad ideas before you spend on the expensive ones. Here is each gate, what it asks, and what happens on failure.

Two words in this codebase overload each other dangerously: 'ring' and 'gate'. Rings are how the BUILDER works (the six-step method for writing code). Gates are how a STRATEGY is judged (the seven-step deflation pipeline). They are unrelated ladders — keep them separate in your head.

Locked decisions & the why