AutoQEC API Documentation¶
This document describes the public developer-facing interfaces currently
supported on main. It is intended as a stable entry point for contributors
who need to call the CLI, understand the core schemas, or consume run/round
artifacts without reading multiple plans and implementation files first.
For exact frozen field shapes, see:
docs/contracts/interfaces.mddocs/contracts/round_dir_layout.md
This file is a practical guide, not a replacement for those contracts.
1. Public CLI Interfaces¶
1.1 python -m cli.autoqec run¶
Primary purpose: run a multi-round no-LLM smoke loop using bundled seed
templates and write run-level artifacts under runs/<timestamp>/.
Example:
python -m cli.autoqec run autoqec/envs/builtin/surface_d5_depol.yaml \
--rounds 3 \
--profile dev \
--no-llm
Inputs:
env_yaml: path to anEnvSpecYAML file--rounds: number of rounds to execute--profile:devorprod--no-llm: required on the current public path; LLM orchestration remains a skill-driven flow rather than a plain CLI feature onmain
Behavior:
- Loads the environment via
load_env_yaml - Selects bundled decoder templates from
autoqec/example_db - Runs one
Runnerinvocation per round - Writes run-level and round-level artifacts
- Prints a machine-readable JSON summary containing
run_dir,rounds, andcandidate_pareto_path
Notes:
- The current public CLI path is a no-LLM smoke path
candidate_pareto.jsonis demo/reporting output only; it is not the authoritative verifier-owned Pareto front
1.2 python -m cli.autoqec run-round¶
Primary purpose: run one round from a specific env/config/round-dir tuple and
emit RoundMetrics as JSON on stdout.
Example:
python -m cli.autoqec run-round \
autoqec/envs/builtin/surface_d5_depol.yaml \
autoqec/example_db/gnn_small.yaml \
runs/manual/round_1 \
--profile dev
Inputs:
env_yaml: path to anEnvSpecYAML fileconfig_yaml: path to a decoder config YAMLround_dir: output directory for round artifacts--profile:devorprod
Worktree-aware options:
--code-cwd: absolute path to a worktree checkout--branch: branch name; required when--code-cwdis set--fork-from: parent branch or JSON list of parent branches--compose-mode: required when--fork-fromis a list--round-attempt-id: UUID minted at attempt creation time
Behavior:
- Loads the env and decoder config
- Validates worktree-related metadata through
RunnerConfig - Runs the round in-process or via the subprocess/worktree path
- Prints a
RoundMetricsJSON payload to stdout
Internal-only command:
python -m cli.autoqec run-round-internal
This is a hidden internal entrypoint used by the subprocess bridge. It is not part of the public CLI surface and should not be called directly by users.
2. Core Schemas¶
2.1 EnvSpec¶
EnvSpec defines the experiment environment. It answers: which code, which
noise model, which resource constraints, and which classical backend.
Top-level fields:
namecodenoiseconstraintsbaseline_decodersclassical_backendeval_protocol
Key practical notes:
code.sourceis the asset path consumed by the Runner- builtin env YAMLs live under
autoqec/envs/builtin/ - loaders may resolve relative paths against the env file location or repo root
2.2 RunnerConfig¶
RunnerConfig defines how one round should execute.
Core fields:
env_namepredecoder_configtraining_profileseedround_dir
Worktree-path additions:
code_cwdbranchfork_fromfork_from_canonicalfork_from_orderedcompose_mode
Practical interpretation:
- legacy path: only the core fields are required
- worktree path: provenance and branch-routing fields become part of the contract and are validated together
2.3 RoundMetrics¶
RoundMetrics is the canonical per-round result payload. It is written to
metrics.json and also emitted by run-round.
Key result fields:
statusstatus_reasonler_plain_classicaller_predecoderdelta_lerflops_per_syndromen_paramstrain_wallclock_seval_wallclock_svram_peak_gbcheckpoint_pathtraining_log_path
Worktree/provenance additions:
round_attempt_idreconcile_idbranchcommit_shafork_fromfork_from_canonicalfork_from_orderedcompose_modedelta_vs_parentparent_lerconflicting_filestrain_seed
Practical interpretation:
RoundMetricsis the output contract consumed by artifact readers, analysis helpers, and orchestration-side bookkeeping- any downstream tool that reads
metrics.jsonshould assume this schema rather than ad-hoc JSON keys
3. Output Artifacts and Their Consumers¶
3.1 Run-level artifacts¶
Common run-root files:
history.jsonlhistory.jsonlog.mdpareto.jsoncandidate_pareto.json
Meaning:
history.jsonl: append-only per-round recordshistory.json: aggregated run summary for simpler consumerslog.md: orchestration narrativepareto.json: authoritative verifier-owned Pareto frontcandidate_pareto.json: unverified demo/reporting front for CLI smoke runs
3.2 Round-level artifacts¶
Per-round files:
config.yamltrain.logcheckpoint.ptmetrics.jsonverification_report.mdwhen verification exists
Meaning:
config.yaml: exact decoder config used for the roundtrain.log: per-step loss tracecheckpoint.pt: saved trained model bundlemetrics.json:RoundMetricsJSON payloadverification_report.md: verifier output when available
3.3 Main consumers¶
- Analyst subagent reads
metrics.json - Ideator context reads
history.jsonlandpareto.json - Verifier reads
checkpoint.ptandconfig.yaml machine_statereadshistory.jsonl
For the authoritative layout and ownership rules, use
docs/contracts/round_dir_layout.md as the source of truth.
4. Source of Truth and Update Rules¶
When the public interface changes, this document should be updated together with the relevant source-of-truth files.
Update this document when any of the following changes:
- CLI command shape for
runorrun-round - top-level
EnvSpec,RunnerConfig, orRoundMetricsusage contracts - run / round artifact names, meanings, or consumer relationships
Also update, as applicable:
docs/contracts/interfaces.mddocs/contracts/round_dir_layout.mdREADME.md