pal-e-docs
Note not found.

Application Domain: Prediction Assistant

arch-app Architecture

architecture active
Project

Application Domain: Kalshi Assistant

Core service architecture and domain logic. Answers: what are the services and how do they interact?

Diagram




          
  
Components



          
  

    

        
          

              Component
              Purpose
              Notes
          

        
      
          

              KalshiClient
              HTTP wrapper for Kalshi API v2 with RSA-PSS authentication
              Signs each request with timestamp + method + path; handles rate limiting (20 reads/sec, 10 writes/sec basic tier)
          

          

              MarketScanner
              Polls same-day markets and filters by confidence threshold
              GET /markets?series_ticker=SERIES&status=open; caches results in markets table; identifies candidates above buy_threshold
          

          

              Watchdog
              Auto-buy when market crosses threshold; auto-sell on triggers
              Entry at 85%+, take profit at 95%+, cut loss below 80%; creates Trade records in active Portfolio
          

          

              SizingEngine
              Calculates optimal YES/NO allocation per Option D model
              Default: 83% YES / 17% NO; brute-force optimized to minimize worst-case loss (-$5.77 on $100 budget)
          

          

              MarketScanJob
              Recurring Solid Queue job for market polling
              Runs every N seconds; calls MarketScanner.scan; creates MarketScan audit record
          

          

              PositionMonitorJob
              Monitors open positions for sell triggers
              Checks price movement on open trades; triggers Watchdog sell logic on threshold breach
          

      
    

  



          
  
Key Decisions



          
  
    
      
  • Service object pattern — each service has a single responsibility: KalshiClient (auth/HTTP), MarketScanner (polling/filtering), Watchdog (buy/sell logic), SizingEngine (allocation math)
    • 
      
  • Watchdog auto-buy at 85%+ — threshold configurable per strategy via watchdog_configs; avoids pregame prediction entirely; rides mid-game momentum when the outcome becomes clear
    • 
      
  • Option D 83/17 split as default sizing — brute-force optimized worst-case loss; stored in sizing_configs for per-strategy override; adjusts based on pick count and confidence levels
    • 
      
  • Rate limit awareness in KalshiClient — tracks request count per second; backs off before hitting basic tier limits (20 reads/sec, 10 writes/sec)
    • 
      
  • MarketScan audit trail — every polling cycle logged with markets_found and above_threshold counts; enables analysis of scan frequency vs. opportunity detection rate
    • 
      
  • Sell triggers as configurable thresholds — take_profit (95%+) and cut_loss (below 80%) stored in watchdog_configs; not hardcoded, tunable per strategy
    •