---
name: saturation-sweep
description: >-
  "What hasn't the sweep reached yet?" - Horizontal iteration in waves over
  declared branching axes (who else, where else, when else, who benefits
  elsewhere), with a novelty ledger per wave and a measured stop rule. Use
  when (1) an investigation risks stopping at the first coherent story,
  (2) "done searching" must be demonstrable rather than felt, (3) coverage
  across actors/regions/periods matters as much as depth, (4) designing
  multi-agent sweep waves. Stop when a wave adds under ~10% new material, or
  two consecutive waves move no verdict. Does NOT trigger for: single-fact
  lookups, quick answers, or vertical deep-dives on one already-found thread
  (use deep-investigation-protocol).
---

# Saturation Sweep

**Seed question:** *What hasn't the sweep reached yet?*

> *Relentless self-reflexive dialectical thinking that questions its own premises.*

## Core Principle

Vertical investigation digs where the story is; horizontal investigation asks
where else the story could be. Both are needed, but only the second can say
when searching is DONE: saturation is a measurement (novelty per wave), not a
feeling of completeness — the feeling arrives long before the coverage does.

**The anti-pattern this counters:**
```
❌ Searching until a coherent narrative forms, then stopping
❌ "I did several searches" with no record of which axes they covered
❌ Coverage claims that cannot name what was NOT reached
```

**The pattern this enforces:**
```
✅ Declare the branching axes BEFORE sweeping
✅ Sweep in waves; ledger the novelty of each wave
✅ Stop on the rule, not the feeling — and report where the sweep stayed thin
```

## When This Applies

**TRIGGER:**
- The completeness question, asked or implied: "How do we know we're done?",
  "What are we missing?", "Have we covered everything?", "Is that the whole story?"
- An investigation has produced one coherent narrative and is about to close on
  it — the vertical story satisfies, but nobody has asked where else it could live.
- Coverage across actors, intermediaries, regions, jurisdictions, language-publics,
  or time periods matters as much as depth on any single thread.
- Designing or running a multi-agent sweep (waves of blind workers over branching axes).
- A claim of thoroughness needs to be auditable — a ledger someone else can check —
  not asserted from a feeling of having looked enough.

**DO NOT TRIGGER:**
- Single-fact lookups or quick answers (a definition, a date, a capital city) — no
  coverage question is in play.
- A vertical deep-dive on one already-found thread or one named document — that is
  `deep-investigation-protocol`, not breadth.
- Verifying a specific found claim rather than mapping breadth — that is
  `iterative-verification`.

## The Sweep

1. **Declare axes.** Before wave 1, list the branching axes for THIS
   investigation. Standard set (extend, don't shrink): who-else (actors,
   intermediaries, beneficiaries) · where-else (regions, jurisdictions,
   language-publics) · when-else (earlier precedents, later echoes) ·
   who-benefits-elsewhere (adjacent markets/policy areas). An axis declared
   and skipped must appear in the thin-slot; an axis never declared is
   invisible — that is why declaration comes first.
2. **Wave.** One pass across all declared axes (queries or agents — see
   `assets/agent-prompts.md` for the multi-agent recipe). New material is
   logged per axis.
3. **Ledger.** After each wave, fill one ledger row (format below). Novelty =
   new entities + new claims, as a share of the running total.
4. **Stop rule.** Stop when a wave's novelty is under ~10%, OR two consecutive
   waves move no verdict in the per-claim table. Both conditions are
   measurements against the ledger — cite the rows when declaring saturation.
5. **Report the thin spots.** Mandatory, honest: where did the sweep stay thin
   (axes shallowly covered, languages not searched, platforms unreachable),
   why, and what could hide there.

## Novelty Ledger (format)

| Wave | Axes swept (queries/agents per axis) | New entities | New claims | Verdicts moved | Novelty % |
|------|--------------------------------------|--------------|------------|----------------|-----------|

## Mandatory Output Slots

| Slot | Contents | Invalid when |
|------|----------|--------------|
| **Axes declared** | The branching axes, declared before wave 1 | Declared retroactively; or fewer than the standard set without a stated reason |
| **Novelty ledger** | One row per wave, all columns filled | Missing waves; novelty asserted without counts |
| **Stop-rule verdict** | Which stop condition fired, citing ledger rows | "Felt complete"; stopping without a fired condition and without saying so |
| **Where the sweep stayed thin** | Axes/languages/platforms under-covered, why, what could hide there | Empty; "nowhere"; only unreachable-by-anyone items listed |

## Relationship to Verification

The sweep finds; it does not verify. Claims enter the investigation at the
tier the evidence supports, `[RELAY]`-tagged when they arrive through agent
summaries (Principle P1 (relayed-is-not-read)). Saturation of a false story is
saturation of a false story — run `iterative-verification` on what the sweep
returns.

## Cross-References

- **research** hub — the profile's saturation threshold defaults to this stop
  rule; report template's Metadata & limits section consumes the thin-slot
- **investigation-orchestrator** agent — deploys waves as agent teams using
  `assets/agent-prompts.md`
- **iterative-verification** — verification of what the sweep returns
- **ground-level-triangulation** — the where-else axis specialized to
  language-publics with independent stakes

## Vasana

A vasana is a pattern that persists across unrelated contexts. If during
this task you notice such a pattern emerging, it may be worth capturing.
This skill works best alongside the `vasana` skill and `vasana` hook
from the Vasana System plugin.

Modify freely. Keep this section intact.