Program Charter

Version: 1.0 Effective: 2026-05-13 Owner: Quant7 Alpha, LLC · Haneef Haqq (haneef@quant7alpha.com) Status: LIVING — version-controlled; amendments require user sign-off Authority hierarchy: This Charter ▸ 00 UI CLAUDE.MD (operational rules) ▸ subordinate docs ▸ code

The Charter is the program's constitution. The operating rules in 00 UI CLAUDE.MD are subordinate to it. Subordinate documentation is subordinate to both. Code is the lowest layer of authority and must conform to every layer above it.

§ 1 — Purpose

Q7 AEGIS AI 1.0 is an institutional-grade, multi-asset systematic trading program owned and operated by Quant7 Alpha, LLC. Its mission is to deploy fiduciary-quality systematic alpha across six strategies (S1–S6) under the Seven Principles of a Hedge Fund Framework and in alignment with Federal Reserve SR 11-7 model risk management guidance (fit-for-purpose).

This Charter formalizes:

1. The Seven Principles as the program's published commitments.
2. The agent-operated execution model that enforces those commitments.
3. The bounded authority each agent exercises and where authority terminates at the user.
4. The audit-grade artifacts the program must produce to be publishable to outside capital.

This Charter is the precondition for soliciting allocator capital and for any regulator interaction. Nothing in the program may operate outside its scope.

§ 2 — The Seven Principles (canonical)

The canonical wording is the version published on quant7alpha.com/program. The whitepaper, this Charter, and every subordinate document must conform to this wording.

Each principle is enforced in code via the agent program described in § 4. The Charter is not the marketing layer — it is the engineering specification.

§ 3 — Authority hierarchy

The program operates under a strict hierarchy. Higher layers override lower layers in all conflicts.

                    ┌───────────────────────────────────────────┐
                    │  USER (Haneef Haqq · sole final authority) │
                    │  · charter amendments                      │
                    │  · escalation decisions                    │
                    │  · production deployments                  │
                    │  · model promotions                        │
                    └─────────────────────┬─────────────────────┘
                                          ▼
                    ┌───────────────────────────────────────────┐
                    │  PROGRAM CHARTER (this document)           │
                    │  · mission · principles · authority limits │
                    └─────────────────────┬─────────────────────┘
                                          ▼
                    ┌───────────────────────────────────────────┐
                    │  00 UI CLAUDE.MD (operational rules)       │
                    │  · 7-step pipeline · escalation triggers   │
                    │  · HAI sub-charter · standing rules        │
                    └─────────────────────┬─────────────────────┘
                                          ▼
                    ┌───────────────────────────────────────────┐
                    │  Agent system prompts                      │
                    │  · per-agent duties · per-agent boundaries │
                    │  · principle enforcement assignments       │
                    └─────────────────────┬─────────────────────┘
                                          ▼
                    ┌───────────────────────────────────────────┐
                    │  Code (q7_precision, strategy cores, ...)  │
                    │  · implements the rules above              │
                    └───────────────────────────────────────────┘

No agent, module, or process may override a higher layer. Any conflict between layers is itself an escalation trigger.

§ 4 — The Seven-Agent Operating Model

The program is operated by seven agents orchestrated under Claude Flow. The agent count is fixed at seven because the count maps 1:1 to the operational duties required by the Seven Principles plus SR 11-7's five-pillar lifecycle:

Adding an eighth agent would create overlap (and weaken auditability of who did what). Removing any of the seven would collapse a duty under SR 11-7 or under the Charter; for example, merging Trainer + Validator would void independent validation. Seven is the load-bearing minimum.

§ 4.1 — Agent roster

§ 4.2 — Bounded authority

Each agent has explicit "may" and "may not" lists. These are non-negotiable.

§ 4.3 — Independence requirement (SR 11-7 §VI)

The Validator agent operates with cryptographic and organizational independence from the Trainer:

1. Distinct API key. Each agent has its own Anthropic API key. Validator's key is never used by Trainer and vice versa.
2. Distinct workflow node. Validator runs as a separate Claude Flow node with its own system prompt and audit identity.
3. Distinct holdout data. Validator uses an independent holdout split (different seed) from the one Trainer used.
4. Distinct sign-off artifact. Validator's promotion approval is a separate file (validator_sign_off.json) with its own integrity check.

This is the load-bearing control. Without it, Principle 7 ("SR 11-7 aligned") is asserted rather than enforced.

§ 5 — Decision rights

The user holds final authority on everything that affects (a) live capital, (b) the Charter, or (c) external publication.

§ 6 — Verifiable artifacts (the publishing standard)

The Charter mandates that every claim made to outside capital must trace to a machine-verified artifact stored in OneDrive or Postgres. The artifact inventory:

If a claim cannot point to an artifact, the claim is removed from external materials until the artifact exists.

§ 7 — Escalation policy

The user is the escalation destination for the following triggers (the program never silently resolves any of them):

1. Any configuration remains BLOK after Phase A+B+C across 3 outer passes (structural strategy×asset mismatch).
2. HAI Health Gate fails on >25% of a strategy's configs after retraining (methodology or pipeline defect).
3. Adversarial AUC ≥ 0.85 across a strategy (training data window contains regime break).
4. Sentinel detects live PF drop ≥ 20% vs backtest within 7 days of cycle ship (possible execution or OOS issue).
5. Drift detector flags an active production model.
6. Any compliance-block field in the Heat Map is false.
7. Charter amendment proposed by Adjudicator.

Adjudicator frames every escalation as a three-option ask to the user, with the Charter clauses cited and the trade-off articulated. The user's decision is recorded with timestamp and rationale; outcomes are tracked so the program learns from its decisions.

§ 8 — Calibration cycle governance (RX cycles)

The program operates in discrete RX cycles. Each cycle is the atomic unit of calibration and audit.

RX-Cycle Lifecycle
────────────────────────────────────────────────────────────────
   START → [Step 0]  Heat Map read (prior cycle, alerts, escal.)
         → [Step 1]  HAI freshness check (Trainer)
         → [Step 2]  HAI Health Gate (Trainer)
         → [Step 2b] Validator independent sign-off
         → [Step 3]  Joint Pine+HAI calibration (Calibrator)
         → [Step 4]  Per-engine gate (DEFAULT or FX_MR profile)
         → [Step 5]  RCA + remediation (Phase A→B→C, keep-best)
         → [Step 6]  Heat Map emit (compliance block all-true)
         → [Step 7]  Mirror + Tracker
   END  → cycle artifact in OneDrive + Postgres event log

A cycle is complete only when:

1. 16/16 configs SHIPped (≥1 live engine each).
2. HAI manifest matches Pine cycle; all Validator sign-offs present.
3. Heat Map compliance block all-true.
4. Cycle JSON + producer snapshot mirrored to OneDrive.
5. Tracker updated.
6. No [BLOK] rows in summary.
7. If escalation fired, user has been notified.

Any cycle not meeting all seven conditions is incomplete and requires Adjudicator escalation before being declared done.

§ 9 — Charter amendment procedure

The Charter is editable only by the user, on Adjudicator proposal. Process:

1. Adjudicator drafts the amendment with rationale (typically triggered by a recurring escalation, an SR 11-7 update, or a strategic decision).
2. Amendment lands in /governance/charter_amendments/{date}_proposal.md.
3. User reads, signs off (signed commit), or rejects.
4. On sign-off, Charter version increments and the change log records: date, summary, rationale, agent that surfaced the need.
5. All agents reload the Charter at next workflow start.

No agent may modify the Charter directly. No agent may operate as though an unsigned amendment is in force.

§ 10 — External commitments

The program publishes to outside capital under the following commitments:

1. Marketing claims map to verifiable artifacts (§ 6). No claim is made that lacks live evidence.
2. The Seven Principles are the published architecture (§ 2). Marketing materials match Charter wording.
3. SR 11-7 alignment is fit-for-purpose, not a regulated bank-level claim. The program is institutional-grade systematic alpha; the SR 11-7 framework informs design choices but is not a regulatory submission.
4. Independent validation is genuine (§ 4.3). The Validator agent operates with cryptographic isolation from the Trainer, verifiable in the Anthropic billing dashboard and event log.
5. The user is the sole final authority (§ 5). All allocator material reflects that humans hold every consequential decision, not the agent program.

§ 11 — Change log

End of Charter. Authority resides with this document; subordinate operational rules live in `00 UI CLAUDE.MD`.