Work in progress / independent research system
QAP
A deterministic crypto research workbench that tests strategies against matched passive controls, realistic costs, immutable evidence, and an explicit live-capital NO-GO boundary.
Repository snapshot
QAP
Deterministic research workbench for evidence before promotion.
- Commits
- 218
- Product
- Workbench
- Research
- Deterministic
Work done
QAP
A research system is more useful when it can reject its own strategy.
- Problem: statistical structure can look convincing while the resulting policy still loses to a simple passive baseline after realistic costs.
- Decision: make matched economic controls, causal evidence, and immutable runs the authority. Models are candidates, not judges.
- Proof: the current repository has deterministic replay, exact portfolio accounting, forward-paper operations, a finite FastAPI command boundary, a React/Vite workbench, and a recorded live-capital
NO-GO. - Status: active research system; forward-paper evidence is allowed to accumulate, but live capital remains explicitly blocked.
The project has two generations
The earlier tradingview_ratio repository grew into QAP — Quantitative Arbitrage Pairs. It was a correctness-first Python CLI with an explicit Discovery → Validation → Signal → Execution lifecycle, vetoes, paper workflows, and Student-t Copula evidence near the center of signal authority.
That work is the predecessor, not the current architecture.
The current qap repository starts from a different product law: portfolio wealth relative to the correct matched passive HODL/control after costs is the primary economic objective. Coin-unit accumulation remains useful attribution, but it cannot turn wealth destruction into a success story.
What changed
| Earlier QAP | Current QAP |
|---|---|
| Pair-validation CLI | Local research workbench |
| Model-led signal authority | Matched economic controls are authoritative |
| Coin accumulation as the headline objective | Matched-HODL-relative portfolio wealth after costs |
| Typer-first operator surface | Deterministic engine + FastAPI boundary + React/Vite UI |
| Paper bundles around pair decisions | Immutable experiments, scanner research, and forward-paper operations |
| Stronger model = likely next step | Richer models must earn admission with a falsifiable question |
The biggest improvement is not the web UI. It is that a model can now end as REJECT without the project treating that as a failed implementation.
Current architecture
public market evidence
-> deterministic experiment / replay engine
-> exact portfolio accounting
-> HODL + matched controls
-> immutable run artifacts
-> forward-paper operations
-> finite FastAPI command/query boundary
-> React/Vite research workbenchThe workbench is organized around user questions—Home, Discover, Validate, Portfolios, Results, Activity—while the scientific and economic authority stays in backend evidence.
A prettier chart cannot promote rejected research.
Evidence before promotion
The current research flow is deliberately simple-first. A candidate has to survive the declared controls and costs before a richer relationship model gets to matter.
That means a useful run can end with:
strategy: interesting
vs periodic control: positive
vs matched HODL: negative
promotion: NOThe weaker comparison does not rescue the strategy.
The same discipline applies to final out-of-sample evidence. Holdout data is not allowed to become another tuning set just because the result is disappointing.
Forward-paper is not live trading
QAP can run deterministic forward-paper operations over recorded public venue inputs and reconcile the resulting artifacts. That is still a research boundary.
The current Phase-12 decision remains NO-GO for live operation. The repository has no private exchange credentials, authenticated live-trading API, browser order controls, live scheduler, or live-capital authority.
That boundary is visible in the product because implementation progress and permission to deploy capital are different claims.
Why the API is deliberately finite
The local FastAPI layer is not a generic remote-control surface. It exposes a finite research mutation boundary and validated evidence reads for a single-operator local workbench.
Longer scientific operations have durable operation records rather than pretending one HTTP request owns their whole lifetime. The frontend can ask what happened without becoming the source of scientific truth.
What I learned
The original QAP taught me to make vetoes explicit. The current QAP pushed that idea further: the research thesis itself needs a veto.
A system that can only discover promising results is not doing much research. The more trustworthy version preserves rejected runs, compares against boring controls, and allows the correct conclusion to be “do not promote this.”