crucible-emergent-resurrection

What this skill does

# Emergent Resurrection — negative-knowledge archive

> **Self-Evolving Skill**: If the failure taxonomy misses a mode, or a resurrection trigger type recurs, update the relevant section AND append to `references/evolution-log.md`. Don't defer.

Failed hypotheses are not waste. They are negative knowledge that:

1. Documents the investigation's boundaries
2. Prevents re-exploring known dead ends
3. Can come back when conditions change

This skill is the genetic-evolutionary mechanism for "**don't rule out anything we have tried, as long as it can emerge through iterative process**".

---

## Why NOT just delete failed ideas

The session accumulated 17 null campaigns. Without negative-knowledge capture, we would:

- Re-explore the same dead ends in future sessions (wasted compute)
- Lose the meta-lesson each failure taught (wrong null, wrong scaling, wrong scope)
- Be unable to detect when conditions have shifted enough to retry

Failed attempts are cheaper to preserve than to re-run.

---

## Failure-mode taxonomy

Each failed campaign fits one or more modes. Classification determines resurrection conditions.

| Failure mode              | Description                                              | Resurrection trigger                                                                            |
| ------------------------- | -------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| `null-insignificant`      | Signal exists but below noise floor                      | Noise floor drops (longer backtest, better data, reduced cost)                                  |
| `overfit-in-sample`       | Strong IS, poor OOS                                      | Cross-validation success on a different data regime or architectural redesign                   |
| `wrong-null-applied`      | Correct signal, wrong null type broke it                 | Correct null method discovered (see Skill B §5 orthogonal cascade)                              |
| `cross-asset-failed`      | Works on one asset, breaks on others                     | Same config trial on a DIFFERENT asset passing, OR regime detector enabling per-asset selection |
| `regime-conditional`      | Full-history fails; edge concentrated in specific regime | Causal walk-forward regime classification + train/test both positive within regime + null z>3   |
| `label-leaked`            | Features/labels violated causality                       | Causality re-verified (`bars[:i]` exclusive) and retest OK                                      |
| `agent-overestimation`    | Agent's estimate > reality                               | External oracle or per-bar replay validates a scaled-down version                               |
| `grid-degenerate`         | Parameter grid too narrow                                | Widen grid, OR sensitivity analysis reveals dormant dimension                                   |
| `dormant-low-precedence`  | Valid but lower priority                                 | Higher-priority frontier cleared, revisit                                                       |
| `falsified-comprehensive` | Tested exhaustively; impossible under stated assumptions | Assumptions change (new asset class, new microstructure, regime shift)                          |

Each archived file tags one or more of these.

---

## Archive structure

```
plugins/crucible/skills/d-emergent-resurrection/references/
├── archive/
│   ├── <YYYY-MM-DD>-<slug>.md          Dormant/failed campaign record
│   └── ...
├── falsified/
│   └── <YYYY-MM-DD>-<slug>.md          Permanently falsified (highest bar for resurrection)
└── exhumation-log.jsonl                 Append-only: when ideas moved, why
```

The distinction:

- `archive/` = dormant, not dead. Awaiting the right conditions.
- `falsified/` = tested exhaustively under clear assumptions. Resurrection requires assumption change.

---

## Archive file template

Use this frontmatter structure when moving a failed idea to archive:

```yaml
---
id: "UNIQUE-ID"
title: "Short descriptive title"
status: "dormant"                       # or "falsified"
failure_mode: ["null-insignificant"]    # list; can be multiple
confidence: 0.95                         # how sure we are it's dead NOW
date_dormant: YYYY-MM-DD

verdict: |
  One-paragraph summary of what was tested and why it failed.

linked_ledger_entries:
  - "FINDING-ID-IN-EVOLUTION-JSONL"

linked_audits:
  - "findings/evolution/audits/YYYY-MM-DD-slug/verdict.md"

resurrect_if:
  - condition: "noise_floor_drops"
    trigger_metric: "trade_level_volatility"
    threshold: "< 1.2 bps (was 2.1 bps at dormancy)"
    requires: "6+ month new backtest reducing noise > 30%"

  - condition: "new_asset_regime"
    trigger_metric: "asset_correlation_cluster"
    threshold: "Jaccard(newasset_patterns, eur_patterns) > 0.65"
    requires: "Trial on new asset with fold-shuffle p < 0.05"

whats_blocked:
  - "List of specific reasons it was shelved"

next_agent_checklist:
  - [ ] If noise_floor drops > 30%: re-run config on latest data
  - [ ] Do NOT assume dead — it's 'not now, but perhaps next regime'
---

# Title

<detailed description of why it failed, what was tested, what would be needed to resurrect>
```

---

## The 3-layer exhumation process

Resurrection is deliberate. Never auto-resurrect.

**Layer 1 — Autonomous flag**: periodically (can be a cron job or session-start check), scan `archive/*` for files whose `resurrect_if` conditions might be currently met. Tag with `CANDIDATE_FOR_RESURRECTION_<date>`. This ONLY flags; it does NOT resurrect.

**Layer 2 — Agent review**: next research session or autonomous agent reviews tagged candidates. Picks ONE to trial (prevents thrashing). Runs 1-2 folds to check if signal has genuinely re-emerged. Either:

- Promotes to active campaign (`status: "active"`, new audit folder)
- Updates archive file's frontmatter: "false positive at <date>, conditions looked met but retry failed"

**Layer 3 — Human sign-off**: before deploying anything resurrected to production (or giving it resources beyond initial re-trial), human reviews exhumation report. Confirms the condition-change is real, not a data artifact.

---

## When to archive (triggers)

During a research session, move to `archive/` when:

- A serial-gate failure killed the signal (Skill B §2, Gate C — the Irrecoverable one)
- A shuffled-null test decisively rejected (z < 1 and p > 0.9)
- 20+ parameter combos all failed → the whole approach gets archived, not each combo
- Cross-asset Gate D fails → archive the "universal" interpretation; keep asset-specific as scoped-down live version (see Skill C §3)

Archive ≠ silence. Write the file; append to `exhumation-log.jsonl`:

```json
{
  "date": "YYYY-MM-DD",
  "action": "archive",
  "id": "...",
  "reason": "...",
  "from_audit": "..."
}
```

---

## When NOT to archive

- A finding survives all gates but produces modest economics — that's `live-limited-economics`, not dormant; keep active and look for ensemble partners
- A finding partially fails one gate — see Skill C §3 (scope narrows, doesn't kill)
- A method used in a campaign that gave null results — the method itself isn't archived; only the specific hypothesis
- User interest waned mid-campaign — that's not a failure mode; mark as `paused` elsewhere

---

## Population-level resurrection signals

Beyond individual-file `resurrect_if`, watch for population-level conditions:

- **Multiple failed campaigns share a failure mode** → the common cause may be addressable (e.g., all 5 used wrong null type → invent new null → resurrect all 5)
- **New method/technology emerges** → old failures under old methods may flip
- **Asset microstructure shifts** → asset-specific failures may reverse

---

## Integration with the ledger

`findings/evolution/evolution.jsonl` entries gain a `dormant_refs` field:

```json
{
  "id": "FINDING-ID",
  "status": "nu