LLM Council Review: InertialEvent Design¶
Date: 2026-01-20 Reviewer: LLM Council (Chairman Synthesis) Documents Reviewed: Functional Requirements Spec (v1.0), ADR-001
Chairman's Synthesis¶
Based on the reviews from the available AI models (Grok, Gemini, Claude, and OpenAI), here is a synthesized evaluation of the InertialEvent specification and ADR.
General Consensus: The specification is technically sophisticated and demonstrates deep domain knowledge of the Polymarket/Kalshi ecosystems. The choice of Rust and the Actor Model is unanimously praised as the correct architectural path. However, the reviewers agree that the system is currently designed for the "Happy Path" and lacks critical safeguards regarding execution atomicity, regulatory compliance, and capital rebalancing.
1. Areas of Strong Agreement¶
Architectural Soundness¶
- Rust + Actor Model: All models validate ADR-001.1 (Rust Core) and ADR-001.2 (Actor Model) as the ideal stack for low-latency, high-concurrency trading systems.
- Premature Optimization (SIMD): Multiple reviewers (Gemini, Claude, GPT) flagged ADR-001.4 (SIMD Acceleration) as a premature optimization. Network latency (jitter) and API rate limits will be the bottlenecks, not CPU math.
- Multi-Tenancy Risks: There is consensus that a "Single-Binary" approach for multi-tenancy (ADR-001.8) creates "noisy neighbor" risks. High-tier strategies could be starved of resources by low-tier users. A pod-based or sharded architecture is recommended.
The "Atomicity" Illusion & Legging Risk¶
Every reviewer flagged FR-ARB-008 ("Atomic orderbook snapshot") and FR-ARB-007 ("Concurrent execution") as practically impossible across two distinct execution venues. * The Consensus: You cannot have true atomicity between a blockchain (Polymarket) and a Web2 centralized exchange (Kalshi). * The Risk: The system lacks a defined "Legging State Machine." If the first leg fills and the second fails (due to price slip or API error), the system is left with unhedged directional exposure.
Fuzzy Matching Danger¶
The requirement for Fuzzy Matching (FR-MD-002) was universally flagged as a "Critical Risk." * The Concern: "Trump vs Harris" (US) != "Trump vs Harris" (State-level). Similar names do not mean identical payout criteria. * Recommendation: Automated matching must be a suggestion engine only. FR-MD-003 (Manual Override) should be changed to FR-MD-003 (Human Confirmation Required). No arb should execute on a mapped pair without a signed human verification bit.
2. Critical Gaps Identified¶
A. Execution State Machine is Missing¶
The spec says "Concurrent Execution," but doesn't define what happens when things go wrong.
* Scenario: Polymarket order fails (gas spike/reorg) but Kalshi order fills.
* Missing Spec: How does the OrderExecutor rollback or hedge?
* Recommendation: Define a Saga Pattern or Compensating Transaction logic.
B. Inadequate Capital Management Strategy¶
- Rebalancing: Identify how capital moves between Polygon (USDC) and Kalshi (USD). This is slow (minutes/hours).
- The Risk: Arbing drains one side. Without an automated rebalancing loop (or alerts), the bot stops working quickly.
- Recommendation: Add FR-WM-XXX: Liquidity Rebalancing Alerts and integration with bridging APIs (e.g., Circle Cross-Chain Transfer Protocol if applicable, or manual workflows).
C. Compliance & ToS Hazards¶
- Arbitrage: High-frequency arb might violate Kalshi's "Market Manipulation" or "Disruptive Trading" clauses if not careful.
- Copy Trading: "Mirror Mode" + "Strategy Marketplace" strongly resembles dealing/advising.
- Recommendation: Add a Compliance Filter middleware that checks order patterns against known venue ToS limits.
3. Detailed Feedback on Specific Requirements¶
| ID | Requirement | Feedback | Recommendation |
|---|---|---|---|
| FR-MD-001 | Persistent Cache | Good, but needs versioning. | Add schema validation for cache entries. |
| FR-MD-002 | Fuzzy Matching | DANGEROUS. | Downgrade to "Candidate Proposal" only. Require human sign-off. |
| FR-ARB-008 | Atomic Snapshot | Impossible physically. | Rename to "Synchronized View Evaluation". Acknowledge strict non-atomicity. |
| FR-ARB-009 | <50ms Latency | Aggressive but possible. | Add "Network Jitter" to risk model. |
| FR-CT-008 | Cross-Platform Copy | Excellent feature. | Needs "Slippage Guard" - if source trade moves market, copy trade might fail. |
| ADR-001.4 | SIMD Arb | Overkill. | Remove complexity. Standard f64 ops are fast enough for <1000 pairs. |
| ADR-001.8 | Single Binary | Risk of resource contention. | Use tokio::sempahore per tenant or switch to ECS variants per tier. |
4. Implementation Plan Adjustments¶
The current Implementation Plan implies a linear build. The Council suggests a Risk-First Approach:
- Phase 1: The "Un-Happy" Path: Build the Execution State Machine & Failure Recovery first.
- Phase 2: Market Mapping Tool: Build the Admin UI for verifying pairs before the Arb Engine.
- Phase 3: The Happy Path: Connect the sockets and strategy logic.
5. Final Verdict¶
Architecture Grade: A- (Strong foundation) Completeness Grade: B (Missing failure modes & state management) Risk Grade: High (Due to legging risk & automated matching)
Recommendation: APPROVE the Architecture (Rust/Actor) but REQUIRE REVISION of the Functional Spec to address: 1. Legging/Partial Fill logic (The "Un-Happy Path"). 2. Human-in-the-loop requirement for Market Matching. 3. Liquidity/Capital Rebalancing workflows.