Systems our founder engineered, shown as they stand today. None of this is client work. Where something is unfinished, we say so.
Founding engineer, GreenRoom Technologies, Inc.V2 in private beta
Moving a live product to its new version without losing anyone's account or history.
GreenRoom is a professional network for the music industry. Its first version is still the live product. The second version is a rebuild, and the hard part is moving every existing user across safely.
Version 1, live today
Artists book paid consultations with music professionals.
Accounts, sign-ins, payments and booking history live here.
the move
Version 2, private beta
An assistant that finds the right person for a brief, and shows why.
It answers from profiles, credits and who knows whom, which needed a new database.
Asked: “We need a producer who's made music for games, has a clean catalog, and is open to brand work this quarter. Who's the right fit?”
Version 2 answering a question: it names its matches and shows the credits and criteria behind the first. Seeded demo data: the person and credits shown are test records.
Safe to run twiceRunning the move a second time changes nothing, so a failed run can simply be repeated.
Can be undoneEvery batch records exactly what it wrote, so it can be taken back out.
Checked both waysA rehearsal first, then checks that the new records match the old ones field by field.
The constraint
Version 1 holds people's accounts, payments and booking history. A rebuild could not lose a user, a completed consultation, or a working login.
What we built
A new database organised around people, their work and how they are connected; a transfer that is safe to repeat; and a sign-in bridge so existing users keep their passwords.
Where it stands
The move is built and tested. The final switch has not happened yet, so version 1 is still the live product. Records that conflicted were held back for review, not loaded.
Under the hood
V1, still live
AWS serverlessLambda and API Gateway
DynamoDBidentity, payments, bookings
Firebase Authexisting passwords
Migration path
Deterministic loadsuuid5 IDs; re-runs are no-ops
Checks around every loaddry run, verify suite, parity audit
Reconciliation gateconflicts held back; manifest rollback
Credential bridgeV2 account created at first sign-in
LLM discoveryanswers from structured profile evidence
For engineers: the path data takes from version 1 to version 2, as built. Version 1 is frozen read-only during each load. The final switch is pending.
QuantMechanix
Independent research toolPaper trades only
Making a trading research pipeline resumable, explainable, and auditable.
A strategy-research and decision-support tool, not a claim of investment performance. It runs on paper by default.
The research view for a single symbol.Exact gate outcomes across two policy versions.One completed run: 104 symbols in, 2 setups out.
ResumablePostgres checkpoints, so a failed stage restarts where it stopped.
LoggedEvery candidate is recorded against named policy gates, with exact pass and fail counts.
ScoredModel predictions settle against market prices as paper trades and are scored.
The constraint
Market-data limits, partial failures and long-running analysis made an all-or-nothing batch unreliable and hard to audit.
The engineering move
Postgres checkpoints, Redis rate limiting, scheduled ingestion, prediction logging, and automated end-of-day settlement of outcomes.
The risk control
Each candidate is checked on the server against named policy gates and every result is recorded. A model without a track record stays labelled unproven.
The pipeline runs in order, one step at a time. Point at a step, or tap it, to read what it does.
Universe scan
A fixed list of symbols, cut down before any model runs.
Illustration of how this step works, not live data.
The universe is a fixed list of 104 symbols.
The scan is scheduled for weekday mornings, Eastern time.
A first cut filters on bid-ask spread, relative volume, IV rank and upcoming earnings.
Rate-limited ingestion
One market-data API, paced so a slow or failed call never sinks the run.
Illustration of how this step works, not live data.
Quotes, daily price history, option chains and earnings dates come from one brokerage API.
Every call passes through a Redis sliding window: 120 calls a minute, with a local fallback if Redis is down, and backoff when the API pushes back.
A symbol whose data fails is recorded as a gap and the scan continues.
IV rank is read from stored daily snapshots, not from the live chain.
Postgres checkpoints
Each tier saves its result, so a run can stop and pick up again.
Illustration of how this step works, not live data.
Each tier writes its result to Postgres as the run moves through its statuses.
A failed or partial run restarts at the first tier that has no saved result.
Every gate evaluation is stored as its own row: PASS, FAIL or UNKNOWN.
Each model prediction is logged with its direction, confidence and price, then marked right or wrong once the outcome is known.
Model ensemble
Fourteen models in the registry as of 30 September 2026: direction models, and volatility and risk models.
Illustration of how this step works, not live data.
Direction models include a hidden Markov regime model, mean reversion, jump diffusion, Hawkes clustering, moving-average trend, Donchian breakout and momentum.
Ornstein-Uhlenbeck, Heston, GARCH, entropy and copula models describe volatility and risk.
Votes are grouped into families, weighted by confidence squared, and reduced when models disagree.
A model with fewer than 30 resolved predictions is labelled UNPROVEN, in the code and on screen.
Policy gates
Contract checks on the option chain, then a pre-trade checklist that records every verdict.
Illustration of how this step works, not live data.
A contract must have open interest of at least 500, a spread of at most 12%, a delta between 0.20 and 0.65, 5 to 45 days to expiry, and a premium inside a fixed risk budget.
Volatility edge is the forecast move minus the implied move minus a cost buffer. A candidate needs a positive edge after costs.
The pre-trade checklist has 29 checks. Nine are always marked blocking, among them earnings safety, settlement, position sizing and drawdown.
By default the checklist runs in audit mode: it records what it would have blocked. Enforcing it is a setting.
Review queue
A short list for a person to decide, then scored against what happened.
Illustration of how this step works, not live data.
At most ten setups reach the queue, ranked.
Outcomes are settled by rule as paper trades: the option price is reconstructed with a pricing model and checked against a target and a stop.
Models are scored by Brier score, direction accuracy and information coefficient.
Research lab
Tools kept outside the daily decision path.
Illustration of how this step works, not live data.
Cointegration: an Engle-Granger test at p below 0.05, a least-squares hedge ratio, and the half-life and z-score of the spread.
Options: an implied-volatility surface across strikes and expirations, and a pricing and greeks workbench.
Pattern recognition across 18 candlestick types, and a walk-forward backtesting engine.
Before the firm
Our founder's work as an employee at Bloomberg and Assured Guaranty. It is shown as experience, not as the firm's clients, and neither company endorses Irrational Solution.
Bloomberg
Software engineer, Data TechnologiesEmployee
Moving high-volume financial data without slowing the research built on top of it.
6,500+companies in the ESG data migration
45%lower query latency after the migration
Globalfinancial data acquisition and delivery
ESG company data
FromESG data on 6,500+ companies
BuiltA Kafka migration
ResultSame data contracts, 45% lower query latency
Bank filings
FromBank filings (FDIC Y-9)
BuiltNormalized ingestion pipelines
Used byCredit analysis in the Terminal
The work
A Kafka migration for ESG company data used in quantitative research, and normalized bank-filing pipelines for Terminal credit analysis.
The constraint
Data contracts and downstream research had to keep working while the acquisition and processing systems changed underneath them.
The result
Query latency fell by 45 percent while the data kept serving workflows built around thousands of companies.
Data engineerEmployee
Turning data onboarding and model calibration from bottlenecks into repeatable systems.
85%faster onboarding of a new data source
100M+parameter search space, distributed
2 hrscalibration runtime after the redesign
Vendor data
FromBloomberg, Moody's, ICE, MMD
BuiltA Snowflake warehouse on Data Vault 2.0
Used byAnalysts, through firm-wide credit datasets
Model calibration
From100M+ parameter combinations
BuiltA distributed grid search on AWS ECS
ResultAbout two hours, down from days or weeks
The system
The data pipeline into a Snowflake warehouse modelled as Data Vault 2.0, bringing in vendor data from Bloomberg, Moody's, ICE and MMD (Refinitiv). A self-service framework automated schema creation, access controls and ingestion templates for new sources.
The scale problem
A regression parameter optimization for catastrophe-risk modelling, across a search space of more than 100 million combinations. A Python, Kafka and AWS ECS system distributed a grid search which had run locally for days or weeks.
The result
Analysts got repeatable access to firm-wide credit datasets, and calibration finished in about two hours. The work involved licensed vendor feeds and sensitive financial data throughout.
How we build
Work is written up as a brief first. A coding agent carries out the brief in an isolated copy of the repository, and a separate reviewer checks the change against the brief. On an engagement, you can see the brief, the change and the review.
Start with fifteen minutes.
A free call to see whether the triage fits your system. No preparation needed.
