αQuant7Alpha
whitepaper · calibration pipeline · v1.0

How a strategy goes from a single canonical specification to a signed, deployable configuration set — and why specification-implementation divergence, not weak signal, is the failure we engineer against.

Q7 AEGIS AI — The Precision Calibration Pipeline

A technical whitepaper on the architecture and methodology of a governance-first, agent-led, fail-closed calibration factory

This document describes how the pipeline is designed to work. It is an architecture and methodology reference, not a status report: it specifies the modules, gates, agents, and rules that define the system in its intended form. It states no performance figures and makes no claim about the live certification state of any particular strategy — those live in the signed pipeline artifacts and the process monitor, not here.


Executive Summary

Q7 AEGIS AI is a governance-first, multi-agent system for producing algorithmic trading strategies that are provably what they claim to be — where the code that was calibrated is the code that ships, the strategy that was backtested is the strategy that trades, and an independent party has signed off on that identity.

The pipeline is an eight-module, linear, fail-closed sequence — M0 Scope-Lock through M7 Verdict — that proves structural integrity before it spends a calibration trial, requires an independent Validator to co-sign the exact shipped code SHA, and turns every known failure mode into a permanent, mechanized gate. Its organizing principle is that a trading edge is worthless without provable structural integrity and independent verification: a strong backtest number tells you nothing you can trust if the executing engine silently under-implements its own design, if the shipped artifact carries a different SHA than the certificate that blessed it, or if the entity that produced the strategy is the same entity that certified it.

The authority model is explicit. Python is the single golden execution source — every engine, parameter, risk control, and the exit kernel live in Python, and every trade runs in Python. The regenerated Pine reference on TradingView is a downstream copy produced from the Python and parity-verified against it; it is a visualization and fallback surface, never an authority and never a place a defect is fixed. Program authority keys on the Python core SHA.

The remainder of this document specifies the pipeline: the eight modules and what each proves, the six design principles that make the structure eliminate whole classes of failure, the seven-agent operating model that enforces producer ≠ verifier cryptographically, the technology stack, and the fleet hard rules — each a fail-closed gate.


Table of Contents

  1. Thesis & Program Goal
  2. The Eight-Module Pipeline
  3. Design Principles
  4. Operating Model & Non-Negotiables
  5. The Fleet Hard Rules
  6. What "Done" Means

1. Thesis & Program Goal

What Q7 AEGIS AI is

Q7 AEGIS AI is a governance-first, multi-agent system for producing algorithmic trading strategies that are provably what they claim to be. The product is a fleet of calibrated strategies — S1 through S6, with S7 as the integration and orchestration layer — each covering sixteen configurations (asset × timeframe).

Every strategy is anchored to a golden Python core (q7_prism_core_S{n}.py): the single execution authority, the language every trade actually runs in, and the sole source of engines, parameters, risk controls, and the exit kernel. A regenerated Pine reference on TradingView exists as a downstream artifact — produced from the Python and parity-verified against it — for chart visualization and user fallback; it is never the law and never a place a defect is fixed. Where a live futures venue requires it, a C#/NinjaScript port is a tertiary artifact that must match the Python. A per-config XGBoost model tandem — HAI — acts as a machine-learning entry gate: it vetoes entries that fail its admissibility threshold; it is not a directional forecaster and carries no accuracy claim.

The authority ordering is binding. Python is golden — the execution truth and the sole authority. The Pine reference is the downstream copy. If Python and the Pine reference ever disagree, the Python is right by definition: the fix is forward, in Python, and the Pine is regenerated from it. "Match the Pine" is never a valid remediation. This does not bless an incomplete Python: where the Python under-implements its own documented design intent, that is a live-trading defect in Python, to be fixed forward. Program authority keys on the Python core SHA, with the Pine reference demoted to a downstream attribute.

The program is deliberately not organized around finding an edge. It is organized around proving that a claimed edge survives contact with reality: that the code calibrated is the code that ships, that the strategy backtested is the strategy that trades live, and that an independent party — not the producer — has signed off on that identity.

The governance thesis

The founding thesis is uncompromising: a trading edge is worthless without provable structural integrity and independent verification. A backtest that reports a strong profit factor tells you nothing trustworthy if the golden Python engine silently under-implements its own design, if the shipped artifact carries a different SHA than the certificate that blessed it, or if the entity that produced the strategy also certified it. In each of those cases the number on the report is real and the strategy behind it is a fiction.

These are not hypothetical risks; they are the recurring failure modes a governance-first pipeline exists to defeat. The response is structural rather than procedural: make integrity a property the pipeline cannot advance without, rather than a discipline it is asked to remember.

The target: a self-proving calibration factory

The pipeline is a self-proving, self-repairing, fail-closed calibration factory that produces audit-grade, live-deployable strategies. Concretely, by design:

  1. Structure is proven before value is spent. Every strategy is driven to an honest Module-1 cornerstone GREEN — all structural checks passing, the certificate SHA-current to the shipped Python core, agent-signed, independently co-signed on that same SHA, and parity-verified (Python → Pine → C# where present) — before any calibration trial runs.
  2. The chain is linear and gated. A strategy proceeds through the eight modules (M0 → M7), no module beginning until the prior is GREEN, to a co-signed honest package satisfying the Deliverable Completeness Standard (ten mandated outputs). Honest means what it says: a config that genuinely has no edge, or that a sanctioned risk policy declines, ships as a documented BLOK rather than being inflated.
  3. A running pipeline is autonomous and self-repairing for known defect classes (stale cert → re-cert; missing risk module → install-and-halt-if-absent; key mismatch → reconcile; stripped shadow → flag-and-route), and escalates to the Adjudicator or USER for anything it cannot safely auto-resolve.
  4. An issue → remediation flywheel makes every new defect class a permanent, mechanized gate, so the rule set only ever tightens.
  5. The operating model enforces producer ≠ verifier cryptographically, with the independent co-sign a hard launch precondition: the launch gate refuses calibration or deploy without a SHA-current, agent-signed, co-signed GREEN certificate.

The authority hierarchy

The pipeline runs under one ordered authority hierarchy: USER → Program Charter → Operational Rules → agent prompts → code. An agent prompt cannot override the Charter; code cannot override an agent's mandate. When the pipeline meets something it cannot safely resolve, it does not guess — it escalates up that chain to the Adjudicator or the USER. The discipline throughout is honesty: a verdict of GREEN carries the full, defined weight of a proven cornerstone, or the word does not appear.


2. The Eight-Module Pipeline

The pipeline is eight linear modules aligned to the Pipeline Taxonomy and the 00–07 run-directory standard. No module may begin until the prior is GREEN.

ModuleNameRun-dir stageOwner (agent)
M0Scope Lock & Provenance00_scope_lockq7-structural-integrity (+ launch operator; USER ratifies registry)
M1Structural Integrity (the cornerstone)01_structural_certq7-structural-integrity (producer ≠ verifier)
M2Calibration02_calibrationq7-calibrator (+ q7-trainer for HAI)
M3Robustness & Certification03_robustnessq7-calibrator (+ q7-structural-integrity binding re-cert)
M4Deliverable Package04_deliverablesq7-calibrator
M5Independent Validation05_validatorq7-validator (OSS model + ed25519)
M6Live Execution & Arming06_deployModule-6X operator + UI Platform; USER arms
M7Verdict, Ledger & Currency07_verdictq7-adjudicator (+ sentinel, auditor)

GATE-ZERO (Fleet R0) sits above the chain: a strategy is admitted to calibration only when its Module-1 cornerstone is an agent-signed, SHA-matched GREEN and its Pre-Cycle Documentation folder is complete. Missing either is terminal.

A note on the R# namespace. Two different R# families appear in the program and must not be conflated. The Fleet Rules (R0 GATE-ZERO, R14 Python-golden, R15 parity, R16 HAI clamp, R17 restart-convergent scheduling, R18 cornerstone-wiring) are program doctrine. The launch-gate / pre-flight checks (R10–R19) are a separate, mechanized numbering inside the gate source — e.g. launch-gate R14 is min-score reachability (not Fleet R14), launch-gate R18 is HAI model-type = XGBoost (not Fleet R18). Where a rule is cited, its family is named.

Each module is a gate boundary that must be earned, never assumed. HONEST-UNKNOWN blocks like a FAIL: a check that could not be evaluated because a required reference was absent is recorded as HONEST-UNKNOWN and blocks GREEN — never a silent PASS.


3. Design Principles

The enhanced pipeline is not a faster version of a conventional one; it is a different shape. Every design choice below eliminates a class of failure at the level of structure, because diligence does not scale and structure does.

Principle 1 — Cornerstone first: prove structure before spending a trial

The load-bearing inversion is that Module-1, the Structural-Integrity Cornerstone, runs before Module-2 spends a single calibration trial (Fleet Rule R0, GATE-ZERO).

Module-1 proves the golden Python core is structurally faithful to its own design: legality of the regenerated Pine reference; engines that fire rather than merely declare; no dead searched dimensions (every searched knob is actually read by the Python executor); attribution by engine × direction; the hard-wired drawdown-utilization objective; formula-footprint parity against the design spec (catching a "stripped shadow" that a presence-only check would pass); calibrated — not hardcoded — HAI thresholds; core↔kill parity; and no hardcoded risk constants. A runtime ship-smoke requires at least one live engine to trade end-to-end; a static-only result is recorded as STRUCT-SMOKE-UNKNOWN, not a pass.

The gate is behavior-not-presence: a check suite backed by a gate-mutation harness that verifies each check actually fails on a seeded defect, rather than merely being present. A presence-only cornerstone can wave through live-trading defects — a close-only stop that books pierced losses as wins, a degenerate window-selector — that a behavior gate catches.

The economic argument is decisive: a clean core calibrates within the trial cap; a defective one burns thousands of trials and still ships nothing. A Module-1 defect masquerades as a Module-2 budget problem. Running structure first converts thousands of wasted trials into a fast, cheap, deterministic gate. Until the cornerstone is GREEN, agent-signed, SHA-matched, and ship-proven, all downstream calibration is advisory only.

Principle 2 — Fail-closed at every boundary

Each module boundary is a gate that must be earned. Fail-closed has three teeth that directly kill the recurring failure modes:

  • HONEST-UNKNOWN blocks like a FAIL. A check that could not be evaluated is never a silent PASS — the antidote to "we assumed it away."
  • SHA-currency is a first-class gate. A certificate is valid only if its SHA matches the shipped Python core. A GREEN whose SHA ≠ the shipped SHA is not a pass. This alone dissolves the "borrowed GREEN" class — a real signature on stale code.
  • No bypass path, of any kind. The launch gate is non-overridable: not an environment variable, not a signed token, not an exception. Override attempts are detected and logged as DENIED, never honored. The only way past a FAIL is to fix the failing check and re-emit a fresh, SHA-current GREEN.

The terminal discipline (M7) forbids ever emitting "production-ready / defect-free / perfect / optimal." Exactly one verdict per pipeline — GREEN / AMBER / RED — each carrying a mandatory residual-risk statement. A GREEN without a residual-risk statement, on a non-clean cornerstone, or on a raw (non-deflated) statistic is invalid and blocks deployment.

Principle 3 — Agent-led and linear

The pipeline is driven by chartered agents (§4), each holding an isolated identity so that producer ≠ verifier is cryptographic rather than procedural. The co-sign identity is an ed25519 key held by an independent Validator seat, distinct from any producer credential; the control plane asserts identity isolation before every judgment node and fails closed on a shared or duplicated signer.

"Linear" is a correctness property, not a workflow preference. Because Module-0 resolves the single authoritative Python core / params SHA and freezes the golden result set first, the tree/cycle-thrash failure mode — one run corrupting the next, results anchored to the wrong core, an HAI serve-SHA drifting from the calibrated SHA — is closed at the front: a legacy label-map artifact opens a STALE finding (RED), two candidate golden sources force a RED, and an HAI serve-SHA ≠ calibrated SHA is a forced RED. Every downstream module is then judged against one law, resolved once. The venue-aware registry (e.g. S1 vs S1_EDGEX) is this principle made concrete: a producer resolves its tree through the registry, never by memory, because pointing a producer at the wrong venue tree is exactly the wrong-law failure Module-0 exists to prevent.

Principle 4 — Independent co-sign as a hard gate

The independence principle is that the agent producing an artifact may never be the agent certifying it as shippable. The design makes the co-sign a hard launch precondition, not a post-hoc courtesy: the launch gate refuses calibration and deploy without a certificate that is simultaneously SHA-current, agent-signed (not a producer self-claim), and independently co-signed on that same SHA, with parity verified.

The Validator seat is a free, non-Claude OSS model (hosted locally) paired with an ed25519 cryptographic signature, and the authority it defers to is a deterministic honest-gate — the model reasons, but a deterministic gate decides, and the ed25519 signature is what makes the decision non-repudiable. The external witness that no in-repo code path can forge is the ed25519 signature together with the git-tracked Fleet Rules Ledger. A recompute divergence, a hash mismatch, a producer-self-signed verdict, or a shared signer blocks the ready-to-ship state.

Principle 5 — Autonomous, self-repairing, with clear escalation

Once a run starts it is an autonomous, ordinal, fail-closed process that is self-repairing for known defect classes. The repair behaviors map one-to-one onto real defect classes: stale cert → re-cert on current code; missing risk module → install and halt-if-absent; config-key mismatch → reconcile; stripped shadow → flag and route the config back to Module-1. Non-convergence within the trial cap is treated as a fail signal that re-routes the config to structure — a defect — never as a budget shortfall to be met with more trials.

Autonomy is bounded by an explicit escalation path: anything the system cannot safely auto-resolve routes to the USER or Adjudicator. This is codified in the clean-cycle discipline — a defect surviving two rebuild → re-proof loops forces Adjudicator / root-cause escalation ("don't grind the symptom"), and a mandatory re-entry audit re-runs on the applied artifact before the clean-cycle counter may increment.

Principle 6 — The issue → remediation flywheel

Verbal rules regress. The design institutionalizes the fix: an issue → remediation (IRR) self-improvement flywheel in which every defect class found becomes a permanent, mechanized gate. The durable substrate is a git-tracked Fleet Rules Ledger + audit gate that binds each hard rule to a permanent gate and is monotonic — rules only ever tighten. The estate becomes monotonically more correct: the set of gates only grows, and a defect can be fixed at most once before it is impossible to reintroduce silently.


4. Operating Model & Non-Negotiables

Q7 AEGIS AI is a governance-first program. The strategies are the product, but the operating model is the moat: a fleet of algorithms is only as trustworthy as the process that certifies each one, and the failure mode the design defends against is not a bad trade — it is a plausible-looking lie that clears the gate.

The seven-agent operating model

The program is operated by seven specialized agents, plus the structural-integrity cornerstone operator. Each has a single job, a defined trigger, and an isolated signing identity.

#AgentTriggerMandate
1CalibratorNightly, per strategySearches the parameter space; produces a calibrated cycle + deliverable package
2TrainerFreshness check before each cycleTrains / refreshes the per-config HAI (XGBoost) entry-gate models
3ValidatorAfter the Trainer, independentlyCo-signs the shipped Python core SHA; the only seat allowed to bless a ship
4SentinelContinuous, 10-minute tickWatches live serving for drift and halt conditions
5ResearcherWeeklyInvestigates new edges and defect classes; feeds Calibration
6AuditorMonthlyProduces signed audit packs for the cold store
7AdjudicatorEvent-drivenResolves escalations the pipeline cannot safely auto-resolve; owns the verdict

Isolated identities are the external integrity check

This is the load-bearing detail of the model: the seat that verifies is never the seat that produces. The independent Validator seat is an OSS, non-Claude model signing with an ed25519 key and deferring to a deterministic honest-gate as the authority. Per-agent identity isolation is the principle; the external witness that no in-repo code can spoof is the ed25519 signature plus the git-tracked Fleet Rules Ledger. It is the program's cheapest, hardest-to-forge integrity signal — proof that the co-sign was computed under the Validator's identity and not fabricated by the producer.

Producer ≠ Verifier ( ≠ Armer )

From identity separation follows the central independence principle: the agent that produces an artifact may never be the agent that certifies it shippable. The Calibrator produces; the Validator disposes. A cert asserting a strategy is honest-GREEN is meaningless unless it carries the independent Validator's ed25519 signature on the exact Python core SHA that shipped. A producer's self-claimed GREEN — however confident — is treated as unproven. For live execution (M6) the chain extends: producer ≠ verifier ≠ armer — the USER is the sole armer of live capital, and no agent may arm.

RACI

Every module has exactly one Accountable owner. The matrix makes producer ≠ verifier structural: the M2 producer (Calibrator) is never the M3 / M5 accountable party (Validator).

ModuleStruct-IntegrityCalibratorTrainerValidatorSentinelAuditorAdjudicatorUI PlatformUSER
M0 Scope LockRCIIIIAIA (registry ratify)
M1 Structural IntegrityR/ACIC (co-sign)IIIII
M2 CalibrationCR/ACIIIIII
M3 Robustness & CertC (re-cert)RCAIIIII
M4 Deliverable PackageCR/ACCIIIII
M5 Independent ValidationIIIR/AIICII
M6 Live Execution & ArmingIIIC (co-sign)CIIRA (arms)
M7 Verdict, Ledger & CurrencyCIICCCR/AII

Three Lines of Defense

  • 1st Line — own & operate the controls (the producers). The Calibrator, Trainer, the structural-integrity producer role, and the Module-6X operator / UI Platform build and run the pipeline and own the fail-closed gates embedded in their own modules. A first-line failure is a producer shipping a defect; the embedded gates are their own first check.
  • 2nd Line — independent oversight & challenge. The fail-closed gate framework itself (the Module-1 cornerstone, the launch gate, the producer defect-cert), the Validator (producer ≠ verifier co-sign on the shipped SHA), the Sentinel (continuous drift / halt monitoring), and the Adjudicator (escalation + decision records). They set the standard and challenge the first line — a producer cannot self-certify; the gate and the Validator must independently agree on the exact shipped SHA.
  • 3rd Line — independent assurance. The Auditor (signed audit packs to the cold store) plus the external witnesses no in-repo code can forge: the ed25519 signature provenance, the git-tracked Fleet Rules Ledger, and the append-only decision / issue ledgers. Third-line assurance means an external reviewer can trace any shipped config golden-Python-core → cert → co-sign → deployed artifact from artifacts alone, with no insider help.
  • Above the lines — the USER (accountable owner): ratifies registry authority and is the sole armer of live capital.

Technology Stack

Execution & modeling. Python is the golden execution source; every engine, parameter, control, and the exit kernel live here, with compiled hot paths (numba njit + Cython simulate_exit kernels on numpy/pandas). Pine v6 is the downstream reference, regenerated from the Python and parity-verified — never an authority. C# / NinjaScript is a tertiary per-venue port where a live futures venue requires it, matching the Python.

Search & AI. Optuna GP/TPE search under a fixed trial cap, with multiprocessing-spawn parallel workers. HAI is a per-config XGBoost entry-gate tandem plus scaler and regime features, admitted only above an embargoed discriminability floor (AUC > 0.55) and calibratable off; it is an entry veto, not a directional forecaster, and carries no accuracy claim. An in-pipeline retrain (capture → train → HAI-ON) keeps train-equals-serve, with a role-aware anti-starvation clamp.

Data. Real exchange order flow for live serving (CME GLBX.MDP3 mbp-1; venue-native feeds for crypto); an order-flow proxy is used for calibration only and is fail-closed on serve. Content-addressed parquet snapshots (SHA256 + leak-check + embargo).

Governance, gates & signing. A fail-closed Python gate suite (structural_integrity_gate, q7_preflight, parity_sync_gate, hai_confmin_gate, aggregate_mdd_gate, param_coverage_gate, no_hardcode_lint, intrabar_stop_gate, q7_tree_resolver, and the non-overridable q7_launch_gate), ed25519 signatures for the Validator co-sign, a locally-hosted OSS Validator model, and the git-tracked Fleet Rules Ledger.

Storage (three tiers). Hot — Postgres: agent events, escalation queue, decision records, model inventory, audit reports, and the issue / remediation ledgers. Warm — versioned store: golden Python cores, params, HAI models, the regenerated Pine, heatmaps, matrices, cert JSONs, packages, the canonical registry, governance docs — one canonical copy per algo·venue. Cold — quarterly signed snapshots and sealed audit packs.


5. The Fleet Hard Rules

Every rule below is a fail-closed gate. A rule that lives only in prose is eventually forgotten by someone under deadline pressure; a rule that lives in a gate that refuses to let the pipeline advance cannot be. In a governance-first trading program, the expensive failures are the ones that look like success — so each rule exists to make a specific plausible-looking lie impossible to ship.

R14 — Python is the singular golden source. Every engine, parameter, control, and implementation lives in Python, which is the execution truth and the sole authority. The Pine reference is a downstream, regenerated fallback — never an authority and never a remediation target. "Match the Pine" is never a valid fix: if Python and the Pine reference disagree, the Python is right by definition (fix forward in Python, then regenerate the Pine). The structural gate verifies Python consumption, not Pine parity: every searched dimension must be read by the Python executor, and every live gate / leg must be emitted by the Python core. A structural defect in Python is a live-trading defect. R14 does not bless an incomplete Python — under-implementing the design is a defect in Python.

R-PARITY — Python → Pine (→ C#) parity at inception and at output. The golden Python is the truth; the regenerated Pine must match it; the C# port, where it exists, must match both. Parity is enforced at two ends: at inception the scripts must be structurally aligned before calibration begins; at output the Python results, the regenerated Pine, the C#, the heatmap, and the matrix must all reflect the same calibrated cycle. The failure this prevents is a strategy that backtests beautifully in Python while shipping a Pine and a dashboard describing a different, older configuration — a live surface that does not match its own evidence.

R-LIVEOF — live trading requires real order flow; the proxy is calibration-only. Because charting sources cannot fetch true exchange order flow, calibration uses an order-flow proxy. Live trading may not. Live serving must consume real order flow, fresh and scale-matched, and apply the calibrated order-flow score to that real feed verbatim — no boost, no rescale, no silent proxy-fallback. If the real feed is absent, stale, or scale-mismatched, the system fails closed and halts rather than substituting the proxy.

DD policy — preventive sizing off the true peak, with a hard true-peak kill. The sanctioned policy is preventive: size to headroom off the account's true (up-only) peak, tightening through defined bands, with a hard mark-to-market kill at the true-peak ceiling. Drawdown constants are calibratable, never hardcoded, and a binding whole-account aggregate drawdown gate governs the fleet, not just single configs. A reactive kill that resets its own reference peak downward can walk drawdown past the ceiling it is meant to enforce — a ceiling wired shut at the wrong value, or one a reactive kill can step through, is worse than no ceiling: a false promise of safety.

OWN-CORE — every algo owns its own core, engines, and models. No strategy may borrow another's core (q7_prism_core_S{n}.py), engines, or models. A shared core creates silent cross-contamination: a strategy that looks up entry-gate models keyed to a different strategy finds nothing valid, vetoes everything, and reports zero trades — a fail-closed deny-all with no visible error. Every algo standing on its own core is what makes a defect local instead of fleet-wide. Any cross-algo import of a risk or commission constant is a candidate violation and is gated.

STOP / INTRABAR — the intrabar high/low must drive the stop trigger. A stop must be evaluated against each bar's intrabar high and low, not only against the bar close. Evaluating stops on the close alone books a stop price that blew through mid-bar and closed back above as a win instead of the loss it was — a per-config distortion that can be catastrophic (an affected config's honest profit factor can collapse by orders of magnitude once intrabar piercing is booked correctly). A mechanized intrabar-stop gate, backed by the behavior-not-presence mutation suite, enforces it. A result is not honestly claimable while the engine is inventing wins it never had.

CO-SIGN — ship only on the independent Validator's SHA-current, ed25519 co-signed cert. A ship is permitted only when the independent Validator seat has co-signed the exact Python core SHA being shipped. The co-sign is an ed25519 signature from an OSS Validator model deferring to a deterministic honest-gate. The keystone root cause it closes is SHA-currency: the cert gate checks that the cert is current to the shipped SHA, not merely that its verdict field reads GREEN. A genuine, correctly-signed certificate whose SHA does not match the shipped artifact — a "borrowed GREEN" — certifies code that is no longer in the box, and is rejected.

Why this is load-bearing. Read together, these rules encode one principle: in a governance-first trading program, the expensive failures are the ones that look like success. A false BLOK hides real money on the table. A parity gap ships a live surface that contradicts its own evidence. A proxy substitution validates against a signal that will never trade. A mis-wired kill promises a drawdown ceiling it cannot hold. A borrowed core poisons a sibling silently. A close-only stop manufactures wins from losses. A borrowed GREEN certifies code that isn't there. None of these announce themselves. Mechanizing every one as a fail-closed gate — and making the independent ed25519 co-sign the external witness that the gate was honestly run — is how the program converts "we intend to be careful" into "the pipeline cannot advance unless we were."


6. What "Done" Means

For any single strategy, done is precise and non-negotiable: it has passed Module-1 with an honest, SHA-current, agent-signed, independently ed25519 co-signed cornerstone GREEN on its golden Python core, and then Modules 2–7 to a co-signed honest package meeting the Deliverable Completeness Standard — its ten mandated outputs: pre-cycle documentation, structural certificate, risk-control catalog, tri-script (or signed-exemption dual-script) conformance, heatmap, matrix, HAI artifacts, C# post-calibration port where the venue requires it, honest-gate result with the Validator sign-off, and the GREEN package itself — plus a content-hashed dossier and a reproducer.

A package is honest in the strict sense: a config that genuinely has no edge, or that a sanctioned risk policy declines, ships as a documented BLOK, not an inflated pass. Missing any required deliverable makes the package INCOMPLETE, not a percentage.

For the program, done means this holds for every strategy S1–S6, produced by an autonomous, self-repairing, fail-closed pipeline whose every known defect is a permanent mechanized gate, and whose entire chain from golden Python core to deployed live artifact is externally auditable — without a single borrowed GREEN or stale cert. Live arming is a standing, USER-accountable gate on top of all of it: no pipeline is armed without compound-GREEN, an independent co-sign, and per-venue USER authorization. The USER is the sole armer of capital.

The pipeline does not promise perfection — the terminal rule forbids the word. It promises something more defensible and externally auditable: that when a strategy ships, the GREEN describes the golden Python core that trades, the co-sign was issued by an independent ed25519 identity on that same SHA, the structure was proven before a dollar of calibration was spent, and every failure the estate has ever seen has already been turned into a gate that cannot be silently reopened.

annex

The pipeline architecture

The companion blueprint maps the same eight stages as a stage-gated flow across seven chartered swimlanes — narrative, gates, tech stack, and guardrails per stage.

Agent-Led Precision Calibration — Pipeline Architecture (Blueprint)open / download pdf ↗

Calibrated, not hand-tuned.

Every shipped configuration is independently re-derived before it trades. See the system it produces, or read how the broader platform works.