Build a crypto-options engine on an existing engineering system.

Options OS is a specification-driven repository for building crypto-options trading engines with Claude Code or Codex. It combines reusable financial libraries, an options-native domain model, venue adapters, engine specifications, agent execution controls, and conformance tooling.

You define the trading system. Options OS translates that definition into engineering contracts, resolves the required framework components, controls implementation, and verifies the resulting engine against the system it claims to implement.

What the repository provides.

options-os/
├── .agents/                    shared agent capabilities
├── .claude/                    Claude Code integration
├── .codex/                     Codex integration
├── .docs/                      operational documentation
├── .legal/                     commercial licence and notices
├── .vscode/                    editor configuration
├── execution/
│   ├── backlog/
│   ├── done/
│   ├── in-work/
│   ├── queued/
│   ├── support/
│   ├── EXECUTION_PROTOCOL.md
│   └── README.md
├── packages/
│   ├── adapter-deribit/
│   ├── libs/
│   └── ruff.toml
├── specifications/
│   ├── framework/
│   ├── libs/
│   └── README.md
├── tools/
│   ├── codemap/
│   ├── controls/
│   ├── flatten/
│   ├── lint/
│   ├── probes/
│   ├── scraper/
│   └── tree/
├── AGENTS.md
├── CLAUDE.md
├── INVARIANTS.md
├── PROFILE.md
├── Makefile
└── README.md

Reusable options-system capabilities.

The framework is implemented as separate libraries with explicit contracts and dependency boundaries. Libraries establish facts, plans, and verdicts. They do not own strategy policy.

Financial meaning is separated from effects.

Options OS structures reusable code through a progression from domain vocabulary to controlled interaction with the outside world.

primitives → enums → objects → algebra + laws
                              ↓
                         morphisms
                              ↓
                         pipelines
                              ↓
                          programs
                              ↓
                        interpreter
                              ↓
                          effects
                              ↓
                     runtime → world

Effects begin at the interpreter boundary. Pricing, portfolio, risk, and order meaning remain testable without opening a network connection, reading a database, or importing a venue client.

Trading intent becomes an engineering contract.

The entry point is a structured trading-system definition. It records the strategy thesis, market observations, inputs, setup and signal rules, candidate construction, entries, exits, portfolio allocation, risk, hedging, order lifecycle, reconciliation, recovery, and runtime modes.

The accepted definition is translated into three coordinated engine contracts:

Venue specifications separately own venue-native capabilities and behaviour. Library specifications own reusable financial meaning. Assembly bindings resolve the engine contract against selected libraries, venues, and infrastructure without redefining them.

trading definition
    ↓
engine contracts
    ↓
venue + library contracts
    ↓
assembly + bindings
    ↓
resolved contract map

The repository controls how agents change the system.

Claude Code and Codex consume the same engineering authority, shared agent capabilities, and completion rules. The agent does not reconstruct the architecture from code or decide what “done” means while implementing.

Repository workflows

• build-system
• change-system
• correct-defect
• certify-trading-build
• release-readiness

Work is implemented as the smallest dependency-closed causal cut. Every affected consumer, contract, and verification surface is updated within the same cut.

Prove the complete engine lifecycle.

Deribit market data
    ↓
normalized option instruments
    ↓
strategy facts and decision
    ↓
canonical order program
    ↓
adapter interpretation
    ↓
orders, fills and positions
    ↓
portfolio, PnL and risk
    ↓
exit or settlement
    ↓
restart and reconciliation

The first engine should use one venue, one underlying, one book, and one explicit operating policy. This exercises the actual seams where trading engines fail: financial identity, order state, partial fills, fees, position adoption, risk, settlement, restart, and venue reconciliation.

Additional venues and strategies come after this spine is coherent.

Compare accepted meaning with implemented behaviour.

specifications
    ↓
types + schemas
    ↓
invariants + architecture rules
    ↓
unit + property tests
    ↓
integration + contract tests
    ↓
lifecycle + acceptance scenarios
    ↓
static analysis + quality gates
    ↓
runtime evidence
    ↓
conformance

Options OS generates distinct evidence artifacts for distinct questions:

The exact procedures ship with the repository.

The private documentation turns the public architecture into an executable workflow:

• Verified installation and package provisioning
• Complete repository map and dependency graph
• Field-by-field trading-system definition
• Specification acceptance and assembly procedures
• Vertical-spine implementation map
• Copyable Claude Code and Codex directives
• Executable verification and conformance commands
• Venue probes, troubleshooting, security, and support

The public documentation exposes the architecture and construction model. The licensed repository contains the authoritative specifications, schemas, controls, generators, and operating procedures.

Repository access: bella@leanos.tech

Access and pricing →