MACH-1 Optimizer

• 

  Initial Project

Inspiration

Every "AI trading agent" pitch we've seen makes the same promise: smarter signals, better predictions, more automation. But the question that actually keeps a CTO up at night isn't "is the agent smart?" — it's "what happens the one time it's wrong with real money?"

Operations Research has spent seventy years answering that exact question for airlines, factories, and supply chains: don't just predict, optimize under constraints. Nobody was bringing that discipline to AI trading agents. Everyone was building the agent. Nobody was building the mathematical brake that makes the agent safe to deploy.

So we didn't build another signal generator. We built the layer that sits between any financial AI agent and real capital — and we used portfolio rebalancing as the proof case. The agent proposes. The math corrects. The ledger proves it happened.

What it does

MACH-1 Optimizer takes a proposed portfolio allocation — from a human, or from any upstream AI agent — and passes it through a real linear programming solver (scipy.linprog, HiGHS) instead of a simple accept/reject filter.

If the proposal violates a hard constraint (per-asset concentration cap, sector exposure limit, minimum cash floor), the system doesn't just block it and stop. It solves for the closest feasible allocation — minimizing the L1 distance between what was requested and what's actually allowed — and returns that correction in under 20 milliseconds.

Every decision is written to an append-only ledger: what was requested, which constraints fired, what was corrected, and how much capital moved. Nothing is a black box. Every rejection comes with math, not just a red X.

How we built it

• Solver core — scipy.optimize.linprog (HiGHS backend) formulated as an L1-minimization problem: introduce slack variables so x − u + v = requested, minimize Σ(u+v), subject to linear inequality constraints (per-asset cap, sector cap, cash floor).
• API layer — Flask, three endpoints: /optimize (runs the solver, writes to the ledger), /ledger (append-only audit trail), /config (current constraint set, YAML-driven — the same configuration pattern from our existing security-harness product line).
• Frontend — a live constraint gate that animates green/red per rule, then renders the before/after allocation as paired bars per asset, with a plain-dollar headline metric ("$X reallocated") instead of an abstract percentage.
• Ledger — SQLite, append-only, one row per decision. No update, no delete path exposed — the audit trail can only grow.

Challenges we ran into

The honest one: our first instinct was a rules-only gate — accept or reject, no correction. A reviewer pushed back hard that pure if/else threshold checks aren't Operations Research, they're compliance middleware with an AI wrapper. That forced the real pivot: replace rejection with optimization. Formulating the L1-distance minimization correctly (the u/v slack-variable trick to linearize an absolute value) took real care to get the constraint matrix right — a wrong sign on A_ub silently returns an infeasible or nonsensical correction, and it's easy to not notice until the numbers are checked against known cases by hand.

Accomplishments we're proud of

A real solver, not a simulation of one. The correction the judges see on screen is the literal output of an LP relaxation, not a canned demo — feed it a different violating allocation and it computes a different, genuinely optimal correction. We also kept the demo honest: v0.1 clamps capital rather than fully redeploying what's freed by a cut position, and we say so, with the fix scoped for v0.2 (lexicographic secondary objective). We'd rather show a known limitation than hide one.

What we learned

That "Operations Research" is a specific, checkable claim — not a vibe. A judge who knows the field will look past the dashboard straight at the constraint matrix, and the only way to survive that is to actually have one. We also learned that a good gate isn't the one that says no the loudest — it's the one that says "here's the closest yes."

What's next for MACH-1 Optimizer

• Lexicographic secondary objective: after minimizing correction distance, maximize capital deployment within the feasible region.
• Turnover and drawdown-regime constraints (tighten caps automatically when portfolio drawdown crosses a threshold).
• A pip-installable package (pip install mach1-optimizer) with the same YAML-driven constraint pattern as our existing agent-security harness — so any robo-advisor or family office can drop in their own risk limits without touching code.

Built With

• flask
• highs
• html/css
• javascript
• linear-programming
• numpy
• python
• scipy
• sqlite