Harpy has three moving parts on your machine — the scheduler, the scanner, and the dashboard — and they pass data in one direction only: scheduler → scanner → disk → dashboard. That’s the whole architecture. Everything else is a refinement of one of those three pieces.
The scheduler
Your operating system’s built-in task scheduler is the clock. On first launch, Harpy registers only the tasks the module you installed needs. A Trade installer gets a position monitor every 5 minutes, a deep scan every 45 minutes, and a weekday rollover at 06:45 ET. A Horses installer gets the rollover plus a single deep scan cadence tuned to the global racing industry. Before it registers anything new, Harpy clears out any previous Harpy-owned tasks on the machine, so switching modules on a single computer can never leave orphan cycles firing in the background.
The scanner
When a scheduled task fires, a short-lived research process starts. It reads the strategy document for the module you installed, fetches whatever live data the strategy calls for, forms a plan, makes its decisions, and writes the result to a private local folder. Then it exits.
No daemon, no long-running process, no background agent hanging around between cycles. Each cycle is a clean-slate run from launch to exit. If anything goes wrong mid-cycle, the next scheduled fire starts fresh with no leaked state.
Strategy documents
The strategy document is where the real logic lives. It’s a plain-text file — no proprietary format, no DSL, no hidden configuration. Each module ships with one of its own, tuned to the market it covers. The document tells the scanner what data sources it has, what rubric to apply, what output to produce, how much API budget to burn, which jurisdictions to scan, and what to skip when short on information.
The documents are not secret. You can open the one on your disk, read it, edit it, and the next scan cycle will pick up the change. If you disagree with the overlay threshold, the confidence rubric, or the staking math, rewrite it. The scanner will follow your version. We treat the published strategy document as a recommendation, not a moat.
The dashboard
The dashboard is a local web application the installer ships with Harpy. It polls a small local service and reads the same on-disk output files the scanner writes. The dashboard never calls the scanner directly, never triggers a scan, and never modifies the target files. It is a strictly read-only view of your system’s state — what the scanner most recently decided, what your journal looks like, which positions are open, what was rejected and why.
Why this shape
We chose one-way, file-based hand-off for two reasons. First, it makes every layer auditable — you can inspect any stage of the pipeline by opening a file in a text editor. Second, it makes the system robust to partial failure: if the scanner crashes mid-cycle, the dashboard still renders the last good output; if the dashboard crashes, the scanner keeps firing on its schedule; if both crash, the next scheduled task starts from a clean slate.
A trading system should degrade the way a newspaper does — today’s edition is stale by tomorrow, but it’s still readable.
The next posts in this series walk through each module one at a time, starting with Trade.