Re-Convergence — Identity Recovery in CIP

Most generative workflows attempt to fix drift by retrying. CIP does not.

It terminates the process and restores a known-valid state.

Retry vs. Re-Convergence

This distinction defines the difference between uncontrolled generation and governed recovery.

Conventional (Retry):
Generate → Drift → Retry → Drift → Retry → Collapse
(Same contaminated context. Drift compounds.)

CIP (Re-Convergence):
Generate → Drift → FAIL → Hard Abort → Purge → Re-bind Anchor → Re-converge
(Context is exited. Contaminated outputs/states are purged. Recovery begins from verified state.)

Retry continues within the contaminated reconstruction context. Each attempt inherits the drift of the previous. The system has no mechanism to return to a known-valid state.

Re-convergence exits that context entirely. The contaminated cycle is terminated and contaminated outputs/states are purged. Recovery begins from the last verified anchor — a state that has previously passed all identity gates.

Why Re-Convergence Is Required

Generative systems do not self-correct identity drift through continued sampling.

Once drift occurs, additional generation within the same context tends to propagate divergence rather than restore identity. This is a structural property of probabilistic reconstruction, not a correctable output error.

Re-convergence addresses this by:

terminating the contaminated generation cycle immediately (Hard Abort) and purging contaminated outputs/states
returning to the last validated anchor state
resetting the reconstruction context
resuming generation under full gate enforcement

The Re-Convergence Sequence

Identity Gate FAIL
        ↓
Hard Abort — terminate current cycle immediately
        ↓
Purge contaminated outputs/states
        ↓
Roll back to last verified Anchor
        ↓
Reset context (environment reset)
        ↓
Re-bind to the last validated anchor as the primary conditioning reference
        ↓
Reset sampling configuration if applicable
        ↓
Resume generation under full Gate enforcement

Entry Condition

Re-convergence may only begin from a verified anchor — an output that has previously passed all identity gates:

PASS ⇔ Face Gate ∧ Skeleton Gate ∧ Proportion Gate

If no verified anchor exists, re-convergence cannot proceed. A new anchor formation cycle must be initiated first.

Re-binding

Re-binding is the act of reconnecting the workflow to the last validated anchor, UID, and governing constraints before re-convergence.

Re-binding procedure:

Select the last verified anchor
Re-bind to the last validated anchor as the primary conditioning reference
Apply minimal prompt (invariant attributes only)
Apply identifier binding (UID) to reinforce identity recall
Resume generation under gate enforcement

Re-binding is not optional. It is a governance requirement within the CIP framework.

Hard Abort vs. Progressive Correction

Approach	Behavior	Risk
Progressive correction	Adjust and retry within same context	Drift compounds
Hard Abort + Re-convergence	Terminate and re-bind to last validated anchor	Drift is contained

CIP mandates Hard Abort. Progressive correction assumes the system can self-correct. CIP treats this assumption as operationally unsafe.

Bounded Generation Cycles (BGC)

Re-convergence operates within bounded generation cycles.

Each cycle has a defined entry point (validated anchor) and a defined exit condition (Hard Abort or session end). Stability is maintained by chaining cycles through disciplined re-convergence — not by assuming identity persists indefinitely.

Cycle A → Generate → Gate → PASS / FAIL (Hard Abort)
                                    ↓
                              Purge → Re-binding
                                    ↓
Cycle B → Generate → Gate → PASS / FAIL (Hard Abort)

Key Principle

Re-convergence does not fix a bad output. It restores the conditions under which adoptable outputs can be produced.

See: CIP Specification v0.1 — Quality Gate & Hard Abort — Protocol Template