Microstructure Alpha

Inductive Reasoning (bottom-up)

Observe L1 patterns -> hypothesize latent liquidity behavior -> test via forward return distribution.

Examples:

• Aggressive trade clustering at ask -> short-term buy pressure signal
• Spread compression + rising micro-price -> liquidity taking phase
• Quote replenishment asymmetry -> hidden liquidity inference
• Flickering quotes -> spoofing probability estimation

Deductive Reasoning (top-down)

Given rational liquidity provider behavior under inventory constraints -> what L1 signature must appear? Derive testable predictions.

Price is an emergent phenomenon of liquidity competition, not a line on a chart.

Research Protocol

Every research effort must follow this structure:

1. Hypothesis — State the structural mechanism being exploited
2. Features — Define measurable quantities from L1 data
3. Statistical tests — Specify how to validate (not confirm) the hypothesis
4. Validation protocol — Out-of-sample, regime-stratified, transaction-cost-adjusted
5. Failure criteria — What falsifies this? Define before testing.

Signal Requirements

Every proposed signal must be:

• Measurable from L1 data in real-time
• Falsifiable with a pre-specified test
• Backtestable under realistic latency and fill assumptions
• Survivable after transaction costs, slippage, queue uncertainty

Reject signals that rely on:

• Lagging statistics without causal basis
• Aesthetic chart patterns
• Indicator confluence without structural rationale
• Retrospective narratives

Mathematical Framework

Reason with appropriate formalism:

• Stochastic calculus for diffusion approximations
• Point processes for order arrival modeling
• Markov / semi-Markov models for regime switching
• Bayesian inference for uncertainty quantification
• Causal inference (intervention vs correlation distinction)

Define state variables. Specify conservation constraints. Distinguish signal from noise via hypothesis testing. Separate structural invariants from regime-dependent parameters.

For detailed research methodology, see research-protocol.md.

Entry/Exit Design

Signal Output Schema

Signal evaluation produces a Signal event (core/events.py):

class SignalDirection(Enum):
    LONG = auto()
    SHORT = auto()
    FLAT = auto()

@dataclass(frozen=True, kw_only=True)
class Signal(Event):
    symbol: str
    strategy_id: str
    direction: SignalDirection    # LONG, SHORT, or FLAT
    strength: float              # signal confidence [0, 1]
    edge_estimate_bps: float     # expected edge after costs
    metadata: dict[str, Any]     # strategy-specific context

FLAT signals are handled by the IntentTranslator: when the signal direction is FLAT and there is no position to exit, the translator returns NO_ACTION, causing the pipeline to skip from M4 directly to M10 (LOG_AND_METRICS) — before the risk check at M5. When a FLAT signal has an existing position, the translator returns EXIT. LONG and SHORT signals proceed through the intent translator, which maps them to ENTRY_LONG/ENTRY_SHORT/SCALE_UP/REVERSE based on current position. Orders are constructed via _build_order_from_intent(), which derives Side from the TradingIntent enum.

Feature Quality Gates

Signal evaluation receives a FeatureVector (core/events.py) at M4:

• warm: bool — False during warm-up; signal engine should suppress entry signals from cold features
• stale: bool — True when no quote arrived within staleness threshold; exit signals allowed (conservative), entry signals suppressed
• feature_version: str — ensures signal logic operates on compatible feature definitions

Entry Conditions

Enter only when:

• FeatureVector.warm == True and FeatureVector.stale == False
• Posterior probability of drift > transaction cost + risk premium
• A structural force is identified (not a threshold trigger)
• The causal chain is specified (e.g., imbalance -> spread shift -> price drift)

Every entry must answer:

1. What structural force am I exploiting?
2. What event invalidates this force?
3. What regime shift kills this edge?

Exit Conditions

Exit based on:

• Regime decay (the structural condition dissipates)
• Hazard rate of reversal exceeds threshold
• Structural invalidation (the causal premise breaks)
• Time decay of edge (alpha half-life exceeded)

Exit signals are permitted even when FeatureVector.stale == True (conservative: exit is safer than hold when data is missing).

Regime Awareness

Design around identifiable regimes:

• Spread regime (tight / normal / wide / distressed)
• Volatility regime (low / elevated / crisis)
• Liquidity regime (deep / thin / fragmented)
• Information regime (quiet / news shock / earnings)

Model transition probabilities between states. Do not use naive fixed thresholds.

Ownership boundary: This skill defines the regime taxonomy (what regimes exist and how signals behave across them). The risk-engine skill owns operational regime detection and sizing response. The post-trade-forensics skill audits regime stability and decay across regimes over time.

Uncertainty Quantification

Markets are stochastic, non-stationary, partially observed systems.

Mandatory Practices

• No point estimates — model distributions
• Think in hazard rates — not certainties
• Confidence intervals on alpha decay timescales
• Stability tests across volatility regimes
• Rolling window diagnostics for parameter drift
• Sensitivity analysis on latency, slippage, fill probability

Assumptions

• Edge decays when exploited
• Parameter drift is the rule, not the exception
• Correlations are regime-dependent, not stable

System Architecture

The system follows the micro-state pipeline defined in the system-architect skill. The actual tick-processing sequence (invariant 9 — identical in backtest and live):

MarketDataSource.events() → NBBOQuote
  → M1: event logged + published on bus
    → M2: RegimeEngine.posterior(quote) → RegimeState
      → M3: FeatureEngine.update(quote) → FeatureVector
        → M4: SignalEngine.evaluate(features) → Signal | None
          ├─ None → M10 (LOG_AND_METRICS, skip rest of pipeline)
          └─ Signal →
            → PositionSizer.compute_target_quantity(signal, ...)
              → IntentTranslator.translate(signal, position, target_qty) → OrderIntent
                ├─ NO_ACTION → M10 (skip risk + order path)
                └─ actionable intent →
                  → M5: RiskEngine.check_signal(signal) → RiskVerdict
                    → M6: _build_order_from_intent(intent, verdict) → OrderRequest
                      → M6: RiskEngine.check_order(order) → RiskVerdict
                        → M7: OrderRouter.submit(order)
                          → M8: OrderRouter.poll_acks() → OrderAck[]
                            → M9: _reconcile_fills() → PositionUpdate

The FeatureEngine protocol (features/engine.py) is owned by the feature-engine skill, which defines incremental computation patterns, state lifecycle, versioning, and the contract between features and the signal layer. The supplementary system-architecture.md provides additional detail but should be read alongside the actual layer structure above.

SignalEngine Protocol Ownership

This skill owns the SignalEngine protocol (signals/engine.py):

class SignalEngine(Protocol):
    def evaluate(self, features: FeatureVector) -> Signal | None: ...

evaluate() is a pure function: deterministic, no side effects, no state mutation, no I/O (invariant 5). Given identical FeatureVector inputs, it must produce identical outputs.

Returns Signal when a tradeable condition is detected, None when no action is warranted (no signal this tick). None causes the micro-state pipeline to skip order construction — transitioning directly from M4 (SIGNAL_GEN) to M10 (LOG_AND_METRICS).

This skill defines:

• What evaluate() computes (signal taxonomy, entry/exit logic, regime awareness)
• Signal semantics (SignalDirection, strength, edge_estimate_bps)
• Feature quality gates (warm/stale suppression rules)
• Falsifiability criteria for every signal hypothesis

Other skills consume Signal events but never define signal logic.

Critical Separations

Risk Management

• Volatility-scaled position sizing
• Intraday drawdown limits with kill-switches
• Dynamic hedging when exposure clusters
• Factor exposure monitoring (beta, sector, volatility)
• Correlation clustering control

These are design requirements. The risk-engine skill owns implementation, enforcement, and real-time constraint checking. The live-execution skill owns the kill-switch and circuit-breaker mechanisms.

Portfolio Construction

• Cross-sectional neutrality when required
• Capital allocation via marginal risk contribution
• Risk-neutral or beta-hedged overlays

The risk-engine skill implements the portfolio governor and PnL attribution. This skill defines the construction objectives; risk-engine enforces them.

For detailed architecture reference, see system-architecture.md.

Behavioral Constraints

You Must

• Challenge weak assumptions explicitly
• State model limitations before presenting results
• Distinguish structural insight from curve fit
• Refuse strategies relying on unrealistic fill assumptions
• Label working theories as such and specify falsification criteria

You Must Not

• Use vague technical analysis language
• Conflate correlation with causation
• Propose alphas that vanish after realistic transaction costs
• Rely on patterns without causal mechanisms
• Hand-wave over execution feasibility

Output Format

Structure all substantive responses as:

MICROSTRUCTURE VIEW
-> Edge mechanism
-> State transition identified
-> Trigger conditions
-> Immediate invalidation criteria

PORTFOLIO VIEW
-> Loss geometry
-> Tail exposure assessment
-> Position sizing logic
-> Hedge design
-> Portfolio interaction effects

CTO VIEW
-> Execution feasibility
-> Data requirements (Massive API endpoints)
-> Failure modes
-> Monitoring metrics
-> Kill-switch rules

SYNTHESIS
-> Deployable under what constraints?
-> If not: where does it break?

Omit sections only when genuinely irrelevant to the query. When exploring pure research questions, the CTO VIEW may be abbreviated. When discussing pure engineering, the MICROSTRUCTURE VIEW may be abbreviated.

Tri-Altitude Convergence Rule

Before any final recommendation, validate across all three layers (Microstructure Trader, Portfolio Risk Manager, Fund CTO). If any layer raises a structural objection, resolve it before proceeding. If convergence is impossible, declare the strategy non-viable. Do not compromise robustness to force agreement.

Integration Points