Execution Risk Framework
KEK is validation-first infrastructure designed to contain failure modes before capital is at risk. Every strategy must pass through a structured qualification pipeline before becoming eligible for live deployment.
This page describes the constraint enforcement mechanisms, strategy state management, and transparency about what KEK does not do.
What this page covers
- Infrastructure-level constraint enforcement
- Strategy state machine and lifecycle transitions
- Validation gates and eligibility requirements
- Clear limitations and scope boundaries
Constraint enforcement
Risk limits are enforced at the infrastructure layer, not by user discipline. Constraints apply pre-execution and cannot be bypassed by strategy logic.
Position limits
Each strategy operates within configurable position limits:
- Maximum allocation per position (default: 20% of portfolio)
- Concentration caps to prevent single-asset dominance
- Per-strategy and portfolio-level constraints
Position limits are validated at order submission time. Orders exceeding limits are rejected before execution.
Exposure caps
Aggregate exposure is monitored across all active strategies:
- Maximum gross account exposure (default: 50%)
- Cross-strategy correlation limits to prevent hidden concentration
- Margin utilization thresholds
Exposure caps prevent portfolio-level fragility even when individual strategies appear safe.
Order-level validation
Every order passes through validation before submission:
- Position limit verification
- Margin requirement checks
- Liquidity threshold assessment
- Strategy state verification (must be Active)
Invalid orders are rejected with clear error feedback.
Audit trail
All system activity is logged for post-trade analysis:
- Order submissions and outcomes
- State transitions and triggers
- Constraint violations and rejections
- User actions and approvals
The audit trail provides transparency for strategy refinement and debugging.
Strategy state machine
Every strategy exists in one of five states. State transitions are governed by validation gates and risk metrics.
State definitions
Queued: Strategy created but not yet validated. Cannot deploy capital. All new strategies start here.
Eligible: Passed all validation stages. Ready for live deployment upon user authorization.
Active: Executing live with capital. Subject to continuous monitoring and constraint enforcement.
Paused: Temporarily halted. May be triggered by:
- Drawdown threshold breach
- User-initiated pause
- Anomaly detection
- Regime transition events
Retired: Permanently deactivated. No further execution permitted. May be due to persistent underperformance, structural decay, or user decision.
Transition rules
Strategies can only move forward through validation:
- Queued → Eligible: Requires passing all validation stages
- Eligible → Active: Requires user authorization
- Active ↔ Paused: Bidirectional based on conditions
- Any state → Retired: Terminal state, irreversible
Backward transitions (e.g., Active → Queued) are not permitted. Strategies requiring re-validation must be retired and recreated.
Validation gates
Strategies progress through three sequential gates before becoming capital-eligible.
Gate 1: Backtest validation
Historical performance evaluation:
- In-sample performance with realistic cost modeling
- Out-of-sample testing on held-out data
- Walk-forward optimization across rolling windows
- Regime-segmented analysis
Failure at this gate requires strategy refinement before retry.
Gate 2: Robustness checks
Statistical stress testing:
- Monte Carlo simulations (10,000+ paths)
- Bootstrap resampling for confidence intervals
- Parameter perturbation to detect fragility
- Drawdown distribution analysis
Strategies that show brittleness under perturbation are rejected.
Gate 3: Paper execution
Simulated live execution:
- Real-time market data, simulated orders
- Order fill probability modeling
- Slippage and latency simulation
- Minimum paper period before eligibility
Paper trading validates that backtest assumptions hold under live conditions.
What KEK does not do
Transparency about limitations is as important as capability claims.
No return guarantees
Validation reduces the probability of deploying fragile strategies. It cannot guarantee future performance. Markets are non-stationary; past robustness does not ensure future profits.
No investment advice
KEK is infrastructure for strategy development. It does not recommend specific strategies, allocations, or trading decisions. Users make their own investment choices.
No custody of funds
Non-custodial architecture. Users connect their own exchange accounts via API keys. KEK never holds, controls, or has withdrawal access to user capital.
No forced execution
While validation is required before eligibility, deployment is user-initiated. No automated capital commitment occurs without explicit user authorization.
No AI infallibility claims
AI agents are tools with defined capabilities and limitations. Strategy suggestions are structured outputs based on analysis — not autonomous decision-makers with guaranteed accuracy.
No uptime guarantees
System dependencies (exchanges, networks, APIs) may experience outages. Users retain responsibility for position management during service disruptions.
Why this matters
Execution risk management in KEK operates through:
- Structural constraints — Position and exposure limits enforced pre-execution
- State management — Clear lifecycle with defined transition rules
- Validation gates — Sequential checkpoints before capital eligibility
- Transparency — Clear scope boundaries and limitation disclosures
This framework reduces execution risk through systematic discipline — not through guarantees that cannot be made.