The grade board, live.
Mr. Claw is a deterministic, rule-based signal engine that scans stocks & crypto across multiple timeframes, detecting price-vs-momentum divergence and scoring each setup 0–100 — graded A through D. No randomness, no model in the math: identical inputs always produce identical signals. Six boards refresh on their own cadence; the one below is rendered live straight from the engine.
A two-engine algorithmic trading system with a clean split between live operations and research — one engine finds and grades setups live, the other replays history to prove they hold up. LLMs do the research and design; they are kept entirely out of the signal and backtest math.
Mr. Claw — live signal engine
Scans stocks and crypto across 1h / 4h / 1d, validating data health before it runs rule-based divergence detection between price structure and momentum. Each setup is scored, graded A–D, and diffed across runs (new vs. changed) so alerts stay clean. The board below is its output, live.
Lord Croc — backtest engine
Replays historical candles through the same scoring logic to simulate entries and per-trade results. Every run is reproducible — stamped with commit, cache hash, and config so the same inputs always yield the same graded outcome, with a zero-drift integrity gate.
The signal engine, live — straight to this page. Each row is a confirmed price-vs-momentum divergence, its 0–100 score a weighted confluence of WaveTrend-style waves, money flow, RSI / Stoch RSI, and VWAP alignment, bucketed into an A–D grade. kΔ measures how far price has extended from the divergence structure — lower is a tighter entry.
A–D with a 0–100 score. A is a clean, high-conviction setup; D is weak or unconfirmed.
Bull / bear — the direction of the detected momentum pivot.
How many bars since confirmation. 1–2 is fresh ✨; higher means the move is aging.
Move size in ATR units. tight entry · stretched · extended.
Determinism as a design constraint.
Given an identical candle cache, config, and commit, the engine must produce identical signals, grades, and artifacts — no randomness, no nondeterministic ordering, no model in the scoring. Backtests enforce a hard zero run-to-run drift integrity check, and every run carries a full identity block — git commit, cache SHA256, config snapshot, universe snapshot, and per-stage candidate counters — so each result is replayable, not merely repeatable. The whole signal codebase runs on the Python standard library only, which keeps the runtime small, auditable, and free of dependency-version drift.
Live and replay determinism are treated as two separate guarantees, validated independently: a fixed-cache replay can’t exercise cron timing, partial candles, or provider lag, so it never stands in for live correctness. Timing semantics are modeled with the same care — mathematical confirmation, real-time knowability, and detection telemetry are kept distinct, which rules out lookahead bias by construction. Behavior is pinned to an explicit engine-version cutoff so historical artifacts stay interpretable as the code evolves.
Development runs through an LLM-assisted, multi-reviewer workflow with scoped authority lanes — infrastructure, strategy, backtesting methodology, code-as-written — so every claim is confirmed against the code, the runtime, or the right domain reviewer rather than asserted. The reasoning layer drives research, design, and orchestration; it is deliberately kept out of the signal and backtest pipeline.
Self-managed production.
Deployment is split by role across two hosts I own end to end: the live signal engine on a remote VPS posting alert boards to Discord, and the research engine on a local machine. Scheduling is cron-driven, including an hourly checkpoint that emits provisional pre-close previews for earlier visibility into developing setups.
Operational data — candle caches, universe snapshots, alert logs, trade tracking, and weekly stats — lives as durable runtime state, kept separate from the version-controlled code. The system tracks an explicit source-of-truth layering (docs, experiments, code, deployed machines) and treats drift between committed code, deployed code, and cron state as a named failure mode rather than an afterthought. A live-ops stack handles alert logging, paper-outcome resolution, and an automated decision monitorthat evaluates pre-committed risk triggers — circuit-breaker rules written down in advance so a losing streak can’t be overridden in the moment. The engine is the dealer applying the rules with total consistency; the operator’s job is the owner role — research, monitoring, and the kill switch — never trade-by-trade decisions.