Skip to content

Strategy Documentation Operating Standard

Operator Contract

This page defines what a state-of-the-art strategy page must look like in QGTMAI. It applies to both GitHub docs and Notion. The goal is not to sound institutional. The goal is to let a reviewer govern capital without reverse engineering the repo.

The Standard

A strategy surface is only considered complete when it is:

  • technically accurate,
  • explicit about runtime posture,
  • explicit about evidence quality,
  • visually scannable,
  • and honest about the gap between thesis and implementation.

Required Sections On Every Strategy Page

  1. Identity
  2. strategy name
  3. strategy ID
  4. code path
  5. category
  6. owner / review cadence
  7. Thesis
  8. intuitive economic story
  9. why this edge should exist in precious metals
  10. Implementation Reality
  11. exact live logic
  12. what the code really emits
  13. what it does not yet do
  14. Inputs And Dependencies
  15. feature columns
  16. provider dependencies
  17. freshness assumptions
  18. PIT assumptions
  19. Portfolio Role
  20. expected holding horizon
  21. long-only vs long/short
  22. overlap with sibling sleeves
  23. Failure Modes
  24. structural failure
  25. feed failure
  26. execution failure
  27. governance failure
  28. Evidence Status
  29. validation packet
  30. replay link
  31. realized PnL / turnover / slippage status
  32. latest review date
  33. Promotion Rule
  34. why it may receive more capital
  35. why it must stay constrained

Visual Grammar

Good strategy documentation is dense but scannable. Use:

  • one clear summary block at the top
  • short tables for identity and posture
  • explicit section headers
  • a visible Evidence Status block near the end
  • an explicit Last Updated marker

Do not use:

  • vague marketing language
  • stale Sharpe claims without context
  • narrative-only pages that hide runtime truth
  • tables that imply live readiness when the implementation is still proxy-only

Runtime Labels

Use labels consistently:

Label Meaning
active currently enabled in the daemon/runtime surface
shadow wired enough to observe, not trusted enough for meaningful capital
inactive registered but disabled
research documented concept or blocked implementation
runtime-only live-known daemon sleeve not represented in the static PM catalog

Evidence Ladder

Stage Minimum Evidence
Research narrative docs + code or design stub + explicit blockers
Shadow walk-forward evidence + replay lineage or explicit replay gap + operator review
Paper runtime wiring + tagged attribution + current operational evidence
Live Capital current attribution, slippage review, decay review, and explicit promotion approval

GitHub And Notion Parity Rules

GitHub and Notion do not have to look identical, but they must say the same thing about:

  • strategy identity
  • runtime posture
  • validation status
  • replay status
  • promotion blockers

If one surface is richer than the other, the richer surface must be linked from the poorer one. Contradictory posture is not allowed.

Definition Of Done

A strategy documentation pass is done only when:

  1. the GitHub family docs are updated,
  2. the Notion row has packet and replay links,
  3. the strategy page body shows evidence status visibly,
  4. the runtime posture is truthful,
  5. the last-reviewed marker is current.

Current Gap To Close

As of April 16, 2026, the main remaining documentation gap is not missing prose. It is missing strategy-specific evidence artifacts and incomplete page-template normalization across the full strategy library.