A proof-first execution airlock for autonomous options trading.
1. Watch the PPT Pitch Video (3 min) | 2. Watch the Live Tech Demo (1.5 min) | 3. Launch Live Demo Portal | 4. Explore Source Code
For judges: watch the short PPT pitch first for the plain-English story, then watch the live tech demo to see the refusal proof.
PPT Pitch / Presentation Video |
Live Tech Demo Video |
TL;DR: An AI may suggest an options trade, but it never gets a direct path to the broker. 13forge rebuilds the order from quoted market data, runs seven deterministic safety gates, and refuses the trade if it breaches hard limits.
flowchart LR
A[AI suggests a trade] --> B[13forge checks it]
B -->|Unsafe: $2,525 > $2,000| C[REFUSED]
C --> D[Alpaca is never contacted]
B -->|All gates pass| E[Structured order may continue]
E --> F[Alpaca]
style B fill:#20292d,color:#fff,stroke:#43b96b,stroke-width:3px
style C fill:#8f2d35,color:#fff,stroke:#ff8b8b,stroke-width:2px
style D fill:#f5f7f5,color:#20292d
style F fill:#43b96b,color:#102018
This is the product in one sentence: creative reasoning is allowed upstream; deterministic permission is required downstream.
Generative models are phenomenal at discovering ideas, but they are not a safe place to put final authority over strikes, risk, or broker payloads. 13forge gives the model a narrow job and gives the execution path hard boundaries:
- 🧠 Smart Extraction: The model emits a constrained thesis, not a raw order.
- 🏗️ Deterministic Assembly: Strategy code uses real
ChainQuotedata to build the spread. - 🛑 Strict Validation: Seven refuse-by-default checks run before any dispatch occurs.
- 🔐 Bounded Dispatch: Only a checked, mathematically bounded result can reach the Alpaca CLI.
The experience is designed to make a technical safety property feel obvious: the system proves what it refused, why it refused it, and what did not happen next.
The deployed portal is a guided, static replay backed by repository evidence. It does not contain credentials, live balances, or a live order button.
| Step | What you will see | Why it matters |
|---|---|---|
| 1 | An oversized iron condor proposal | A concrete failure, not an abstract architecture diagram |
| 2 | Seven checks run in sequence | Safety is a holistic path, not a single marketing claim |
| 3 | $2,525 maximum loss vs $2,000 limit |
The refusal is perfectly transparent |
| 4 | DispatchRefusal::MaxLossVeto |
The human explanation maps directly to backend code |
| 5 | "Broker process not started" | The system proves the prevented side effect |
flowchart TD
A[Constrained S13 thesis] --> G1[01 Margin circuit breaker]
G1 --> G2[02 Position-state check]
G2 --> G3[03 AI permission check]
G3 --> G4[04 Market stability check]
G4 --> G5[05 Trade structure check]
G5 --> G6[06 Maximum-loss check]
G6 --> G7[07 Alpaca submission]
G1 -. refuse .-> R[Receipt + no broker process]
G2 -. refuse .-> R
G3 -. refuse .-> R
G4 -. refuse .-> R
G5 -. refuse .-> R
G6 -. refuse .-> R
style G1 fill:#20292d,color:#fff
style G2 fill:#20292d,color:#fff
style G3 fill:#20292d,color:#fff
style G4 fill:#20292d,color:#fff
style G5 fill:#20292d,color:#fff
style G6 fill:#20292d,color:#fff
style G7 fill:#43b96b,color:#102018
style R fill:#8f2d35,color:#fff
The current path checks GovernorVent first, before the other refusal paths. The public receipt records 159/159 tests: 110 forge-gate + 36 forge-daemon + 13 example tests for the 2026-09-02-night-governor session.
We use a strict vocabulary so the README does not make a stronger claim than the code or receipt supports.
|
Governor VENT blocks dispatch before the other checks. Backed by the |
Position-state, oracle, market, geometry, and max-loss checks control dispatch. Backed by dispatch code and refusal tests. |
|
A $2,525 maximum loss exceeds the $2,000 ceiling. Proven by the recorded oversized-condor refusal case. |
Credit prices serialize as negative Alpaca mleg limit prices. Backed by the |
|
Strategy uses quoted strikes and pulls wings inside the cap. Backed by robust strategy tests. |
Merkle seal, Fredholm residue, and API pacer. Built components, not presented as live gates. |
flowchart LR
A[Dual oracle: Bull / Bear] --> B[Constrained S13 thesis]
B --> C{Rust gate lattice}
C -->|Refuse| D[Receipt: reason + zero broker call]
C -->|Pass| E[Build from ChainQuote data]
E --> F[Alpaca CLI via stdin]
style C fill:#20292d,color:#fff,stroke:#43b96b,stroke-width:3px
style D fill:#8f2d35,color:#fff
style E fill:#43b96b,color:#102018
The model is useful because it proposes a thesis. The Rust path is trusted because it owns permission, risk, structure, and serialization boundaries.
Best-practice inference, not an event-specific official rubric: hackathon judges tend to reward a focused problem, a working public demo, meaningful technology use, originality, and a clear explanation. This README makes each visible in the same order a judge experiences the submission:
|
AI-generated trading ideas need a deterministic safety boundary. |
One replay, one refusal, one visible dollar comparison. |
|
Rust gates own the final permission path; AI does not write orders. |
Code references, refusal receipts, and a reproducible test session. |
|
The system proves a dangerous order never reached the broker. |
|
The psychology is simple: reduce cognitive load, show a concrete consequence, and make trust visible through a receipt. A judge should feel oriented before they feel impressed.
The proof portal is plain static HTML and can be opened directly or served from the repository root. The Rust workspace requires a local Rust toolchain.
# Set Alpaca paper credentials only in the current shell.
export APCA_API_KEY_ID="your_key_id"
export APCA_API_SECRET_KEY="your_secret_key"
# Run the current workspace verification.
cargo test -p forge-gate -p forge-daemon
# Dry-run strategy selection; no order is placed.
cargo run --example sim_today -p forge-daemon
# Read-only account smoke test.
cargo run --example live_smoke -p forge-daemonThis submission is maintained from a collaborator lane: frontend demo portal, README/docs, deployment preview, and presentation assets. The Rust engine, credentials, live trading behavior, and trading receipts remain owned by the core repository maintainers. Frontend copy mirrors backend receipts without editing backend code.
- Watch PPT Pitch / Presentation Video (3 Minutes)
- Watch Technical Demo (1.5 Minutes)
- Launch Live Demo Portal
- Explore GitHub Repository