Case Study
Sentinel
Options swing trading bot with a veto-only risk layer
- Platform
- Automation & Integrations
- Year
- 2025 - 2026
01 / 01 โ Confirmation sign-in
Select thumbnail ยท click image to enlarge
Screenshots come from the real applications. Sensitive names, identifiers, and credentials are redacted.
01What it does
Screens options setups on a schedule, applies strategy filters, then passes every candidate through a risk layer that can only veto - never widen - risk. A confirmation server keeps a human operator in the loop, and a journal records round trips for review.
02What I built
- Strategy, execution, broker, risk, analysis, journal, and data modules with strict Pydantic models
- Scheduling with APScheduler anchored to a trading timezone
- Two-service Docker Compose deployment: an always-on confirmation web service and a scheduled screener sharing a persistent SQLite volume
- A kill switch and daily counter that survive container restarts by design
- VPS deployment tooling over SSH
03Key engineering work
- Whole-package pytest coverage gate at ~94%, with omissions documented and visible rather than silently allowlisted
- Risk sizing anchored to a cash cap; breakeven guard placement driven by journaled trade data, not guesswork
- AI-assisted analysis via the Anthropic API as an optional dependency
- Docker timezone and log-rotation configuration so missed trading windows are diagnosable
04Challenge / Solution
Challenge
Trading bots fail dangerously when risk rules and application state reset on every redeploy.
Solution
The risk layer is veto-only by architecture, and runtime state (kill switch, daily counter, audit trail) lives on a mounted volume - a HALT survives a redeploy instead of being cleared.