← All work

Builder (personal research) · 2026–present

Freedom Machine: autonomous research infrastructure

A personal, paper-only research system built as a reliability-engineering exercise. An LLM proposes hypotheses, a separate deterministic layer decides, and a chaos-engineering suite of 3,000+ offline tests proves it fails loudly rather than silently.

PythonAutonomous agentsChaos testingAPSchedulerStatisticsData integrity
A multi-monitor trading desk with charts
Research infrastructure

What it is

A personal research system that generates and rigorously screens quantitative hypotheses on its own schedule. It is paper-only: no real-money execution, and it makes no financial claims or recommendations. I built it less as a "trading bot" and more as a testbed for a hard systems problem: how do you let an AI run unattended and still trust the output?

The interesting engineering

  • LLM proposes, a deterministic layer decides what's real. An LLM generates rationale-first hypotheses on a recurring schedule. A lightweight LLM triage drops the obvious duplicates. Then a separate, fully deterministic statistical layer takes over: multiple-testing deflation, a hierarchical pilot→sweep protocol, and correlation/redundancy pre-filtering, all pre-registered before any data is touched. That layer is the sole arbiter of whether an edge is real. The model that dreams up an idea never gets to decide whether it survives the statistics.
  • Pre-registered, then unattended. A nightly campaign scheduler runs with zero human intervention, gated by statistical templates written before any data is touched, and hard-scoped so it can never reach anything that would matter beyond the sandbox.
  • A literature-mining pipeline harvests from OpenAlex, Semantic Scholar, arXiv, and CrossRef weekly, classifies abstracts with a schema-constrained local LLM into a structured research map, and routes anything low-confidence to a human review queue instead of auto-accepting it.
  • Chaos engineering, for real. A dedicated fault-injection suite (tests/chaos/) kills the process mid-critical-section, corrupts checksums, truncates append-only stores, and forces lock contention. Then it asserts the system surfaces each fault by name rather than merely "not crashing." The full gate runs 3,000+ tests, fully offline (network disabled).
  • Fail-loud data integrity: append-only ledgers with rotating backups, checksum-verified map files, and crash-safe idempotent daily jobs. If something corrupts, it's built to halt loudly instead of quietly returning the wrong data.
  • A daily observability cockpit: one derived health metric plus ~9 traffic-light checks, delivered as a digest, specifically to catch silent pipeline failure, the worst kind.

Why it's here

It's the clearest example of a habit that runs through everything I build: let automation run, but engineer it so you find out the instant it's wrong. Separate the creative part from the deciding part, pre-commit the rules, inject the faults yourself, and make silence impossible.

← All work