Annotated SOP — Competitor_deep_dive

This document annotates competitor_deep_dive — a production SOP, twelve steps DD01–DD12 — against the mechanics documented across this reference. Every mechanism named here is specified in its own document; this is where they are all exercised by one workflow.

NOTE — This revision carries the complete annotation layer. Verbatim per-step JSON — declarations, prompts, criteria — finalizes in the excerpt pass against the shipped SOP file, per the reference baseline. Function descriptions and structural readings below are the annotation; the excerpt is the artifact.

What this SOP exercises

Structural spine

DD01 ─▶ DD02 ─▶ DD03 ─▶ DD04 ─▶ DD05 ─▶ DD06 ─▶ DD07 ─▶ DD08
framing   targets  collect   fan-out  consolidate          extract
                                                      │
                                                      ▼
                          DD12 ◀─ DD11 ◀─ DD10 ◀─ DD09
                          review  synthesis hypotheses selection

Excerpt — structural spine of competitor_deep_dive. Exact dependency sets finalize with the verbatim excerpt.

Steps

DD01 — Engagement framing

Fixes the competitive set, scope, and success criteria for the dive. The engine hydrates the intake context; verification checks the framing is complete and internally consistent before anything downstream consumes it.

DD02 — Target resolution

Turns the agreed set into concrete competitor entities with identifiers. Structured output is verified before commit — an unresolvable target never becomes workflow state.

DD03 — Evidence collection

External gathering against the resolved targets. Tool calls run through the MCP sandbox, policy-attached: every call passes Cedar evaluation and the input schema gate before it executes.

DD04 — Per-target deep evidence (SUB_SOP)

The composition point. A child evidence procedure fans out per target; each child is isolated — own identity, checkpoint trail, budget envelope — and the join merges only terminal artifacts into the parent. This is the step that exercises regeneration bounds and the circuit breaker: a child failing deterministically parks with its signature attached rather than storming.

DD05 — Consolidation

Normalizes the joined evidence into one structured corpus. Hydration references artifacts by checksum; nothing is copied or mutated.

DD06 — Capability analysis

Reads the corpus into capability claims, each carrying evidence references. The verifier checks claims against the input context it can actually see — the scope rule from verification blocks in operation.

DD07 — Positioning analysis

Derives positioning and movement reads from the capability layer. Same loop: proposal, verdict, critique back-edge if the criteria fail, bounded per attempt.

DD08 — Move extraction

Extracts discrete competitor moves from the analysis. The output contract is the move list that DD09 selects from.

DD09 — Move selection

Selects the salient subset of extracted moves. The output carries selection counts — and this is where honest scarcity lives: zero moves selected is a valid outcome, recorded as the self-attesting count in the sealed artifact. The engine does not invent moves to select; when the input contains none meeting the criteria, the artifact says so.

DD10 — Hypothesis generation

Consumes DD09's selected moves and generates competitive hypotheses. Under a zero selection, the correct output is the zero-case result:

{ "selected_count": 0, "hypotheses": [] }

Excerpt — hypothesis-generation output shape under zero selection, competitor_deep_dive DD10.

The step's verification block carries the zero-case exemption: the self-attesting empty result passes, because criteria that cannot pass on empty make the step unfinishable — no retry creates data that does not exist.

DD11 — Synthesis

Assembles findings into the deliverable. Depends on DD10; under the zero case it hydrates the empty selection and synthesizes on the acknowledged gap rather than blocking.

DD12 — Review and delivery

The final gate. Human review through the HITL ladder before release; the deliverable artifact seals only on resolution.

The zero-case chain, end to end

The DD09 → DD10 chain is the annotation this reference points at when it says the system has run in anger:

The authoring defect this chain closes — selection-dependent criteria without an empty-case exemption — is documented as a closed defect class in retry and recovery. A step made unfinishable by its own criteria deterministic-fails into the circuit breaker, not into a retry loop; the fix is authoring, and the SOP above carries it.