Autonomous AI systems your risk committee will actually approve.

<h2>Building an autonomous research organisation</h2> AAQuant is an AI-native quant fund. Birchblue built its operating system: the agent orchestration, the governance layer, the statistical gate stack, and the cost controls that let it run unattended. This page covers the engineering. For the fund itself — strategy, data moat, and investor information — see <a href="https://aaquant.ai" target="_blank" rel="noopener">aaquant.ai</a>. <h2>The engineering problem</h2> Quantitative research is human-serial and therefore expensive. A researcher takes a hypothesis, builds it, backtests it, argues for it, and usually discovers it has no edge — after weeks of work. The question was whether that discovery loop could be delegated to a governed agent workforce without lowering the statistical bar. <h2>What we built</h2> <ul> <li><strong>A six-stage governed state machine</strong> carrying every hypothesis from ideation through research, development, validation, and paper deployment — unattended.</li> <li><strong>Tiered model routing across five classes.</strong> Every feature declares the model class its work requires and the runtime enforces it. Mismatches between intended and actual model are flagged automatically.</li> <li><strong>A tamper-evident audit chain.</strong> Every state transition, gate verdict, and model call written to an HMAC-SHA256 chain with model, tokens, cost, and prompt hash.</li> <li><strong>A statistical gate stack</strong> — deflated-Sharpe critic at 90% confidence, correlation gate, four-layer decay detection with false-kill guards.</li> <li><strong>Self-healing operations.</strong> Supervisor daemon with per-step retry, dead-letter, and escalation; liveness probes; daily machine-written postmortems.</li> </ul> <h2>Operating results</h2> <table> <tbody> <tr> <td><strong>Research cost per terminal verdict</strong></td> <td><strong>$0.88</strong> — against analyst-months at $10k–100k+</td> </tr> <tr> <td><strong>Ideation to verdict, median</strong></td> <td><strong>3.66 days</strong> — against 3–12 months per strategy</td> </tr> <tr> <td>Unattended tick success, 30 days</td> <td>98.4%</td> </tr> <tr> <td>Failures resolved without a human</td> <td>97.8% of 1,645</td> </tr> <tr> <td>Model calls, individually ledgered</td> <td>13,228 across 29 governed features</td> </tr> <tr> <td>State transitions, all audited</td> <td>5,041</td> </tr> </tbody> </table> <em>These are pipeline-operations figures. AAQuant is in paper trading and has no live track record; Birchblue publishes its operating metrics, not performance claims.</em> <h2>Why it matters to your project</h2> Quant research was chosen as the proving ground because the feedback is unforgiving and the compliance bar is real. The lifecycle itself is domain-independent — anywhere agents can be staffed, verified, and audited like an engineering team, the same governance applies. That is what Birchblue installs: the Agentic Development Lifecycle, explicit decision rights, tamper-evident audit trails, and hard cost ceilings. AAQuant is the evidence we run it ourselves first.

<h2>Burst Core Configurator: a framework migration under production load</h2> The Burst Core Configurator powers vehicle inventory search, model browsing, and ordering across Tesla's web and mobile platforms. This engagement covered its migration off end-of-life foundations onto a supported, hardened stack — without a functional regression and without downtime for the ordering path. <h2>The problem</h2> The application ran on Slim 3 with PHP 7. Both had reached end of life: Slim 3 was no longer maintained and PHP 7 long-term support had expired. That combination is a compounding liability — unpatched CVEs with no upstream fix path, dependencies that stop publishing compatible releases, and a migration cost that grows every quarter it is deferred. On a revenue-carrying ordering surface, it is not a deferrable problem. <h2>The work</h2> <ul> <li><strong>Framework and runtime migration.</strong> Slim 3 → Slim 4 and PHP 7 → PHP 8, taking the application onto supported security and performance baselines rather than a minimum-viable patch.</li> <li><strong>Container rebuild.</strong> Worked with the platform team to rebuild the Docker image against Slim 4 and PHP 8 requirements, including restoring image-processing extensions the new runtime needed.</li> <li><strong>Dependency remediation.</strong> Traced and resolved breakage in downstream packages — including the shared foundation library — that only surfaced once the runtime moved.</li> <li><strong>Endpoint-level verification.</strong> Built Postman collections and automated scripts covering every endpoint in the service, then ran them with QA and the owning engineers as the release gate. Nothing shipped on the assumption that a framework upgrade is behaviour-preserving.</li> </ul> <h2>Why Slim 4</h2> Slim 4 adopts PSR-7, PSR-15, and PSR-11 — standard HTTP messages, middleware, and container interfaces. In practice that means middleware and dependency wiring become portable rather than framework-specific, so the next migration is a smaller job than this one was. Paired with PHP 8's performance improvements, the service came out faster and materially cheaper to maintain. <h2>Outcome</h2> A revenue-carrying application moved off two end-of-life dependencies onto supported, standards-based foundations — verified endpoint by endpoint, with the security exposure closed and the next upgrade path made cheap by design. <em>This is the kind of work Birchblue takes on: load-bearing legacy systems where the migration has to be provably safe, not merely finished.</em>