Most backtests lie. As I discussed in my previous research on Data Quality Guards (DQG), structural misleading in trading often stems from overfitting and weak out-of-sample validation.
Today, I’m introducing the Freqtrade integration and the new architecture behind the Kiploks Robustness Engine.
The Freqtrade Bridge
I have built a direct bridge between Freqtrade and Kiploks to eliminate manual data preparation.
The integration allows you to run a strategy in Freqtrade and automatically generate a full robustness report. Kiploks transforms raw trade data into a structured risk analysis without complex configuration or format conversion.
Open-Source Integration
The bridge implementation and setup instructions are available here:
👉 kiploks/kiploks-freqtrade (GitHub)
Deterministic Risk Engine (DRE)
Financial analytics is extremely sensitive to "calculation drift." To solve this, I’ve rewritten the core into a Deterministic Risk Engine (DRE).
The DRE operates on a canonical return domain (a single trade return array ) and ensures that identical input always produces identical output. It computes all risk metrics including volatility, Value at Risk (VaR), and Expected Shortfall—in a single backend pipeline.
Key architectural shifts:
- Single Source of Truth: All metrics like Sharpe ratio and Maximum drawdown are computed once on the backend.
- Zero Frontend Math: The frontend only renders API data, preventing inconsistencies between the UI and the analytical core.
The Judge Pattern: Separation of Concerns
Inspired by the separation of concerns principle, I implemented the Judge Pattern. This strictly separates the Math Layer from the Policy Layer.
1. Math Layer (The Calculator)
Calculates pure metrics (Expectancy, Volatility) using the DRE. It has no "opinion" on whether the numbers are good or bad.
2. Policy Layer (The Decision Maker)
Interprets the calculated numbers to produce a verdict: PASS / CAUTION / REJECT. It applies caps, safety margins, and thresholds, but it never redefines mathematical formulas.
3. Integrity Judge (The Validator)
A specialized layer that validates structural invariants after computation. It checks for:
- Concept drift
- Statistical anomalies
- Unit consistency
Ensuring Mathematical Integrity
To prevent "math dominance" and silent logic drift, the system now follows a strict data contract:
- Deterministic Computation: Policy decisions (caps/overrides) are handled separately from formulas.
-
Version Control: Every report includes
VERDICT_ALGORITHM_VERSION. - Rule-Based Priority: Verdict logic follows a strict rule-based system.
Methodology & Documentation
Along with this architectural update, I have published full model validation guides and quantitative analysis documentation on kiploks.com.
The real stress test begins now. I invite traders to break their strategies using the new engine and provide feedback on the limits of our robustness models.
I'm Radiks, the lead dev behind Kiploks. 🛡️
I bring institutional-grade validation to the retail trading world. Follow for deep dives into my Freqtrade integration, kill-switch logic, and the math of strategy robustness. Let's make open-source trading safer.
Top comments (0)