Skip to content
ORDR-DESK
Register

ORDR-DESK · Technical Implementation

Server-Side Validation.

We reject discretionary performance reporting. ORDR-DESK's validation engine is a server-side process that checks market observation data against the entry, stop and target levels recorded for each call. The monitor and the publishing workflow change a call's status through database functions that check its current status first.

What “database-enforced” means here →
System Specification
ArchitectureBranching
State Transitions13 statuses, not one-way
ReconciliationGaps recorded, never inferred
Ledger StorePostgres, append-only events
Phase 01

Quantitative Formulas

Weighted Exit

A call can scale out. Each target hit before the call closes exits its allocation at the price recorded for that hit, and the remaining allocation exits at the close price. Only recorded prices enter the figure.

X̄ = ∑ ( wi · Pi ) + ( 1 − ∑ wi ) · Pclosewhere wi = allocation of target i hit before the close, Pi = its recorded hit price

Call Return

Return runs from the trigger price to the weighted exit, signed by direction. A completed call that returns less than 0.05% either way is breakeven; otherwise it is a win or a loss. Expectancy is the average return of completed calls. Calls an operator has quarantined are left out of these figures.

R = ( X̄ − Ptrigger ) / Ptrigger × 100for a long call; a short call reverses the sign
Phase 02

The Append-Only State Machine

A published call moves through a branching state machine. From waiting, it can trigger, expire, be cancelled, or be invalidated. A transition that is recorded is not rewritten.

Signal lifecycle →

1. Published → WaitingIdea is published with entry zone, invalidation, and targets. System awaits market price action.
2. Waiting → Triggered / ActiveMarket prices tick within the qualifying entry bounds during an eligible session. Setup is live.
3. Active → Target Hit / InvalidationPrice reaches target horizon or touches invalidation stop. The transition is recorded in the append-only events table (signal_events), where a database trigger rejects updates and deletes.
PUBLISHEDWAITINGEXPIREDACTIVE
Phase 03

The Gap Policy

In real-world distributed systems, data feeds occasionally disconnect. If a data provider fails and both an Entry and a Stop are crossed during the blackout period, ORDR-DESK does not heuristically infer the sequence.

09:30:14Connection Stable
UNVERIFIED INTERVAL (DATA LOSS DETECTED)
09:31:12Connection Restored

The interval is recorded as a monitor gap rather than assumed clear. The monitor writes its market events only from fresh, ordered trades it actually observed, at their own price and time; nothing is inferred for the gap itself.

What “database-enforced” means here →