ID-71 Fleet-Graduation Framing Record

This record captures the fleet-graduation mechanism for ID-71’s headless-agent surface — how the headless fleet grows after launch — and the boundary it draws around what ID-71 itself ships. It is a framing/record artefact only: it asserts no new code and builds nothing. It documents the mechanism (B-INV-19 / M19) and cross-references the invariants that govern it (B-INV-7, B-INV-18, B-INV-21) so the boundary is unambiguous.

Wave 3 — Fleet-graduation framing ({71.28})

Recorded 22/06/2026. Satisfies B-INV-19 (M19, fleet additive / Task-gated / metric-gated) and frames its dependents B-INV-7 (M7, per-workflow auto-apply off at launch, earned), B-INV-18 (full fleet is post-launch graduation, not launch scope), and B-INV-21 (the single MVP pilot recipe is pilot-gated). No KH code path is created, modified, or re-enabled by this slice — it is a framing + boundary record only. ID-71 builds no fleet agents.

The mechanism (B-INV-19 / M19)

The headless-agent fleet is not launched big-bang. It grows additively, one Task at a time, and each addition is metric-gated on ID-104. The four governing statements:

1. The fleet grows ADDITIVELY, per-Task — no big-bang fleet launch

There is no “ship the fleet” event. Each new headless agent graduates into the launch surface via its own Task (its own spec chain + Subtasks + Checker gate), layered additively on the single outcome-grouped MCP server (Option C on Option A — B-INV-25 / surface-design-record “Single human-facing server + fleet-additive”). A new agent consumes the same consolidated entries; it does not introduce a parallel surface. Per B-INV-19, fleet additions are Task-gated — added with a Task + metric gate, never without one. This is the post-launch graduation posture restated across PRODUCT (Non-goals: “the fleet is post-launch graduation, additive, grown per-Task as ID-104 metrics earn it”) and TECH (§Context: “full fleet = post-launch graduation”; M18/M19/M21).

2. Each graduation is METRIC-GATED on ID-104

A new headless agent graduates only once its ID-104 quality metric clears the touchpoint’s threshold. This is the in-house WS-5 graduation metric: the per-workflow quality metric that earns graduation is computed on-platform, on KH’s own ID-104 infrastructure (the graduation_metric field on the AgentEvalContract consumption surface — TECH §OQ-2 / B-INV-15 / B-INV-19), surfaced through the in-house graduation path (lib/eval/graduation.ts metricFor). Per B-INV-15 this metric is never computed via Raindrop cloud and no client-data-derived trajectory egresses to it; evals are authored locally (Raindrop Workshop) but committed into KH’s KH-owned L3/L4 + baseline harness and run under KH CI (B-INV-14). The threshold a graduation must clear is the touchpoint’s ID-104 threshold — the eval, not a schema check, is the quality gate (B-INV-40).

3. auto-apply is the per-workflow REWARD of clearing that threshold

Auto-apply is OFF at launch — propose-only is the default (B-INV-7 / M7, cross-linked to surface-record {71.23}‘s propose-write framing). Every headless write path defaults to propose-only; no workflow ships with auto-apply enabled at launch; the per-workflow auto-apply switch exists but is verifiably off (TECH M6/M7: “per-workflow auto-apply switch exists and is verifiably OFF at launch”).

The auto-apply switch is the per-workflow reward of clearing the ID-104 threshold. It is flipped on per-workflow only, when that workflow’s ID-104 quality metric earns it (B-INV-7 ⟶ B-INV-19). Graduation and auto-apply are the same gate viewed twice: clearing the metric is what graduates a new agent and what earns its workflow the right to auto-apply rather than merely propose. Publication itself remains human-gated regardless (B-INV-6) — auto-apply earns through-flow within a workflow’s sanctioned write paths, not a licence to publish without a human gate.

4. NO fleet agents are built under ID-71

ID-71 builds no fleet agents. The launch headless surface is exactly:

the {O1/O4/O6 reads + W5.6} headless-complete set (B-INV-1 / B-INV-17 / M1–M5), PLUS
the one piloted recipe {71.27} — the single MVP goose recipe (B-INV-18 / B-INV-21 / §MVP: cron → remote-MCP → Claude → one O4 briefing → deliver to one outbound channel + write one propose-row into the queue).

No additional fleet agents are launch-gated (B-INV-18: “no additional fleet agents are launch-gated; Fail: additional fleet agents are required for launch”). The fleet is the explicit ID-71 Non-goal “the full agent fleet at launch”.

{71.27} is itself pilot-gated and currently DEFERRED. The one piloted recipe is the riskiest-assumption-first proof of the headless guarantee (B-INV-21) — goose is committed as the launch substrate only after the pilot validates the §7 must-be-true assumptions. Per the S391 OQ decision, {71.27} (the MVP pilot) is DEFERRED to a dedicated ops slice: the goose pilot is revisited post-PullMD-teardown. Until that pilot lands and passes, no recipe graduates and the fleet-graduation mechanism above has no first member beyond the deferred pilot itself.

The boundary (what this record asserts and does not assert)

Asserts: the mechanism — additive per-Task growth (1), metric-gating on ID-104 (2), auto-apply as the earned per-workflow reward (3) — and the boundary (4): the launch surface is the {O1/O4/O6 + W5.6} set plus the one (deferred, pilot-gated) recipe {71.27}.
Does NOT assert: any new code, any built fleet agent, any auto-apply enabled at launch, or any graduation independent of an ID-104 metric + an own Task. ID-71 reserves the mechanism; each graduating agent is delivered by its own future Task, born-evaluable against an ID-104 eval (B-INV-13) when it lands.

Pass condition (B-INV-19): fleet additions are Task-gated and metric-gated; auto-apply is the per-workflow reward of clearing the ID-104 threshold; no big-bang fleet launch; no fleet agent built under ID-71 — HELD.