@vela-science/canopus 0.7.0 → 0.8.0

package/dist/src/vela/types.d.ts

@@ -1,27 +1,11 @@
-import type { LandRoute, MissionRoots } from "../contracts/mission.js";
+import type { MissionRoots } from "../contracts/mission.js";
 export interface VelaInspection {
     version: string;
     roots: MissionRoots;
-    check: Record<string, unknown>;
-    proof: Record<string, unknown>;
+    status: Record<string, unknown>;
+    repository: Record<string, unknown>;
 }
 export interface VelaCommandResponse {
     ok: true;
     value: Record<string, unknown>;
 }
-export interface LandResult {
-    operationId: string;
-    receiptRoot: string;
-    recordId: string;
-    proposalId: string;
-    findingId: string;
-    route: LandRoute | "exact_retry";
-    originalRoute: LandRoute | null;
-    rawRoute: string;
-    detail: string;
-    acceptedEventCountBefore: number | null;
-    acceptedEventCountAfter: number | null;
-    acceptedEventDelta: number | null;
-    publication: Record<string, unknown>;
-    raw: Record<string, unknown>;
-}

package/dist/src/verifier/run.js

@@ -240,8 +240,8 @@ export async function runVerifier(options) {
     // still the same three bounded trees; it does not widen the readable set.
     const declaredReadRoots = [
         options.paths.input,
-        options.paths.artifacts,
         options.paths.verifierHome,
+        ...new Set(options.artifacts.map((artifact) => path.dirname(artifact.frozenPath))),
     ].map((entry) => path.resolve(entry));
     const readRoots = [
         ...new Set([

package/dist/src/workspace/prepare.d.ts

@@ -5,7 +5,7 @@ export declare class WorkspaceError extends Error {
 export interface WorkspacePaths {
     root: string;
     input: string;
-    landing: string;
+    frontier: string;
     work: string;
     output: string;
     artifacts: string;

package/dist/src/workspace/prepare.js

@@ -109,7 +109,7 @@ export async function prepareWorkspace(options) {
     }
     const root = await assertFreshOutsideRoot(options.sourceRepo, options.runRoot);
     const input = path.join(root, "input");
-    const landing = path.join(root, "landing");
+    const frontier = path.join(root, "frontier");
     const work = path.join(root, "work");
     const output = path.join(root, "output");
     const artifacts = path.join(root, "artifacts");
@@ -130,37 +130,37 @@ export async function prepareWorkspace(options) {
     ]);
     try {
         await gitText(runner, ["git", "clone", "--no-hardlinks", "--no-checkout", "--", await realpath(options.sourceRepo), input], root, home, timeoutMs, maxOutputBytes);
-        await gitText(runner, ["git", "clone", "--no-hardlinks", "--no-checkout", "--", await realpath(options.sourceRepo), landing], root, home, timeoutMs, maxOutputBytes);
+        await gitText(runner, ["git", "clone", "--no-hardlinks", "--no-checkout", "--", await realpath(options.sourceRepo), frontier], root, home, timeoutMs, maxOutputBytes);
         await gitText(runner, ["git", "checkout", "--detach", options.gitCommit], input, home, timeoutMs, maxOutputBytes);
         // Vela publishes exact scientific deltas to the current ref. Keep the
-        // immutable input detached, but give the isolated landing clone its own
-        // disposable local branch so publication never depends on caller state.
-        await gitText(runner, ["git", "checkout", "-B", "canopus-landing", options.gitCommit], landing, home, timeoutMs, maxOutputBytes);
-        const [commit, tree, status, landingCommit, landingTree, landingStatus] = await Promise.all([
+        // immutable input detached, but give the isolated control clone its own
+        // disposable local branch so inspection never depends on caller state.
+        await gitText(runner, ["git", "checkout", "-B", "canopus-frontier", options.gitCommit], frontier, home, timeoutMs, maxOutputBytes);
+        const [commit, tree, status, frontierCommit, frontierTree, frontierStatus] = await Promise.all([
             gitText(runner, ["git", "rev-parse", "--verify", "HEAD^{commit}"], input, home, timeoutMs, maxOutputBytes),
             gitText(runner, ["git", "rev-parse", "--verify", "HEAD^{tree}"], input, home, timeoutMs, maxOutputBytes),
             gitText(runner, ["git", "status", "--porcelain=v1", "--untracked-files=all"], input, home, timeoutMs, maxOutputBytes),
-            gitText(runner, ["git", "rev-parse", "--verify", "HEAD^{commit}"], landing, home, timeoutMs, maxOutputBytes),
-            gitText(runner, ["git", "rev-parse", "--verify", "HEAD^{tree}"], landing, home, timeoutMs, maxOutputBytes),
-            gitText(runner, ["git", "status", "--porcelain=v1", "--untracked-files=all"], landing, home, timeoutMs, maxOutputBytes),
+            gitText(runner, ["git", "rev-parse", "--verify", "HEAD^{commit}"], frontier, home, timeoutMs, maxOutputBytes),
+            gitText(runner, ["git", "rev-parse", "--verify", "HEAD^{tree}"], frontier, home, timeoutMs, maxOutputBytes),
+            gitText(runner, ["git", "status", "--porcelain=v1", "--untracked-files=all"], frontier, home, timeoutMs, maxOutputBytes),
         ]);
         if (commit !== options.gitCommit ||
             tree !== options.gitTree ||
-            landingCommit !== options.gitCommit ||
-            landingTree !== options.gitTree) {
-            throw new WorkspaceError(`checkout root mismatch: expected ${options.gitCommit}/${options.gitTree}, observed ${commit}/${tree} and ${landingCommit}/${landingTree}`);
+            frontierCommit !== options.gitCommit ||
+            frontierTree !== options.gitTree) {
+            throw new WorkspaceError(`checkout root mismatch: expected ${options.gitCommit}/${options.gitTree}, observed ${commit}/${tree} and ${frontierCommit}/${frontierTree}`);
         }
-        if (status !== "" || landingStatus !== "") {
+        if (status !== "" || frontierStatus !== "") {
             throw new WorkspaceError("exact checkout is unexpectedly dirty");
         }
         await sealTree(input, options.maxEntries ?? 200_000);
-        return { root, input, landing, work, output, artifacts, home, velaHome, verifierHome };
+        return { root, input, frontier, work, output, artifacts, home, velaHome, verifierHome };
     }
     catch (error) {
         await cleanupWorkspace({
             root,
             input,
-            landing,
+            frontier,
             work,
             output,
             artifacts,

package/docs/EVALUATION.md

@@ -0,0 +1,142 @@
+# Canopus and Vela evaluation
+
+Canopus is useful only if it turns a fixed model and task budget into more
+verified, repairable, and reviewable work than a simpler runner. Vela is useful
+only if its state and authority contracts make review, reuse, correction, and
+handoff safer or cheaper than ordinary files, Git, and exact-lock baselines.
+
+Evaluation therefore tests four claims separately:
+
+1. **Canopus execution lift:** with the same model, task, information, tools,
+   verifier, and budget, Canopus improves independently verified completion or
+   reduces invalid artifacts.
+2. **Vela state lift:** with fixed work products, Vela improves premise
+   selection, replay, correction, review, or authority integrity.
+3. **Combined-system efficiency:** Canopus and Vela increase correct scientific
+   dispositions or reusable verified progress per all-in cost and expert-hour.
+4. **Adoption:** a cold user can reproduce, interpret, and continue real work
+   without maintainer coaching or replacing their existing workbench.
+
+None of these claims is implied by the others. A verifier pass is not
+scientific acceptance. Internal replay is not independent reproduction. One
+useful frontier result is not evidence of a repeatable discovery engine.
+
+## Release gates
+
+Every report places these gates above aggregate outcomes:
+
+- zero unauthorized accepted-state transitions;
+- zero human, repository, or provider credential leaks;
+- zero verifier-to-acceptance conflation;
+- zero undetected registered-history tampering;
+- zero hidden exclusion of registered targets or failed runs;
+- zero unreported benchmark-answer leakage;
+- exact replay of every reported supported case.
+
+A gate failure disqualifies the run as release evidence. It cannot be averaged
+away by task completion, model quality, or cost.
+
+## Comparison contract
+
+The smallest useful comparison includes:
+
+- a native model or benchmark-native baseline;
+- a native baseline with the same verifier and structured task facts;
+- a Canopus arm;
+- a Canopus plus Vela arm only when the task tests state, governance, or reuse.
+
+The model, task bytes, information, tools, verifier, evaluator, budget, retry
+rule, stopping rule, and primary outcome are frozen before usable model output.
+Both matched-capability and best-product comparisons may be reported, but must
+not be mixed.
+
+Registrations bind exact tasks, versions, roots, arms, assignment, seeds,
+budgets, scorers, audits, hard gates, exclusions, and publication rules.
+Amendments after usable output are visible corrections, never silent edits.
+
+## Outcomes and cost
+
+Reports keep these layers separate:
+
+- attempt;
+- artifact produced;
+- independent verifier result;
+- correct Vela route or scientific disposition;
+- independent reproduction;
+- downstream reuse;
+- external recognition.
+
+Primary metrics depend on the registered claim. Common measures are verified
+completion, false scientific admission, epistemic rescue, intervention harm,
+model-swap resilience, correction localization, duplicate-work rate, and
+correct dispositions per expert-hour.
+
+All-in cost includes model tokens or price, compute, setup, repair, verifier
+time, human intervention, expert review, and operational overhead. A `10x`
+claim requires a matched denominator and quality threshold, a preregistered
+study, a held-out replication, and no hard-gate failure.
+
+## Benchmark order
+
+Use established suites before inventing Vela-specific tasks:
+
+1. Harness-Bench and a compact Harbor Index subset for harness comparison and
+   regression;
+2. AstaBench, verified ScienceAgentBench, CORE-Bench, or
+   SocSci-Repro-Bench for scientific execution and honest non-reproduction;
+3. Corral for evidence uptake and response to refutation;
+4. Continual Learning Bench for accepted-state inheritance and stale-state
+   harm;
+5. Formal Conjectures and exact frontier tasks for statement fidelity,
+   correction, and field evidence.
+
+Vela-specific suites are limited to invariants external benchmarks do not
+measure: authority, accepted-state inheritance, correction, canonicalization,
+multi-agent coordination, reviewer leverage, and cold adoption. They form a
+registry of focused suites, not one blended leaderboard score.
+
+## Immediate evidence loop
+
+Before expanding the adapter surface:
+
+1. close or explicitly stop every existing registered Canopus experiment;
+2. preserve the July 26 Erdős rejected candidate and verifier-bound repair as
+   one canonical regression case;
+3. add a matched native Codex arm;
+4. generalize registrations only enough to support multiple tasks, arms,
+   seeds, and randomized blocks;
+5. retain benchmark-native scoring unchanged;
+6. add one InspectAI bridge and one Harbor or METR Task Standard bridge;
+7. publish failures, exclusions, roots, costs, and raw reproducible records.
+
+The existing `inheritance-001` ceiling tie is evidence against adding more
+agent-state machinery. The composition smoke supports only a narrow
+representation-compression claim. Neither result justifies a protocol object.
+
+## Simplification rule
+
+Evaluation support remains a removable Canopus layer. Raw records stay
+immutable and content-addressed; generated reports and web projections are
+disposable. Evaluation data does not enter Vela's canonical scientific log,
+and no benchmark database becomes a source of truth.
+
+For each Canopus or Vela subsystem, run a preregistered ablation when its value
+is uncertain. If a simpler structured baseline matches quality and safety with
+less friction, remove or narrow the subsystem. In particular:
+
+- reduce Canopus to a thin reproducible producer wrapper if its mission
+  machinery does not improve verified output;
+- preserve only Vela's smallest universal invariants if Git, DSSE, exact locks,
+  and a written reducer match its correction and authority behavior;
+- stop discovery-engine claims if fixed-denominator recognized yield does not
+  exceed the baseline;
+- change the adoption wedge if cold users require live maintainer
+  interpretation.
+
+The north-star question is:
+
+> Does the system produce more genuine, reusable science per scarce human
+> judgment?
+
+This document is an evaluation-layer contract. It introduces no Vela protocol
+object, authority path, workflow language, or canonical result store.

package/docs/MISSIONS.md

@@ -1,94 +1,56 @@
-# Missions
+# Missions and profiles
 
-Mission v1 is the current Canopus mission contract. Canopus owns only the
-**Produce** step in Vela's five-step product story: produce → preserve → check
-→ decide → reuse. The frontier Git repository preserves; Vela checks and
-governs standing; signed policy or a protected human decision decides; the
-Observatory and other replaceable readers support reuse.
+Mission v1 is the current advanced execution contract. A profile selects one
+bounded target, packet, objective, worker boundary, verifier capsule, result
+contract, and budget. Preparing a Mission binds the exact Git and Vela roots
+plus the Vela, Codex, container, packet, profile, and capsule identities.
 
-## Mission v1: current
+## Current lifecycle
 
-Mission v1 keeps the same four roles and authority boundary while adding a
-tool-enabled local worker. `mission prepare` selects the first ranked attack,
-derives the clean Git and Vela roots, registers the complete pre-existing
-strict blocker set, and copies the exact packet, native permission profile,
-structured-output schema, and verifier capsule into a portable bundle. The
-Codex binary, model, verifier image, exact Linux verifier platform, resource
-ceilings, and every copied byte are hash-pinned. Historical Mission v1 records
-without a platform retain their old replay behavior; newly prepared missions
-always bind one. Product-prepared missions also retain the selected profile's
-exact name and full root, including Defer-only runs; older Mission v1 records
-without that non-protocol field replay unchanged.
+```text
+profile → mission → run → replay → optional export → optional submit
+```
 
-The producer runs through the native Codex CLI under a default-deny platform
-profile: Seatbelt on macOS and Codex's Bubblewrap sandbox on Linux or WSL2. The
-writable workspace contains only the exact target packet; the full source
-checkout, Vela home, host home, and authentication file remain outside
-command-readable paths. Provider transport is available only to the Codex
-process. Shell commands have no network access.
+- A **Run** is local orchestration evidence. It never mutates a frontier.
+- A successful Run may **export** one authenticated Vela Submission.
+- **Submit** is a separate explicit action that asks Vela to register the
+  Submission as a pending Proposal.
+- Mechanical verifier output is not a Vela Verification Record.
+- Neither Canopus nor its verifier creates a Decision, Event, or Standing.
 
-Worker status is producer completion, not verifier or scientific standing.
-`success` means the worker supplied every artifact byte required by the output
-contract and explicitly leaves verification pending. Only such a draft proceeds
-to the separate network-denied verifier. `null` means the bounded work produced
-no candidate; `failed` means the worker could not produce a contract-complete
-candidate or observed disqualifying evidence. Both are preserved in
-`engine-result.json` and stop before verification or Receipt landing. After a
-verifier pass, Canopus publishes exactly the frozen artifact sources in one
-unsigned non-authoritative Git commit and then calls `vela land`.
-The frozen verifier manifest reports the actual Docker boundary and bound Linux
-architecture; the older macOS-Seatbelt manifest remains only for Mission v0.
-`canopus inspect latest` includes safely stopped runs as well as completed runs;
-its failure projection distinguishes no landing attempt from an observed Vela
-effect that requires the retained landing-recovery evidence. Withdrawal's
-`latest` selector remains limited to completed, proposal-bearing runs.
+Worker outcomes remain simple:
 
-Defer-only Mission v1 bundles preserve their original zero-delta behavior. A
-profile may register `permit` only when it also freezes one closed positive
-`canopus.result-contract.v1` and a `vela.execution-binding.v1` over the full
-packet, profile, verifier-capsule, and result-contract roots. The worker result
-must be an exact computational success, the verifier must pass, its claim is
-replaced by the contract's exact canonical claim, and every required artifact
-kind must be present before Canopus authors the binding through Vela's Receipt
-builder. Any mismatch stops before landing. Vela alone evaluates the
-already-signed policy; Canopus then requires the registered route and
-accepted-event delta and reproduces the retained Receipt from a clean clone.
-Canopus does not treat its own Receipt verifier row as load-bearing Vela
-assurance.
+- `success`: every declared Artifact exists and the Run may proceed to the
+  frozen verifier;
+- `null`: the bounded attempt produced no valid candidate;
+- `failed`: execution was incomplete or disqualified.
 
-For exact construction profiles, prefer Vela-native `vela-witness` JSON and a
-packaged `vela-verify` executable. This gives the isolated producer verifier,
-Vela policy derivation, strict replay, and third-party reproduction one shared
-pure verifier and claim-fidelity contract. A target-specific wrapper is kept
-only when Vela has no suitable verifier; it is not duplicated for presentation
-or convenience.
+Only a verifier-passing `success` Run with at least one Artifact, one caveat,
+and a full `vela.execution-binding.v1` can be exported.
 
-## Mission roles
+## Isolation
 
-One Mission v1 bundle runs one explicit role. The role changes the worker
-instruction, not the trust boundary:
+The Codex worker receives only the exact packet and bounded writable workspace.
+The full source checkout, host home, Vela custody, authentication files, and
+verifier remain outside command-readable paths. The verifier runs separately
+with network and writes denied. A clean-clone verifier replay must match before
+the Run completes.
 
-- `producer` constructs the smallest candidate or preserves a null result;
-- `adversary` seeks a concrete counterexample or narrows the claim;
-- `verifier` checks correspondence between the candidate and declared tests,
-  while the separate frozen executable remains the mechanical verifier; and
-- `fidelity` checks that prose claims do not outrun frozen artifacts and
-  verifier facts.
+## Roles
 
-A research loop may fan these into separate missions against the same exact
-accepted roots. Each result lands its own Receipt and route. A repair mission
-names an immutable parent candidate, but a substantive downstream mission may
-inherit only state that Vela reports as accepted. Defer, a verifier pass, or a
-Canopus candidate digest is not an inheritance edge.
+The retained roles change the prompt, not the trust boundary:
 
-This deliberately avoids a workflow DSL, agent society, or second graph. Git
-stores the bytes, Vela stores authority and accepted lineage, and Canopus is
-replaceable orchestration over those primitives.
+- `producer` constructs a candidate or records a bounded null result;
+- `adversary` seeks a concrete counterexample or scope failure;
+- `verifier` checks correspondence while the frozen executable remains the
+  mechanical verifier;
+- `fidelity` checks that prose does not outrun the retained bytes.
 
-## Mission v0: historical replay only
+Each role produces its own Run. No role inherits pending or merely verified
+work as accepted state.
 
-Mission v0 is retained solely so frozen benchmark registrations and historical
-run records remain reproducible. It used the same four roles with a tool-free
-worker and the older macOS Seatbelt verifier manifest. Do not prepare new
-product missions with v0; use Mission v1. Historical v0 bytes and results remain
-unchanged.
+## Historical Mission v0
+
+Mission v0 remains readable for immutable historical replay. The current branch
+does not prepare or execute new v0 product missions. Use the release that
+created a historical Run when exact old behavior is required.

package/docs/RUN_RECORD.md

@@ -1,101 +1,79 @@
-# Canopus run records
-
-A completed run writes these local records beneath its run root:
-
-- `activity.jsonl`: append-only orchestration events linked by full SHA-256
-  digests, including the exact `vela next` offer digest and selected rank;
-- `candidate.json`: the frozen candidate and verifier facts;
-- `worker-events.jsonl`: the raw Codex event stream used as the tool trace;
-- `worker-final.json`: the exact final worker response;
-- `worker-stderr.bin`: the bounded raw worker stderr stream;
-- `engine-result.json`: the parsed worker outcome and usage;
-- `run.json`: the compact run record, exact roots, landing result, costs,
-  clean-clone reproduction result, and stage-typed observations;
-- `evidence-manifest.json`: content roots for the worker, run, candidate,
-  artifacts, verifier result, Receipt when present, and final frontier roots;
-- `projection.json`: a read-only view for another consumer;
-- `landing-command.json`: the exact argv, exit status, raw streams, and stream
-  digests observed at the potentially effectful `vela land` boundary;
-- `landing-observation.json`: the parsed raw Vela result, retained before any
-  Canopus interpretation.
-
-If anything fails at or after that boundary, `landing-recovery.json` records
-the last command, raw result when available, parsed route when available, and
-freshly inspected roots. `failure.json` points to that recovery record. A
-command timeout may have changed external state even when no complete stdout
-was captured, so recovery roots are authoritative over assumptions.
-
-These files are operational evidence, not Vela authority. The projection says
-so in its schema and can be rebuilt with `canopus inspect run.json`. Deleting
-the run-record files must not change Vela replay, a policy route, or accepted
-state.
-
-Completed runs now use `canopus.run.v1`. Its `observations` object separates
-three claims that must not be collapsed:
-
-- `worker_observations`: what the model reported or attempted;
-- `verifier_observations`: what the frozen mechanical verifier established;
-- `standing_caveats`: limitations that remain true after verification.
-
-Immutable `canopus.run.v0` records remain readable and replayable. Canopus does
-not rewrite them to manufacture the new evidence categories.
-
-For a public evidence surface, generate the publication bundle only after the
-successful run has reached Defer with zero accepted-state delta and matched
-clean-clone replay:
-
-```bash
-canopus publish-run /local/run/run.json \
-  --mission /local/run/mission/mission.json \
-  --repository https://github.com/vela-science/formal-conjectures-frontier \
-  --output ./public-evidence
+# Run, export, and submit records
+
+## Run
+
+A completed current Run writes `canopus.run.v2` beneath its private run root.
+Its contract is deliberately nonmutating:
+
+```json
+{
+  "schema": "canopus.run.v2",
+  "effect": "none",
+  "authority": "non_authoritative",
+  "submission": null
+}
+```
+
+The run root retains:
+
+- append-only orchestration activity;
+- exact worker events, final response, and bounded stderr;
+- candidate bytes and content-addressed Artifacts;
+- verifier identity and result;
+- clean-clone reproduction;
+- exact mission, source, runtime, budget, and evidence roots.
+
+`canopus show` projects these records. `canopus replay` reruns the frozen
+verifier. Deleting Canopus or its run directory cannot change Vela replay or
+Standing.
+
+## Export
+
+`canopus export` creates `canopus.submission-bundle.v1`:
+
+```text
+submission-bundle/
+  submission.json
+  manifest.json
+  artifacts/sha256/<full-digest>
 ```
 
-The new directory contains the `canopus.public-run.v1` projection, an exact
-root manifest, read-only Observatory import data, and commands to reproduce or
-inspect the pending proposal and retain additional verifier evidence. The
-commands do not accept, publish, push, deploy, or cross a human authority
-boundary. The public projection contains only mission and model identity, a
-bounded activity summary, claim and caveats, artifact/verifier/Receipt roots,
-route, accepted delta, usage, source/final commits, and reproduction commands.
-It cannot export a failed or admitted run. Never publish the raw run directory,
-isolated homes, authentication, private paths, or unrestricted logs.
-
-The run root also contains isolated checkouts and content-addressed artifacts.
-The landing clone uses a disposable attached branch so Vela can publish exact
-deltas; the immutable input clone remains detached and read-only. Successful
-runs delete the isolated Vela home and its agent-only key. Failed runs may
-retain local diagnostic state until explicit cleanup. Never publish a run root
-or Codex credential directory wholesale. After verification, Mission v1 makes
-one unsigned non-authoritative Git commit containing exactly the frozen source
-artifacts before invoking `vela land`; `activity.jsonl` records that commit,
-tree, and path set. The terminal Vela commit then contains the Receipt, activity
-record, proposal, and `records/artifacts/sha256/<digest>` copies. This ordering
-keeps `vela.lock` and every clean Git checkout self-contained.
-
-A `--no-land` run writes `canopus.diagnostic-run.v1`, invokes the same frozen
-worker and verifier path, and leaves the source frontier at its starting commit
-and tree. It has no Receipt or proposal. A landed product run performs all work
-in isolated clones, verifies the clean clone, then fast-forwards the clean local
-source checkout to the exact verified landing commit. It never pushes a remote.
-
-Product output must live outside the source frontier and outside known
-cloud-synced Desktop or cloud-storage roots. Docker bind mounts over cloud-backed
-paths can stall without producing a verifier verdict, so Canopus refuses that
-placement rather than weakening the verification timeout.
-
-`route: defer` with `accepted_event_delta: 0` means the Receipt v1 record is
-pending human review. It is a successful producer handoff, not scientific
-acceptance. `route: permit` is valid only when an already signed Vela policy
-admits the exact proposal; Canopus still does not hold a human key.
-
-## Budget semantics
-
-The mission hard-bounds prompt bytes, artifact bytes, attempts, spawned
-research-lane processes, and captured research-lane output. The same ledger
-covers the first verifier and clean-clone verifier. `max_observed_tokens` is an
-honest postcondition over provider-reported usage; the Codex subscription
-surface does not expose a portable pre-call token cutoff. Git and Vela are the
-control plane and retain their own fixed command timeout/output bounds. The
-mission therefore does not advertise a hard end-to-end subprocess or billing
-budget it cannot enforce.
+`submission.json` is a whole-body Ed25519-signed `vela.submission.v1`.
+Independent verifier output is named only as a verification requirement; it is
+not mislabeled as producer authority or a Vela Verification Record.
+
+The current worker contract keeps verifier status out of the Claim. Export
+fails closed if a retained older Run says verification is pending after its
+verifier passed or contains control bytes. In that narrow case the producer may
+pass `--claim` with `--scope-limit`; Canopus signs a corrected Submission,
+records that the wording changed after the run, and leaves the Run byte-for-byte
+unchanged. Arbitrary Claim replacement on a non-stale Run is refused.
+
+The producer key is ephemeral. It is not placed in run evidence, the portable
+bundle, or a retained capability store. A producer that independently keeps its
+own key may use Vela's direct withdrawal interface; Canopus does not add a
+second key lifecycle.
+
+## Submit
+
+`canopus submit`:
+
+1. verifies the bundle, Submission signature, Artifacts, source Git roots, and
+   exact Vela binary;
+2. keeps transport blobs outside the clone and lets Vela create their canonical
+   content-addressed paths inside the repository-authority transaction;
+3. performs the Vela registration in a disposable exact-head clone;
+4. requires `vela.submit-result.v1`, `pending_review`, and accepted-event delta
+   zero;
+5. fast-forwards the clean source checkout only after the registration is
+   complete.
+
+Submit does not create a Verification Record, Decision, Event, or accepted
+Standing.
+
+## Budgets
+
+Missions bound prompt bytes, Artifact bytes, attempts, processes, output, wall
+time, and observed provider tokens. The same verifier budget covers initial and
+clean-clone replay. Provider-reported token totals are verified post hoc; the
+subscription CLI does not expose a portable pre-call billing cutoff.