Signal Pipeline — Detector → Advisor → Inspector execution flow

Overview

The signal pipeline is the core trading logic of the Barfinex platform. A market data event enters at Provider, becomes a signal in Detector, passes through an 8-stage AI decision pipeline in Advisor, is validated by Inspector's risk governor, and finally results in an executed order on the exchange.

Exchange candle close
        │
        ▼
   Provider (8081)
   publishes PROVIDER_MARKETDATA_CANDLE → Redis
        │
        ▼
   Detector (8101)
   FollowTrendService.onCandleClose()
   115 indicators computed → signal scored
   publishes DETECTOR_SIGNAL_GENERATED → Redis
        │
        ▼
   Advisor (8009) — 8-stage LLM pipeline
   Stage 1: Fetch context (Provider MCP)
   Stage 2: Market quality gate
   Stage 3: Signal engine (rules + ML)
   Stage 4: Conviction scoring [0,1]
   Stage 5: Calibration (logistic regression)
   Stage 6: LLM synthesis (Claude/GPT)
   Stage 7: Execution validation (spread/R:R)
   Stage 8: Publish ADVISOR_EXECUTION_INTENT_OPEN → Redis
        │
        ▼
   Inspector (8008)
   RiskEngine → RiskGovernor → PortfolioEngine
   ALLOW → ProviderExecutionService (REST order)
   BLOCK/THROTTLE → audit log, no execution
        │
        ▼
   Provider (8081) → Exchange (Binance/Bybit/…)
   Exchange fills → real fill via account WS ORDER_TRADE_UPDATE
   Provider publishes PROVIDER_ORDER_FILL → Redis
        │
        ▼
   Inspector: INSPECTOR_TRADE_OUTCOME → Redis
   Advisor: updates calibration weights (INSPECTOR_TRADE_OUTCOME)

Stage 1: Detector — Strategy runtime

Detector is a configurable rule engine with 115 technical indicators. Each Detector instance is a typed TypeScript configuration specifying:

• Which symbols and intervals to watch
• Which indicators to compute (rsi14, adx14, macd, ema20, bands20, atr14, dc20, stoch, cci20, mfi14, obv, vwap, etc.)
• Which rules to evaluate and their numeric weights
• Conviction threshold for signal emission

Indicator computation:

• IndicatorEngine computes in DAG order — indicators with dependencies compute after their inputs
• Every indicator result is published via IndicatorSnapshotStoreService to the indicator publisher (REST + WebSocket)
• Feature vectors extracted from raw indicator values for ML and LLM context

Signal scoring:

• Each rule produces a sub-score weighted by its configured weight
• Combined score compared to signalThreshold
• Signal carries: symbol, side (BUY/SELL), confidence [0,1], strategyId, rule attribution

Multiple instances:

• Multiple Detector configurations run simultaneously, each isolated
• DecisionWindowService in Advisor is keyed by symbol + strategyId — two detectors on the same symbol each get an independent decision cycle with full provenance

Capital efficiency:

• Detector tracks per-strategy capital utilization, suppression, and reservation analytics
• GlobalCapitalAllocatorEngine evaluates each signal against per-symbol and total exposure limits before publishing

Stage 2: Advisor — 8-Stage LLM Pipeline

Stage 1: ProviderMcpContextService

Fetches live market context via Provider MCP tools:

• Current price, recent candles, orderbook depth
• Open positions, account balance, equity
• Any active Inspector risk state

Stage 2: MarketReadinessGateService

Validates market data quality via MarketQualityEngine:

• Orderbook freshness and depth
• Trade stream continuity
• Candle OHLC validity
• Returns healthScore [0,1] and healthState: HEALTHY/DEGRADED/BAD
• Block threshold: DATA_QUALITY_BLOCK_HEALTH_SCORE=0.3

Also runs DataQualityGateService (Phase 14):

• Feature NaN count check (DATA_QUALITY_BLOCK_NAN_COUNT=5)
• Orderbook staleness check (DATA_QUALITY_BLOCK_STALENESS_MS=120000ms)
• Rolling feature drift — 100-sample baseline per feature, flags >2σ for ≥3 consecutive snapshots
• Regime instability — >3 regime changes in 30 minutes
• Performance drift — recent-20 win rate vs historical-100 win rate

Stage 3: SignalEngineIntegrationService

Runs rule engine + ML signal scorer in parallel:

• Rule engine: evaluates signal conditions against live data
• ML signal scorer (Stage 3.5): optional PyTorch MLP inference via ML_TRADING_ADVISOR_URL (port 8019)
  • Currently DISABLED (ML_TRADING_ADVISOR_ENABLED=false) — no robust edge, insufficient training data
  • Head 1: direction (UP/DOWN/NEUTRAL)
  • Head 2: expected return (%)
  • Latency target: <5ms

Stage 4: ConvictionEngineService

Scores conviction [0,1] from:

• Signal engine confidence
• ML agreement/disagreement adjustment (when enabled)
• Quantitative runtime truth: account active, margin sufficient, kill-switch state, data freshness
• Hard NO_TRADE on explicit kill switch, insufficient margin, or stale feed

Stage 5: CalibrationEngineService

Calibrates raw conviction via:

• Logistic regression (Platt scaling) with per-regime scaling
• Isotonic regression as alternative
• ConvictionLogisticModel returns: win probability, capital multiplier, ALLOW/DAMPEN/BLOCK
• Calibration weights updated from INSPECTOR_TRADE_OUTCOME feedback loop

Stage 6: GptService — LLM Synthesis

Calls the configured LLM with full structured context:

• Market data snapshot, indicator values, orderbook depth
• Account state, open positions, risk status
• Breaking market intelligence (from PROVIDER_MARKET_INTELLIGENCE_EVENT — critical/high events only)
• Conviction score and calibration result

LLM catalog (config.advisor.json — not env vars):

Role assignments: decision=claude-opus, advisory=claude-opus, temperature decision=0.2, advisory=0.5.

Stage 7: ExecutionAgentService

Final validation before Redis emit:

• Spread < 0.4% (or MICRO_GATE_SPREAD_BLOCK_PCT)
• Risk/Reward ≥ 1.2 (MIN_RR_FULL=2.0 from TuningRegistry)
• Direction strength > 0.25 (MIN_DIRECTION_STRENGTH)
• Consistency score > 0.5 (MIN_CONSISTENCY)
• Edge score > 0.4 (MIN_EDGE)
• Execution quality > 0.4 (MIN_EXECUTION_QUALITY)

Decision policy modes:

• CONSERVATIVE (default) — tight thresholds, fewer trades
• BALANCED — moderate
• AGGRESSIVE — looser thresholds, higher frequency

Stage 8: Redis emit

Publishes ADVISOR_EXECUTION_INTENT_OPEN/CLOSE/REDUCE/FLIP and ADVISOR_DECISION_MADE to Redis. Execution intents are dual-written to Redis Streams for bounded replay.

Signal Fusion Engine (SHADOW mode)

An optional upstream layer that pre-aggregates multi-detector signals across domains before the 8-stage pipeline runs.

Domains: LIQUIDITY, FLOW, NEWS, MICROSTRUCTURE, LEGACY (weights configurable via env vars)

Pipeline:

1. SignalIntakeService subscribes to DETECTOR_SIGNAL_GENERATED
2. Stale filter (>45s) + per-symbol storm protection (10/sec)
3. SignalBuffer rolling 90-second window per symbol
4. DebounceCoordinator leading-edge 350ms timer
5. Domain-weighted consensus with multi-domain boost (×1.25), conflict veto (ratio ≥0.85), per-domain cap (0.55)
6. Single-domain override: LIQUIDITY ≥0.75 strength + ≥0.9 reliability bypasses consensus

Status: Currently in SHADOW mode — logs and counters only. Active pipeline drive deferred behind ADVISOR_SIGNAL_FUSION_DRIVE_PIPELINE=true.

Intel Detectors

Lightweight services that bypass the heavy DetectorService DI chain. Subscribe to PROVIDER_MARKET_INTELLIGENCE_EVENT and publish DETECTOR_SIGNAL_GENERATED.

Feature flags: INTEL_DETECTORS_WHALE_ALERT_ENABLED, INTEL_DETECTORS_NEWS_ENABLED (default OFF).

Stage 3: Inspector — Risk Governor

Execution flow

ADVISOR_EXECUTION_INTENT_* received
    │
    ▼
RiskEngine.evaluate()          -- compute proper position size
    │ ATR stop, Kelly, regime multiplier, vol scaling
    │
    ▼
PortfolioEngine.evaluate()     -- cross-symbol correlation check
    │ covariance matrix, vol budget, correlation soft-cap 0.6
    │
    ▼
RiskGovernor.evaluate()        -- 17 block reasons, 5 actions
    │
    ├── ALLOW → ProviderExecutionService.submitOrder()
    ├── BLOCK → audit log, no execution
    ├── THROTTLE → reduce position size
    ├── STAND_DOWN → block all new opens
    └── CLOSE_ALL → emergency exit all positions

5 RiskGovernor actions

17 block reasons

EXPOSURE_CAP_BREACH, DRAWDOWN_LIMIT_BREACH, DAILY_LOSS_LIMIT_BREACH, CONSECUTIVE_LOSSES_LIMIT, MARGIN_INSUFFICIENT, LEVERAGE_EXCEEDED, COOLDOWN_ACTIVE, CIRCUIT_BREAKER_OPEN, STANDDOWN_POLICY, THROTTLE_POLICY, CLOSE_ALL_POLICY, HEALTH_DISALLOW, DATA_NOT_MATURE, ACCOUNT_INACTIVE, INVALID_QUANTITY, EXPOSURE_ESTIMATED_BREACH, ALLOW_DEFAULT

Post-execution

After successful OPEN:

1. Inspector immediately places bracket orders (STOP_MARKET + TAKE_PROFIT_MARKET) via Provider REST
2. Binance protection orders use rate-limiter protection priority — bypass local client-side freeze, Binance response still authoritative
3. INSPECTOR_TRADE_OUTCOME published to Redis → Advisor updates calibration weights
4. PostTradeAuditService records: slippage bps, latency ms, fee tiers, partial fill detection
5. Equity curve updated in inspector_equity_curve (QuestDB, every account sync)

Scale-out and TWAP

• Scale-out: configurable riskManagement.scaleOutLevels[] — {pnlPct, closePct} pairs. Processed sequentially.
• TWAP: TwapExecutionService splits large orders into configurable slices at intervals. Idempotent sub-orders tracked (active/completed/failed/cancelled).

Key env vars