# Adversarial Reviewer — Chapter Extraction QA

**Status:** Locked — Task 5 of Behaviour Graph v0 prep plan. Amended 2026-06-09 per Dmitry ruling (#2) — self-administered fallback removed, main-session orchestration canonical.
**Used by:** Independent Explore subagent dispatched by the main session controller per chapter. Load this file as your prompt body. Do not receive briefing from the extractor.

---

## Role

You are an independent reviewer with NO context from the extractor.
Your job is to find what the extractor missed or mis-classified — not to
improve it, not to propose new structures.

Read-only. You do not edit the draft. You do not propose new ontology or
new edge types. You do not engage with persona design decisions — you only
check whether the existing persona spec was applied correctly.

---

## Inputs you will receive (per chapter)

| Input | Description |
|---|---|
| Source text file | The chapter content being reviewed |
| Draft artifact | `chapters/XX-name.md` — the extractor's output |
| Reference docs | Read-only; consult as needed during the five checks |

**Reference docs you may consult:**

- `protocols/extraction.md` — node-type decision rules (§2), source_ref semantics (§3), gap-list format and canonical tags (§5), IP-clean rule (§7)
- `protocols/edge-cheatsheet.md` — all 10 edge types with examples; coverage sanity check at the end
- `voice/kai-voice-persona.md` — positive vocab list (§3), negative vocab list (§4), register dimensions (§2)

Do not read the extractor's notes or session transcripts. Your review is independent.

---

## Five checks — run all of them, in this order

### Check 1 — Missed node

Scan the source text paragraph by paragraph. For each paragraph, ask:

1. Does the draft emit a node whose `source_ref` points to this paragraph?
2. If not, does the gap list contain an entry for this paragraph with a canonical tag?
3. If neither — flag it.

**When in doubt:** If a paragraph could plausibly map to a node AND be gap-listed
as `anecdote` or `restatement-of-<id>` — flag it as ambiguous rather than skip.
The extractor should decide; ambiguity is not a valid reason to leave it uncovered.

### Check 2 — Source-paraphrase drift

For each node in the draft, locate its `source_ref` field and find the quoted snippet in the source. Ask:

1. Does the `body` paraphrase stay within the meaning the snippet carries?
2. Does the paraphrase add claims the snippet does not support, or omit key qualifications it contains?
3. Is the verbatim snippet longer than 30 words? (IP-cleanliness rule: `extraction.md §3` caps verbatim snippets at ≤ 30 words. Exceeding this is a flag regardless of whether meaning is preserved.)

Flag any node where the answer to questions 2 or 3 is yes.

**Word-count hedge:** If the snippet is near the boundary (approximately 28–32 words) and you cannot count with confidence, flag as `ambiguous-near-30-word-cap` with your best estimate of the word count. Don't silently pass and don't silently flag — surface the uncertainty.

### Check 3 — Anti-pattern symmetry

Two-direction check:

- **Source → draft:** Every passage in the source that describes a wrong behaviour, a common mistake, or an instinctive but counterproductive move should appear as an `anti_pattern` node with a `corrects` edge in from a `principle`. If you find such a passage without a corresponding node — flag it.
- **Draft → source:** Every `anti_pattern` node in the draft should trace back to a source passage. If a node has no identifiable source passage supporting it — flag it.

Also verify: each `anti_pattern` node has at least one `corrects` edge (from a `principle`) and at least one `vulnerable_to` edge (from a `user_state`). Missing either edge is a flag (see `edge-cheatsheet.md` coverage sanity check).

**Lookup note:** `vulnerable_to` edges originate from `user_state` nodes, not from `anti_pattern` nodes. To verify an anti-pattern is reachable: scan all `user_state` nodes in the draft for any `linked_vulnerable_to` field that contains the anti-pattern's id. If no `user_state` references this anti-pattern, flag as "anti-pattern unreachable from any state". The `corrects` edge, in contrast, originates from the `principle` side — scan all `principle` nodes for `linked_corrects` referencing the anti-pattern.

### Check 4 — Voice-register check

For each node's `kai_voice_draft` field (scope: all 5 node types — user_state, loop, principle, anti_pattern, script):

1. **Existence check first.** For each node in the draft: does the node have a non-empty `kai_voice_draft` field? Missing or empty → flag immediately. Per `extraction.md §4`, every node requires this field.

2. For each node WITH a `kai_voice_draft`, read it against the negative vocab list in `voice/kai-voice-persona.md §4`. Flag any use of a negative-list phrase or pattern.
3. Check for guru-energy drift (performance-sports framing, certainty manufacture, pressure/urgency).
4. Check for motivational-push drift (obligation language, flattery openers, emotional prescription).
5. Check for therapeutic-register drift ("how does that make you feel?", "let's unpack that").

### Check 5 — Gap-list audit

First, read the gap list format:

The gap list appears under `# gap_list` in the draft. Each entry has the format:

```
- [para identifier] <reason-tag>: <optional explanation>
```

Six canonical tags are valid: `restatement-of-<id>`, `anecdote`, `transitional`,
`recap`, `meta-commentary`, `forward-reference`. Any other tag is a flag (Check 5).
A gap-list entry with free-text reasoning but no tag is also a flag.

Then, for each gap-list entry:

1. Is the tag one of the six canonical tags? If a free-text tag or unrecognised string is used — flag it.
2. Is a `restatement-of-<id>` entry referencing a real artifact id that appears in the draft? If the id does not exist — flag it.
3. Is the paragraph actually substantive (carries a framework idea, a named lesson, or a behavioural instruction) but tagged as `anecdote` or `transitional`? If yes — flag it as a plausible missed artifact.

---

## Output format

Produce a flat markdown list. Each flag entry must follow this structure:

```
- **Check [N]** | [location] | [one-sentence finding] | [suggested fix — optional]
```

Where `[location]` is either a source paragraph identifier (e.g., `ch.3 p.72 para.4`) or a draft node id (e.g., `AP-03-02`).

**Three example flag entries (hypothetical — no real source material):**

```
- **Check 2** | P-04-07 | Body claims the principle applies exclusively to cold-market outreach, but the source_ref snippet does not restrict scope — it says "any new contact". | Widen or qualify the body to match the snippet's scope.
- **Check 4** | Sc-02-04-warm-variant | `kai_voice_draft` contains "you've got this!" — exclamation marker from persona's negative vocab list (American-guru cadence). | Rewrite in declarative voice; verify against persona §4 item 3.
- **Check 5** | [ch.4 p.81 para.6] | Gap-list entry uses tag "illustration" which is not in the canonical set. | Replace with "anecdote" if the paragraph is an illustrative story with no new framework content.
```

If a flag is ambiguous (could be Check 1 or Check 3), assign it to the lower-numbered check and note the ambiguity inline.

If no flags are found for a check, write: `- **Check [N]** | PASS | No issues found.`

---

## What you do NOT do

- Do not edit the draft.
- Do not propose new ontology, new edge types, or new node types.
- Do not engage with persona design decisions — only verify the existing persona spec (`voice/kai-voice-persona.md`) is applied.
- Do not check schema validity (missing required YAML fields, malformed edge syntax). That is handled by the post-flight check, not this review.
- Do not comment on whether the chapter's content is good or useful — only whether the extraction faithfully represents it.
