Treasury Raid: The Living Runway

A playable, adversarial corporate-liquidity twin that finds the smallest plausible chain that can break a company—then lets teams build and verify defenses in an open 3D world.

Comment

Inspiration

Corporate cash crises are often timing failures disguised by aggregation. An invoice may be valid but late, a processor reserve may lock cash, a covenant test may freeze a revolver, and payroll may settle before the weekly spreadsheet ever looks negative.

We asked a different question: what if treasury risk could be explored like a city, attacked like a game, and audited like a ledger?

Treasury Raid is not a 13-week forecast wrapped in game graphics. It is a playable, adversarial corporate-liquidity digital twin built around a new mechanic we call Minimum Viable Bankruptcy (MVB): search for the smallest plausible shock chain that reaches a hard failure, prove every shock in that chain is necessary, and then challenge the player to close the path with a cheaper, bounded defense.

What it does

The player enters Treasury District as a crisis controller. Every world object has one financial meaning:

  • Invoice crates are receivable promises; their size is amount, their clock is collection timing, and their color is payment risk.
  • Aqua canals are settled, unrestricted cash.
  • Purple tanks are processor reserves and other restricted cash.
  • The covenant bank and drawbridge represent borrowing eligibility and revolver access.
  • Numbered roads encode payment priority.
  • Payroll homes represent real people and a hard Day 28 obligation.

The guided four-step game loop is:

  1. Scout the $880K Northstar receivable.
  2. Raid the company with the verified MVB chain.
  3. Counterplay by choosing collection timing, early credit draw, or reversible capex deferral.
  4. Contain the raid only if liquidity reaches payroll through every contractual gate.

The demo's shortest verified failure chain is: Northstar settles 12 days late → the processor reserve rises by $180K → the covenant test advances two days → borrowing availability freezes → payroll is short by $180K on Day 28.

How we built it

The product combines a semantic low-poly 3D world with a deterministic finance kernel:

  • A timestamped, event-sourced, double-entry ledger using integer minor units.
  • Independent legal-entity and currency boundaries with no silent cash netting.
  • Restricted-cash release rules and explicit settlement priority.
  • Borrowing-base and covenant evaluators that control draw eligibility.
  • A 91-day primary horizon plus a Day 92–365 shadow tail.
  • Seeded correlated Monte Carlo paths for survival, quantiles, freeze probability, and expected shortfall.
  • An exhaustive search over a disclosed finite attack space, followed by deletion tests that certify the displayed MVB chain is 1-minimal.
  • Immutable baseline, fortified, and efficient branches so simulations never overwrite the authoritative state.

The interface is built with TypeScript, React, Next.js, Three.js, and React Three Fiber. A fully playable 2D continuity twin appears if WebGL is unavailable, slow, or loses context, so the experience never freezes at a loading spinner.

How we used GPT-5.6 and Codex

GPT-5.6 is the Raid Director and causal strategy layer. The deterministic engine first produces ledger-authoritative metrics, shocks, constraints, and evidence. The server then calls the OpenAI Responses API with gpt-5.6-sol, high reasoning effort, and a strict Zod output schema. GPT-5.6 explains the smallest causal chain, surfaces the hidden assumption, and authors bounded actions with an owner, deadline, dependency, cash impact, and guardrail.

The model is deliberately not allowed to alter balances, journals, settlements, covenant results, or claim that proposed cash has arrived. If an API key is unavailable, the product labels and uses a deterministic fallback brief so the demo remains reproducible.

Codex was our engineering collaborator across the full stack: financial-domain modeling, invariant design, reverse-stress logic, interaction architecture, Three.js implementation, WebGL recovery, accessibility, visual iteration, automated tests, and adversarial review of unsupported financial claims.

Challenges we ran into

The hardest challenge was not rendering a 3D city; it was making every visual metaphor financially exact and instantly understandable. We repeatedly redesigned the world so that amount, time, probability, availability, credit eligibility, payment priority, entity boundary, and evidence could be read without a finance manual.

A second challenge was separating AI judgment from accounting authority. Natural-language advice is useful, but imaginary cash is dangerous. We therefore made the ledger and contract engines authoritative and constrained GPT-5.6 to explanation and proposal generation.

The third challenge was graceful degradation. We built explicit WebGL capability detection, a renderer deadline, context-loss recovery, manual retry, and a complete 2D gameplay fallback.

Accomplishments that we're proud of

  • A complete Scout → Raid → Counterplay → Contain loop inside the world.
  • A visually legible failure chain from receivable timing to restricted cash, covenant freeze, and payroll.
  • A deletion-tested MVB certificate instead of an opaque risk score.
  • Action branches that preserve auditability and distinguish simulated, proposed, and settled cash.
  • A finance kernel tested against unbalanced entries, duplicate settlements, currency/entity leakage, overdraft misuse, covenant edge cases, and horizon gaming.
  • An accessible light theme, a dark war-room theme, and a no-WebGL continuity mode.

What we learned

A useful financial twin needs more than factor coverage. It needs boundaries: accounting consistency, contract consistency, behavioral calibration, evidence lineage, and honest model limits. Game mechanics helped because they forced causality to become visible: the player cannot “win” by turning a dashboard number green; usable cash must physically cross every gate before the obligation settles.

What's next for Treasury Raid

Next we would connect bank, ERP, billing, payroll, CRM, and loan-document data; add industry and jurisdiction packs; calibrate counterparty behavior from promise-to-pay history; backtest forecast distributions; and run continuous reality sync so actual outcomes update the next raid.

The long-term vision is a multiplayer treasury control room where CFOs, operators, lenders, and advisors can attack the same evidence-backed twin, negotiate actions, and learn which defenses remain valid under a new adversary.

Responsible-use boundary

The current company and events are synthetic. Treasury Raid is decision support, not a bank balance, accounting opinion, lending decision, or guarantee of solvency. Contract formulas and legal restrictions require human verification before real-world use.

Built With

Share this project:

Updates