Skip to content
Canonical

ID-71 Scope-Boundary & Carry-Forward Record

ID-71 Scope-Boundary & Carry-Forward Record

Section titled “ID-71 Scope-Boundary & Carry-Forward Record”

This record fixes the scope boundary of the ID-71 AI-tooling rationalisation and records the carried-forward inputs to the capabilities that graduate to their own future Tasks. It is a record/boundary artefact only: it asserts no new code and builds nothing. The three invariants it satisfies — B-INV-16, B-INV-17, B-INV-20 — are all explicitly NO-code-change boundary assertions. It is a sibling to the {71.28} Fleet-Graduation Framing Record (which fixes the fleet boundary) and the {71.11} Surface-Design Record (which anchors verdicts to outcomes); this record fixes the capability-scope boundary between them.

The outcome map used throughout (PRODUCT.md §C/§D): O1 find/answer, O2 revenue documents, O3 trust, O4 reorientation/briefing, O5 signal→action / intelligence-consumption, O6 exposure (five layers), O9 onboarding; W* are the per-outcome workflows.

Wave 3 — Scope-boundary enforcement + carry-forward ({71.25})

Section titled “Wave 3 — Scope-boundary enforcement + carry-forward ({71.25})”

Recorded 22/06/2026. Satisfies B-INV-16 (M16, W9.3 onboarding cross-reference only), B-INV-17 (M17, scope enumeration = {O1/O4/O6 reads + W5.6}), and B-INV-20 (M20, net-new capabilities NOT built under ID-71 — reserved-concept + own-Task pointer each). No KH code path is created, modified, or re-enabled by this slice — it is a boundary + carry-forward record only. All three invariants are NO-code-change assertions.

B-INV-16 (M16) — W9.3 onboarding is cross-reference only

Section titled “B-INV-16 (M16) — W9.3 onboarding is cross-reference only”

W9.3 (onboarding discovery→propose headlessness) is OWNED by the onboarding Task (O9), not ID-71. Per B-INV-16 (PRODUCT.md §A, ⇐ HC-6 / HR-4 / WS-6):

  • W9.3 is ABSENT from ID-71’s headless-complete enumeration (B-INV-1 / B-INV-17). The headless-complete set deliberately excludes W9.3 — ID-71 asserts no W9.3 headless guarantee and implements no W9.3 tooling.
  • W9.3 is PRESENT as a cross-reference only — a pointer to the onboarding Task, which owns the discovery→propose flow and will build it born-evaluable in its own group.
  • The create verb is NO LONGER onboarding-routed. It moved to ID-59 / {71.16} M-CREATE — create_content_item gains a write-to-canonical-store create-leg on ID-59’s file-first write-back substrate (TECH.md §M / §X intent #1; this retires PRODUCT OQ-1’s stated defer-to-onboarding fallback). The create-into-store leg is canonical-pipeline scope on the ID-59 substrate, not an onboarding concern.

Pass condition (B-INV-16): W9.3 absent from ID-71’s headless-complete enumeration and present as an onboarding cross-reference; create verb routed to ID-59 / {71.16} M-CREATE, not onboarding — HELD.

B-INV-17 (M17) — scope enumeration unchanged: exactly {O1/O4/O6 reads + W5.6}

Section titled “B-INV-17 (M17) — scope enumeration unchanged: exactly {O1/O4/O6 reads + W5.6}”

The ID-71 headless-complete launch scope is EXACTLY {O1/O4/O6 reads + W5.6} — unchanged by this record. This is the same set the landed {71.22} L4 enumeration encodes in scripts/mcp-eval/headless-complete-set.ts:

  • HEADLESS_COMPLETE_OUTCOMES = ['O1', 'O4', 'O6', 'W5.6'] — the declarative source of truth the L4 suite drives MCP-only and the Checker confirms matches {O1/O4/O6 reads + W5.6} exactly (no extras, no omissions — B-INV-1).
  • The four members: O1 find/answer (find), O4 reorientation/briefing (get_reorientation, widened beyond KH state), O6 exposure five-layer (where_are_we_exposed), W5.6 re-syndication (trigger_intelligence_poll).

There is NO scope creep into net-new capabilities. W9.3 is cross-reference only (B-INV-16); write-back is sanctioned-destinations-only. This record adds nothing to the enumeration — it asserts the boundary the {71.22} module already encodes.

Pass condition (B-INV-17): scope enumeration matches {O1/O4/O6 reads + W5.6}; no scope creep into net-new capabilities — HELD.

B-INV-20 (M20) — net-new capabilities NOT built under ID-71

Section titled “B-INV-20 (M20) — net-new capabilities NOT built under ID-71”

Net-new product capabilities are NOT ID-71 deliverables. Each has a reserved surface concept + its own-Task pointer, and is explicitly NOT built here. ID-71 reserves only the surface concepts (A16 source-connection, A22 propose-confirm); the capabilities graduate to their own Tasks (RESEARCH §4 task-split map):

CapabilityOutcome / workflowReserved-concept / own-Task note
Sales triggersO5 W5.2 (sales-trigger→outreach)Reserved concept only; graduates as its own Task in the O5 group (see WS-10 carry-forward below). Not built under ID-71.
Marketing pipelineO5 W5.3Reserved concept only; graduates to its own Task in the O5 group. Not built under ID-71.
Renewal packsO2 W2.3Reserved concept only; graduates to its own Task (OQ-2 horizon). Not built under ID-71.
Trust trioO3 W3.1–W3.3Reserved concept only; each remains a net-new own-Task (W3.1 is explicitly NOT a member of the headless-complete launch set — B-INV-1 / B-INV-17). Not built under ID-71.
Proposal assemblyO2 W2.2Reserved concept only; graduates as the O2 W2.2 proposal-assembly own-Task thread (see WS-12 carry-forward below). Not built under ID-71.

Pass condition (B-INV-20): none of these capabilities is built under ID-71; each has a reserved concept + own-Task pointer — HELD.

Carry-forward record (B-INV-20, §X intent #4)

Section titled “Carry-forward record (B-INV-20, §X intent #4)”

Two RESEARCH inputs are recorded as carried-forward inputs to their O5/O2 own-Tasks so they are not lost when those capabilities graduate. Neither is built under ID-71. The Orchestrator will backlog both — so the provenance is recorded in this doc AND surfaced as backlog intents (see this slice’s return to the Orchestrator).

  • WS-10 — W5.2-home assessment. W5.2 (sales-trigger→outreach, O5-consumption) opens as its OWN Task in the O5 group, sequenced first. RESEARCH §4.1 found W5.2 does NOT belong inside the unratified sales-proposal-workspaces Phase-3 drafts — it is a different outcome (O5 intelligence-consumption vs O2 revenue-document-assembly) with a different data home: the live HubSpot↔Cowork MCP connector (not the sales_proposal_workspaces satellite). The sales-proposal Phase-3 build is a separate future Task whose four arm-a/arm-b substrate drafts still need Liam ratification + canonical-pipeline reconciliation before adoption.
  • WS-12 — proposal-writer exemplar. The in-repo proposal-writer skill is carried as a named skill-reuse input/exemplar to the O2 W2.2 proposal-assembly thread (NOT to W5.2).

Pass condition (B-INV-20 carry-forward): both recorded as carried-forward inputs to the respective own-Tasks — WS-10 with its live-HubSpot↔Cowork data-home assessment, WS-12 named as the O2 W2.2 exemplar; neither built under ID-71, neither silently dropped — HELD.

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

Section titled “The boundary (what this record asserts and does not assert)”
  • Asserts: the scope boundary — the headless-complete enumeration is fixed at {O1/O4/O6 reads + W5.6} (B-INV-17, matching the {71.22} module); W9.3 is onboarding-owned and cross-reference only with the create verb routed to ID-59 / {71.16} (B-INV-16); net-new capabilities are reserved-concept-only with own-Task pointers (B-INV-20); and the WS-10 / WS-12 carry-forward provenance.
  • Does NOT assert: any new code, any built capability, any change to the enumeration, or any W9.3 headless guarantee. ID-71 reserves the surface concepts; each net-new capability is delivered by its own future Task, born-evaluable against an ID-104 eval (B-INV-13) when it lands.