How It Works.
From levels recorded in a numbered version at publication to a revisioned performance record. This is the lifecycle every published call follows.
Five-Stage Architecture
One lifecycle, with a fixed set of statuses, for every published call.
Market Research Defined Before the Move
A call is written as a thesis with a direction, setup type and timeframe before it is published. Publication stamps the time and freezes the first version of the call, so the reasoning on record is the reasoning that existed before the market moved.
- Written thesis, direction, setup type and timeframe
- Publication time stamped by the database at publish
- Dated market briefs record regime, volatility and sector context
- The first version is frozen at publication and cannot be edited
Explicit Entry, Stop, and Targets
Every call publishes an entry zone, a stop, and one to three ordered targets (T1, T2, T3). Publication is refused unless the stop and targets sit on the correct side of entry, and the planned reward-to-risk is computed from those levels before publication.
- Entry zone with a lower and an upper bound
- A stop on the losing side of entry, checked by the database
- One to three ordered targets; set allocations must total 100%
- A revision through the revision workflow adds a new version; earlier versions are never rewritten
Server-Side State Machine
Server workers evaluate trade observations from a named market-data feed against the levels recorded for each call. The state machine has 13 statuses. The monitor and the publishing workflow change a call's status through database functions that check its current status first. A call is not counted as triggered until an observation in an eligible session meets its entry condition.
- Observations from before publication are ignored
- Main path: WAITING → TRIGGERED → ACTIVE → CLOSED
- Other outcomes: TARGET HIT, STOPPED, INVALIDATED, EXPIRED or CANCELLED
- Calls that never trigger are counted separately, never as wins
Append-Only Event Ledger
Each lifecycle event the monitor or publishing workflow applies is written to the signal events table with its type and time. Market events also carry the provider's market timestamp and the price observed at that moment. A database trigger rejects any update or delete on the events and on the frozen versions.
- Database triggers reject edits and deletions of versions and events
- SHA-256 idempotency key on each market event the monitor writes (trigger, target, stop, invalidation, expiry), so a retried write is recorded once
- A published call cannot be deleted while its versions and events exist
- The call's own row carries no such trigger; Evidence Integrity lists this gap
Performance From Recorded Outcomes
A reconciliation job computes performance from the recorded outcomes of published calls: win rate, loss rate, average and median completed return, and target-hit counts. These are call statistics, not a portfolio or account result.
- Each snapshot stores a SHA-256 digest of its source records
- A recomputation inserts a new revision; it never overwrites one
- Winners, losers, breakeven and stopped calls are all counted
- No win rate or return is shown until published calls have completed outcomes
Explore Documentation
In-depth references and framework disclosures.
Validation Methodology
The methodology: the state machine, the gap policy, and how performance is calculated.
Signal Lifecycle
Every status a published call can reach, and the transitions declared between them.
Evidence Integrity
What the database enforces, how it enforces it, and what the record does not guarantee.
Performance Record
The published track record. Win rate and returns appear only after published calls have completed outcomes.
See What Members Receive.
ORDR-DESK Pro is $99/mo and Premium is $299/mo. The pricing page lists what each plan includes and whether paid membership is open.