---
title: Sleep phases
description: "The curation cycle's phases, in execution order."
---

## 1. The order

[`memhtml sleep run`](/reference/commands/sleep-run/) runs 17 phases in the order below, on a review branch, and each committing phase makes its own commit there. `--phases` runs any subset of them.

The last column names the phases that a failure here blocks. Those are the hard prerequisites the runner reads, so a phase with an empty cell can fail without stopping the rest.

| # | Phase | Commits | Calls a model | Blocked if it fails |
| --- | --- | --- | --- | --- |
| 1 | `preflight` | no | no | `dedup-merge`, `entity-resolution`, `person-links`, `relationship-mining`, `edge-typing`, `confidence-decay`, `arc-synthesis`, `retention-triage`, `compress`, `reprieve`, `trace-consolidation`, `task-detection`, `placement-triage`, `integrity`, `state-export`, `report` |
| 2 | `dedup-merge` | yes | yes | `compress`, `retention-triage` |
| 3 | `entity-resolution` | yes | yes | - |
| 4 | `person-links` | yes | no | - |
| 5 | `relationship-mining` | no | no | - |
| 6 | `edge-typing` | yes | yes | - |
| 7 | `confidence-decay` | yes | no | - |
| 8 | `arc-synthesis` | yes | yes | - |
| 9 | `retention-triage` | yes | no | - |
| 10 | `compress` | yes | yes | - |
| 11 | `reprieve` | yes | no | - |
| 12 | `trace-consolidation` | yes | yes | - |
| 13 | `task-detection` | yes | yes | - |
| 14 | `placement-triage` | yes | yes | - |
| 15 | `integrity` | yes | no | - |
| 16 | `state-export` | yes | no | - |
| 17 | `report` | yes | no | - |

8 of the phases call a model. The rest are deterministic, so a run with no credentials still gets through them.

## 2. Why this order

The seventeen phases, in execution order.

The order encodes the predecessor memory system's dependencies (design §6): entity resolution precedes person
links so aliases have already merged, confidence decay precedes retention triage so triage
scores the decayed value, and dedup-merge precedes compress and retention because both operate
on the post-merge set.

`task-detection` sits after `trace-consolidation` and before `integrity`, and both edges are
deliberate. It scans the ACTIVE corpus for unresolved
commitments, so it has to run after every phase that changes what is active — after dedup's folds,
after retention's evictions, after compress's canonicals, and after trace consolidation's newly
distilled memories, which are the freshest text of the night and the likeliest to carry one. And it
WRITES files, so it must precede `integrity`, which repairs dangling hrefs and regenerates the
directory artifacts: a task minted afterwards would be absent from its directory's `index.html`
until the next night.

`placement-triage` is deep-only (issue #63): on a run without `--deep` it returns immediately,
writes nothing, and commits nothing, so a default run's behavior is unchanged by its presence
in this list. Its slot has the same two edges task-detection's does, plus one more on each side:
it must run after `compress` (it re-files only what even deep grouping could not fold, so folding
has to have had its chance first) and after `task-detection` (a move mid-scan would hand the
detector paths that no longer hold files), and it must precede `integrity` because it MOVES files —
integrity regenerates each directory's `index.html`, and it rewrites inbound hrefs itself because
integrity's dangling-href repair only knows how to chase a target into the ARCHIVE, not into a
topic directory.

## 3. Provenance

A loader generates this page from `packages/sleep/src/contract.ts` while the site builds, so no file in the repository holds it: the phase names, the committing set, the model-calling set, and the hard prerequisites are four constants there, and they are the same four the runner, `memhtml sleep resume`, and the run report read. Change the registry and this page changes with it.