Proposed evidence, instrument, trade reference and review requirements.
Trusted decision / server checks
Prove it against the input.
Verbatim quotation, candidate membership, recomputed review rules, then correctness and numeric risk.
Practice only. Every mode.
01 / The problem
The problem
Trading posts are informal and ambiguous. An LLM can help interpret them, but its confidence, citations and description of its own reasoning cannot be trusted as execution authority.
02 / What I built
What I built
A signal pipeline that ingests selected X posts, extracts structured instructions, independently verifies evidence, checks correctness and numeric risk, then observes, asks for approval or executes against OANDA practice. Reconciliation compares local state with the broker. There is deliberately no live-account execution path.
03 / Architecture
Architecture
01Input → immutable raw post↓
02Cheap deterministic pre-filter↓
03LLM classification → context engine↓
04Structured extraction↓
05Hard safeguards → evidence and candidate checks↓
06Deterministic validator↓
07Numeric risk manager↓
08Mode gate → observe / approval / practice_auto↓
09OANDA practice only↓
10Reconciliation → audit trail
04 / Key decisions
Key decisions
01
The model’s account of what it did is never the authority
Quoted evidence must exist verbatim in the source. Trade IDs must belong to supplied candidates. The server recomputes review requirements; an absent instrument can force review even when the model claims it inferred one.
02
Correctness and risk are separate decisions
The validator checks staleness, instrument mapping and stop/target relationships. The risk manager checks exposure, spread, reward/risk, limits, cooldowns and sizing. Passing one does not imply passing the other.
03
Mode changes who presses go
Observe, human approval and practice_auto share the same safeguards. A mode change cannot bypass downstream validation. The broker layer rejects anything except OANDA practice.
05 / What went wrong
What went wrong
The circuit breaker that could never reset
Problem
A consecutive-loss breaker halted trading for five days.
Why it happened
Resetting it required a winning trade. The active breaker prevented any new trade, so the recovery condition could never occur.
How it was detected
Operational investigation exposed the circular dependency between the halt and its reset condition.
Response
The fix uses the breaker’s own state: reaching the loss-streak check with no active trip means the halt has been served, so the streak resets instead of re-tripping. An operator clear is no longer silently overridden by the counter.
Lesson
A safety mechanism needs a reachable recovery path. Stopping safely is only half of the state machine.
06 / Evidence
Evidence
Evidence and review requirements are checked independently of model self-report.
Operational incidents exposed missing close/update paths, resting-order bookkeeping gaps and broker/dashboard state disagreement.
Gold pip scaling made configured thresholds effectively untradeable; an ephemeral filesystem incident erased historical state. These are operational lessons, not performance evidence.
X Copy-Trade Tool / existing project capture
Existing project capture. The case study describes the reviewed system; this image may show an earlier interface.
07 / Current status & limitations
Current status & limitations
Practice · No live-money path
A running practice system with a public read-only demo. The observed trading sample is small and net negative. No profitability claim, no live-money execution and no claim that the public demo mirrors every private-system revision.
Evidence basis: project implementation review and research notes supplied for this portfolio, September 2026. Project tests described here are distinct from the portfolio’s own checks.