# Multi-Exchange Delta-Neutral Constitution
<!--
Sync Impact Report
Version: 0.0.0 → 1.0.0
Modified principles: (template → Delta-Neutral First, Deterministic Market Data, Capital Protection, Transparent Observability, Tested Execution Paths)
Added sections: Operational Constraints, Workflow & Quality Gates, Governance
Removed sections: Placeholder Section 2, Placeholder Section 3
Templates requiring updates:
- ✅ .specify/templates/plan-template.md (version reference)
- ✅ .specify/templates/spec-template.md (no change required)
- ✅ .specify/templates/tasks-template.md (no change required)
- ✅ .specify/templates/agent-file-template.md (no change required)
Follow-up TODOs: none
-->

## Core Principles

### I. Delta-Neutral First
All strategies MUST target aggregate delta ≈ 0 across every connected exchange and account pair at all times. Net exposure per asset MUST stay within ±0.0005 BTC-equivalent unless a mitigation order is already in-flight and logged. Rebalancing MUST occur immediately when utilization or exposure breaches configured thresholds.

### II. Deterministic Market Data Intake
The system MUST maintain continuous, low-latency orderbook access per venue (WebSocket primary, HTTP fallback within 5 s). Orderbook snapshots MUST be validated for monotonic bids/asks and depth freshness < 2 s. Any degraded feed MUST automatically trigger fallback plus alerting before new trades execute.

### III. Capital Protection & Risk Controls
Every account MUST enforce configurable position, leverage, and drawdown ceilings. Emergency stop-loss paths MUST cancel or hedge residual exposure within 30 s of trigger. All order flows MUST carry idempotent identifiers and rollback plans to prevent orphaned exposure during partial failures.

### IV. Transparent Observability & Audit
Execution, hedging, and cleanup services MUST emit structured logs, metrics, and health signals per account and exchange. Order intent, fills, cancellations, and balance snapshots MUST be traceable end-to-end with correlated IDs. Historical actions MUST remain reproducible via persisted configs and replayable event logs.

### V. Tested Execution Paths
Every new trading or hedging flow MUST ship with dry-run simulations and dual-account integration tests before live enablement. Regression suites MUST cover order placement, cancellation, rebalance loops, and fallback transitions. No code may move to production without automated verification demonstrating profit-after-fee feasibility under expected spreads.

## Operational Constraints
The platform MUST sustain high-frequency signal evaluation (≤8 s loop) while keeping per-iteration compute under configured budgets. Network access MUST route through approved proxies when required without breaking latency commitments. Sensitive credentials MUST stay encrypted at rest, and rotation procedures MUST be rehearsed quarterly. Data retention for trading logs MUST satisfy minimum 90-day replay.

## Workflow & Quality Gates
Planning artifacts MUST explicitly map features to these principles before development starts. Specs MUST declare exposure limits, data sources, and testing matrices. Plans and tasks MUST schedule TDD coverage for hedging, order cleanup, and observability improvements. Pull requests MUST include evidence (logs, test output, or dashboards) showing ongoing compliance with Principles I–V. Any deviation demands documented mitigation prior to merge.

## Governance
This constitution supersedes prior process guidance for the trading stack. Amendments require maintainer consensus, documentation of impact on safeguards, and updates to dependent templates. Versioning follows SemVer: MAJOR for principle removals/incompatible governance, MINOR for new principles or significant scope increases, PATCH for clarifications. Compliance reviews MUST occur at least monthly, examining exposure reports, health alerts, and test coverage deltas. Drifts MUST be recorded with remediation owners and timelines.

**Version**: 1.0.0 | **Ratified**: 2025-09-27 | **Last Amended**: 2025-09-27