Leigen — Q3 Alignment & Ratification Session
Rev 3 — July 20. Big turn: Bob published the operating-model package (PR #185) — approved from Vash's seat, Adam's review pending. Dollars-first gates are RATIFIED (Vash), spec v2 is pushed to #182, and the ratification forum is now the Wednesday Jul 22 grid session (Bob proposes the baseline grid, Adam signs off). Receipts shipped as PR #186. Orange chips = an answer is still owed.
The Goal (one paragraph)
Q3 = the AI Agent Prop Fund. Get at least one Intelligent Trading System (ITS) live by September 30 — starting with Marcus V2. Every Tradovate slot is a trader's seat that must be earned: each ITS gets a virtual capital pool and must grow it without blowing up, while passing a daily decision-quality review (DDQ). Mechanical strategies (ORB etc.) move to a simulation engine — they can power an ITS, but only agentic traders hold seats, because judgment is what makes live automation trustworthy.
Where Things Stand (as of Rev 2)
The Path — 5 Steps to "Marcus Is Deployed" (plain terms)
1. Safety plumbing (Vash — 2 of 3 built) — Three pieces: the name tag ✅ (every order records which trader placed it — PR #183, in review), the receipt system ✅ (a restart or network hiccup can never cause a duplicate or orphaned order — PR #186, review round 1 passed), and the on-switch (trading authority is an explicit, expiring authorization that verifies it actually took effect — building Mon–Tue; rehearsal gate G7 needs it).
2. One box (Bob — committed at the 7/19 call, still the long pole) — Marcus's brain, broker connector, and commands currently live across different branches that can't import each other (the operating model documented exactly why — nested repos and divergent worktrees). Package them into one tested unit before Tradovate connection, so what we rehearse is exactly what runs.
3. Prove the books (Monday — automatic) — The bookkeeping bug (#147: real trades happened, zero fills recorded) is fixed and deployed. Monday's first ORB trade must land correctly in the books. No trusted books → no rehearsal.
4. The dress rehearsal (together, ~1 day) — Seven checks like a pre-flight: read-only checks → place & cancel a far-away order → one real supervised fill → move the stop & verify the broker moved it → restart mid-trade & recover → close out with records matching the broker exactly → switch off & prove no orders possible.
5. Deployed = evaluation begins (~Jul 28–Aug 1) — Marcus trades daily on his demo seat: virtual pool tracked, DDQ graded, Slack ping to Bob before each entry (logged, never controlling). Live money is a separate authorization after he passes — September.
Agenda (if the sit-down happens — otherwise the tracker above is the record)
Ratification Tracker (Rev 2 — Bob's responses folded in)
AGREED settled NEEDS ANSWER owner owes a call DEFAULT STANDS unchallenged — confirms at Wednesday's grid session (the ratification forum per the 7/19 call: Bob proposes, Adam signs off, spec #182 is the single pen)
Clarifications (answering Bob's notes directly)
"What is B minus?" — resolved by a discovery. The letter grades are dead, and better: the operating-model package revealed Bob's side already built the real thing — DDQS, a deterministic process-scoring system. Each day scores 0–100 across six pillars (permission & no-trade 20 · data truth & diet 20 · mandate fit 20 · risk & order quality 15 · execution & reconciliation 15 · evidence & learning 10), from evidence only — never P&L, never the trader's self-report. Days under 90% evidence coverage are UNSCORABLE; serious defects cap the score. Spec v2 adopts DDQS as-is: passing needs zero disqualifying defects, zero UNSCORABLE days, and a daily-score floor Adam proposes Wednesday. A losing day can score clean; a winning day that broke rules cannot. The pool answers whether to trust a trader — DDQS answers why. Adam's daily ACK/QUESTION/ESCALATE is QA review, never promotion authority.
Where R goes (it doesn't fully die). Per Bob: the gates become plain dollars — pass +$1,500, fail −$1,000, daily lockout in dollars. But every trade still declares its planned risk at entry in its decision log: Adam needs it to check risk compliance anyway, and it quietly builds the dataset for comparing traders of different sizes when there's more than one seat filled. Logged, never gating.
Frozen mandate, in one breath (new since Bob's read) — The mandate is who the trader is: prompt, model, risk policy, input set. It freezes when the trader leaves the Foundry; changing any of it mid-eval voids the eval and sends the trader back for a fresh start. Everything around the trader — plumbing, data delivery routes, monitoring — stays freely changeable, logged. Rule of thumb: fix the desk, never the trader.
Still Owed — One Answer Each
The Two GEX Answers (#164) — Defined
GEX Answer #1 — Can our GEXstream login run in two places at once? Bob's Mac holds a logged-in GEXstream session that captures the rich options data (vGEX) Marcus decides on. For the VPS to capture that same feed on its own — the autonomy requirement — it needs its own logged-in session. The question: does GEXstream allow one account logged in from the Mac and the VPS simultaneously, or does the second login kick the first (or breach the terms), meaning we buy a second seat? A complete answer is one of: "simultaneous works, confirmed" · "second seat needed — it costs $X/mo" · "unclear from the ToS, here's what support said." Checking account settings, the ToS, or just testing a dual login for ten minutes settles it.
GEX Answer #2 — Where does the rich-capture code live? PROMISED Now a committed call action item: Bob's data-pipeline doc, due this week, covering the rich-capture source (repo/branch), truth-layer flow, and migration path. That doc, received, closes this answer. Vash still needs it to port that exact capture to the VPS and prove two-session parity. Until the doc lands this stays open — it just has a named vehicle and a date now.
Why these two, and how urgent — Neither blocks the evaluation: Marcus runs on Bob's Mac-local data through every supervised phase, per the ratified data ruling (#170). But both block Vash's #164 build starting next week — and #164/#165 (VPS captures its own rich GEX + delivers it verifiably) are the hard gates for autonomy and live capital. Every week these answers wait, the September live milestone gets tighter. Ten minutes of Bob's time now protects the quarter's endgame.
Timeline
NOW ————————— late July ————————— August ——————————— September ——→
Mon: books proof Rehearsal G1–G3 EVALUATION RUNS DAILY pass → LIVE ($1–1.5k)
(#147 acceptance) G4 supervised fill (Bob's Mac data, Bob |
~Jul 24–28 supervising, VPS executes) |
—— in parallel —— |
#164/#165: VPS rich GEX └─ then Mac Mini =
+ delivery (autonomy gate) autonomous host
Mini purchased + set up (brains only)
Who Owns What
Sources: PR #182 (Evaluation Spec v2), PR #185 (operating-model package + 7/19 call summary), PR #183 (trader_id), PR #186 (receipts), PR #177 (Q3 OKR), issue #170 (Marcus cutover master, incl. the data ruling), Bob's async eval-spec notes. Rev 3 — updated July 20, 2026.