Selected engineering work / Case study
Apex
A quantitative research platform that collects real market evidence, evaluates strategies point-in-time and preserves a reproducible record of every decision.
I designed and built Apex end to end as a local-first system. Scheduled workers collect public market data into durable PostgreSQL evidence, strategies are evaluated against only what was known at the time, and qualifying strategies are exercised in PAPER trials with risk controls, double-entry accounting and an Operator Console.
The production system is private. The demo is a static, read-only bundle on synthetic data, and a curated single-commit source snapshot is public.
- Core
- Python 3.12, mypy --strict
- Evidence
- PostgreSQL, 118 Alembic migrations
- Operation
- systemd timers, Docker Compose
- Interface
- React + TypeScript console
- Integrity
- Decimal money, double-entry ledger
Project summary
- What it is
- A research platform that observes real markets on a schedule, retains the evidence, and tests strategies against it without hindsight.
- What I built
- All of it: collection workers, the evidence schema, the evaluation and decision pipeline, risk controls, the ledger, recovery tooling and the Operator Console.
- Why it is interesting
- Integrity is enforced structurally: immutable evidence in the database, point-in-time reads, deterministic identities and a risk kernel that policy cannot bypass.
- Where it stands
- Operating continuously on one machine: collecting real market data and running research and PAPER trials.
01 · What Apex doesObserve, evaluate, decide, and keep the record.
These are the capabilities that operate today, each backed by persisted evidence in the system.
Collects real public market data
Coinbase crypto products, candles and one-minute top-of-book quotes, Kalshi prediction-market data, and SEC and Nasdaq Trader security directories, including about 1.4 million option contract references. Real Alpaca options-chain quotes have been captured and retained since August 2026. Options capture is a scheduled, credential-gated task in the operating cycle; an attempt that fails does not affect the other tasks.
Runs unattended on schedules
A five-minute operating cycle and a separate one-minute observer run as systemd timers. Each firing is one bounded, idempotent pass under a PostgreSQL advisory-lock lease.
Keeps durable, provenance-tracked evidence
Observations become content-hashed, append-only records, classified by how they were obtained (public, historical, sandbox, PAPER or fixture), so synthetic data can never stand in for real data.
Evaluates strategies point-in-time
A strategy sees only evidence available before its cutoff. Evaluations, promotions and the exact strategy version behind each trial are retained, so a result can be reproduced and explained.
Runs experiments and counterfactuals
Every eligibility or mandate decision, including each rejection, becomes a permanent record. Later market facts are attached to it as follow-up evidence for human research review. Nothing retrains automatically.
Proposes, allocates and applies risk controls
Strategies propose, an allocator sizes the proposal under campaign policy, and a risk kernel accepts or rejects it on freshness and exposure checks that configuration cannot switch off.
Runs PAPER trials with real accounting
Trials execute against internal PAPER ledgers or a broker sandbox, with fee-aware double-entry accounting in exact decimals and closure that survives a crash and resumes.
Protects itself at startup and recovers
Workers refuse to start on a mismatched schema, fail closed on missing credentials, and reconcile ledger state. After outages, evidence gaps are recorded and classified as recoverable or irrecoverable.
Presents it in an Operator Console
A React console covers opportunities, the decision ledger, follow-up, portfolio and mandate, allocation and PAPER operations. A static, read-only build of it on synthetic data is the public demo.
02 · Why it is technically interestingThe hard part is making the record impossible to quietly change.
A research system is only as credible as its history. Apex enforces that in the database and the domain model rather than by convention: immutability triggers on the evidence tables, content-addressed identifiers so a replay reproduces the same record, and explicit as_of bounds so a calculation cannot see the future.
It also keeps what it rejected, and it labels what it could not capture. Backfilled evidence is marked as such and cannot pass as live observation, and some gaps are recorded as irrecoverable because a provider has no historical record to reproduce.
03 · What I personally builtOne engineer, the whole stack.
I designed the architecture and implemented each layer, from the host timers to the browser console.
- Collection and operations. The operating-cycle and live-observer workers, systemd units, lease and heartbeat handling, and per-day idempotent scheduling.
- Evidence and persistence. The PostgreSQL schema and migrations, database-enforced immutability, content-hash identity, and least-privilege database roles for the workers.
- Research and decisions. Point-in-time evaluation, strategy versioning and provenance, the counterfactual and follow-up loop, shared opportunities and the investment mandate.
- Execution and accounting. The allocator, risk kernel, PAPER trial lifecycle, and the double-entry ledger with reconciliation.
- Safety and recovery. The schema-compatibility guard, credential fail-closed behavior, and evidence-gap classification and recovery.
- Interface and verification. The React and TypeScript Operator Console, the static demo generator, and isolated per-checkout test environments.
04 · How the subsystems fit togetherOne evidence store, four stages of decision.
Collection feeds retained evidence. Every decision then follows the same auditable path, rejections included.
-
01Evidence
Point-in-time inputs
A record is visible only if it was available before the decision cutoff. Settlement data cannot leak backward.
available_at ≤ cutoff -
02Proposal
Strategy, then allocation
A strategy proposes; an allocator converts normalized risk into a quantity under campaign policy.
NO_PROPOSAL is terminal -
03Risk kernel
Non-bypassable invariants
Authorization-time freshness and exposure checks accept or reject. Configurable policy cannot disable them.
stale data → rejected -
04Ledger
Execution and accounting
Immutable execution events, atomic reservations, and a double-entry ledger as the sole financial authority.
Decimal, never float
Drawn from Apex’s authority and operating-model documentation. The synthetic demo has no connection to the collection above it.
Layers, from collection to authority
-
Real · runningCollection
Unattended capture of public market data, retained as durable evidence.
-
Real data · researchEvidence and experiments
Strategies, experiments and counterfactuals run against retained real observations.
-
Simulated · PAPERTrials
Execution logic with simulated money on internal ledgers, plus one external broker’s own sandbox endpoint, under campaign limits.
-
Synthetic · publicThe demo
/apex/demo/ is a static, read-only snapshot generated from Apex’s own fixture services and a throwaway database.
-
Not enabledLive authority
Research records carry
authority = "NONE", the default mandate holds zero capital and the live execution gate is never armed in operation.
05 · Console and public demoThe working interface, and a demo you can open.
Both captures are of the static synthetic demo, which is labelled as such in every view and makes no network requests beyond its own files.
Step through it yourself
Open the demo to walk all eight outcomes. It runs entirely from its own static files, and its data came from a throwaway database seeded only by Apex’s fixture services.
06 · Reliability, validation and challengesBuilt to run unattended, and corrected when it failed.
The operational problems the system’s own records show being found, fixed and designed out.
Fails closed on a schema mismatch
After application code reached a worker hours before its migration, every firing crashed deep in a SQL error. Workers now refuse to dispatch unless the database revision exactly matches the code, with an explicit error.
Ledger reconciliation caught up with the ledger
The first real PAPER trial close exposed a SELL journal that recognized a fee twice while reconciliation still reported clean. I fixed the journal, derived consideration from fills rather than journals, and made reconciliation compare ledger balances to account economics.
Honest about outages
After host outages, recoverable gaps (such as closed-session daily bars) are backfilled and labelled as recovered. Irrecoverable ones, such as order books and live observations, are recorded as such, and database checks stop backfill from passing as live evidence.
Hardened database access
Workers run as a least-privilege database role without superuser or DDL rights, with no tracked default credentials, and a maintenance window was rehearsed on a restored backup before production was touched.
Reproducible by construction
Deterministic, content-addressed identities let a retried cycle reuse evidence instead of duplicating it, and the eight demo outcomes print byte-identical reports whose hashes are pinned by tests.
Isolated verification
Persistence tests run against a per-checkout Docker project, port and database, never the live stack. As recorded on 2026-10-14, the offline and real-PostgreSQL suites pass with strict typing and linting clean.
07 · Boundaries, maturity and next stepsA research platform, not a trading product.
- Real data, simulated capital. Apex collects and processes real market observations. PAPER trials use simulated or sandbox capital, and no code path places a live order.
- Research outcomes. Most strategy research so far has been rejected or exploratory, and PAPER results are engineering evidence rather than a performance claim.
- Public demo. Static, read-only and synthetic. The production system, its history and its infrastructure remain private.
- Maturity. It runs on one local machine and only while that host is awake, and historical equity universes are survivorship-limited.
- Open items. Apex’s own records list more repeated PAPER outcomes per strategy and a strategy-driven Kalshi PAPER path, which does not exist yet, as the next engineering steps.
Python 3.12 · mypy --strict · PostgreSQL · Alembic · SQLAlchemy · Docker Compose · Linux · systemd · React · TypeScript · Vite · double-entry ledger · property-based tests
Next: ArenaOps, a cloud backend that slept until someone needed it.