Strategy Operating System
QGTMAI Documentation Standard
This section is the GitHub-side operating manual for the precious-metals strategy stack. It is designed to answer the questions an allocator, reviewer, or operator actually needs answered:
- what exists,
- what is live,
- what is merely documented,
- what evidence supports it,
- and what should still be treated as controlled research.
Snapshot anchored to repo head 6fdbe848 on April 16, 2026.
Start Here
-
Operating Standard
Read the documentation contract, evidence rules, and GitHub/Notion parity model in Operating Standard.
-
Review Matrix
Read the per-strategy runtime posture, evidence posture, and critical caveat view in Review Matrix.
-
Evidence Index
Use Strategy Evidence Index for the honest list of validation and replay surfaces that exist today.
-
Category Narratives
Use the family pages for economic intuition and signal design: Macro Regime, Curve & Carry, Stat Arb, Positioning & Flows, Options, Microstructure, ML & Tail Hedge.
Runtime Truth Hierarchy
When counts or labels disagree, use this order of precedence:
GET /api/v1/strategiesfor current live-known runtime truth.qgtm_api/routes.py::PM_STRATEGIESfor the documented PM catalog.- The broader library only for research and operator context.
Never use raw qgtm_strategies/ file count as a production strategy count.
Inventory Layers
| Layer | What It Means | Canonical Surface |
|---|---|---|
| PM catalog | The 29 documented precious-metals strategies the repo treats as first-class catalog entries |
qgtm_api/routes.py::PM_STRATEGIES |
| Live-known runtime | The 31 strategies the daemon/API currently expose, including runtime-only sleeves |
GET /api/v1/strategies |
| Broader strategy library | The wider PM arsenal, including runtime-only and support/control sleeves | README, Notion library, strategy docs |
| Implementation bundles | Helper modules, support models, and composite layers | source tree only; not countable as standalone strategies by default |
What Good Documentation Must Do
A strategy page is not complete because it sounds sophisticated. It is complete only when an operator can answer all of these without opening code first:
- What is the exact trade thesis?
- What data does it depend on?
- What does the live implementation actually do, as opposed to the richer idea?
- What is the current runtime posture?
- What is the evidence quality?
- What are the blockers to promotion?
- What other sleeves overlap with it?
Current Category Map
| Category | Catalog Count | Typical Role | Primary Risk |
|---|---|---|---|
| Macro / Fundamental | 5 | directional regime capture | stale macro assumptions or regime breaks |
| Curve & Carry | 4 | basis, roll-yield, physical-tightness signals | feed integrity and contract alignment |
| Cross-Metal Stat-Arb | 4 | relative-value mean reversion | structural breaks and proxy contamination |
| Positioning & Flows | 5 | crowding and physical-demand signals | lagged or revised data |
| Options / Overlay | 4 | VRP harvest, skew, gamma, term structure | proxy-vs-options implementation mismatch |
| Microstructure | 4 | event and session dislocations | timing, slippage, and feed precision |
| ML / Meta | 2 | gating and adaptive selection | leakage, drift, and explainability |
| Tail Hedge | 1 | convex protection | persistent bleed and implementation drag |
Runtime-Only Sleeves
The runtime surface also includes sleeves that do not sit in the 29-entry PM
catalog. As of April 16, 2026, that includes:
tsmomxsmomcarver_trendcarver_carrykalman_pairspairs_mrvol_risk_parity
These are real operator concerns and must be documented with the same standard as the PM catalog, even when they entered through daemon/runtime wiring instead of the static catalog.
Supplemental And Control Layer
The broader documentation set also covers modules that are important but should not automatically be counted as standalone runtime strategies:
regime_detector.pycot_positioning.pyoptions_strategies.pyml_ensemble.pyinventory_surprise.pyforecasting.pyprecious_metals.pypysystemtrade_patterns.py
The rule is simple: a reusable engine, helper, or bundle is not a standalone capital sleeve until the runtime registry and review process say it is.
Documentation Promise
This section now aims to keep GitHub docs and Notion aligned around the same operator contract:
- one evidence story,
- one runtime-truth hierarchy,
- one review matrix,
- one promotion standard.
The pages linked above are the canonical places to inspect that contract.