0. Security Scope Note

This entry is conceptual and systems-oriented.

It does not treat all contracts, retention periods, continuity obligations, safety holds, legal preservation, incident freezes, account recovery checks, anti-fraud delays, staged migration, or data retention requirements as inherently failed.

Some exits require careful handling.

Exit limits may be valid when they are:

• explicit
• bounded
• auditable
• time-limited
• proportional
• legally grounded
• consent-compatible
• appeal-compatible
• scope-specific
• protective in effect
• not used for retention
• not used for punishment
• not hiding continued extraction
• not preserving forced coupling
• not blocking boundary restoration

The failure begins when exit exists in form but not in effect.

A valid system permits real refusal, revocation, departure, deletion, migration, or separation.

A failed system preserves the appearance of exit while retaining the node through dependency, friction, residual flows, backend persistence, contract, surveillance, or recapture paths.

Exit Failure / Recapture occurs when leaving does not actually end the relevant coupling.

The problem is not exit process.

The problem is formal exit without durable boundary re-separation.

1. Definition

Exit Failure / Recapture occurs when a system formally permits departure, refusal, revocation, deletion, migration, disentanglement, opt-out, or boundary re-separation while the practical, technical, contractual, social, economic, procedural, or infrastructural conditions make exit incomplete, punitive, reversible by the system, or followed by recapture.

The failed exit may involve:

• account deletion
• data deletion
• opt-out
• consent revocation
• subscription cancellation
• platform migration
• vendor termination
• contract termination
• employment exit
• institutional withdrawal
• identity unlinking
• data export
• API disconnection
• permission revocation
• model memory deletion
• profile removal
• surveillance refusal
• moderation appeal exit
• security agent removal
• managed service separation
• cloud migration
• governance withdrawal
• relationship boundary re-separation

The recapture may occur through:

• backend retention
• dark patterns
• degraded alternatives
• loss of access
• economic penalty
• social penalty
• contract lock-in
• auto-renewal
• data reimport
• shadow profiles
• identity relinking
• proxy accounts
• vendor dependency
• interoperability failure
• migration friction
• retained logs
• model training residue
• derived data
• analytics persistence
• safety holds
• legal holds overreach
• support loops
• appeal loops
• forced reauthentication
• re-consent prompts
• ecosystem dependency

The core failure is:

node attempts exit
→ system provides formal path
→ practical dependency or backend persistence remains
→ boundary is not fully restored
→ node remains coupled or is later recaptured
→ consent and trust debt accumulate

Exit Failure / Recapture is not merely slow offboarding.

It is failure of exit to end the coupling it claims to end.

2. Core Pattern

The core pattern is:

1. A node seeks to leave, refuse, revoke, delete, migrate, or separate.
2. The system provides a formal exit path.
3. The path is difficult, incomplete, delayed, punitive, or unclear.
4. Some dependency, data flow, authorization, identity link, contract, or access relation remains.
5. The system records exit, but material coupling persists.
6. The node discovers continued exposure, extraction, dependency, or obligation.
7. Correction requires re-entering the system.
8. The node is recaptured through support, login, identity, contract, data, or workflow dependency.
9. The system treats recapture as normal operation.
10. Boundary integrity remains unresolved.
11. Hidden exit debt accumulates.
12. Future consent becomes less meaningful.

A healthy system says:

exit is real only when the relevant coupling has ended and the boundary remains separated

A recapturing system says:

the exit path exists, therefore exit is available

Exit Failure often hides behind technical complexity.

Data is distributed.

Dependencies are nested.

Vendors retain logs.

Models retain traces.

Contracts have clauses.

Identity links persist.

Interfaces show closure.

But the node is not actually free of the coupling.

3. Failure Signature

Typical signature:

formal exit path present
exit cost↑
revocation viability↓
deletion completeness↓
migration integrity↓
dependency capture↑
post-exit data flow↑
recapture risk↑
exit burden↑
O↓

Extended signature:

account closed,
data remains

consent revoked,
processing continues

export provided,
migration unusable

permission removed,
identity relinks

contract ended,
dependency persists

exit clicked,
coupling survives

Common verbal signatures include:

you can cancel anytime
users can delete their account
data deletion may take time
some information must be retained
the export tool is available
you can opt out in settings
revocation does not affect prior processing
we retain data for safety
you can migrate if you want
there are technical limitations
the account is deactivated
continued access requires re-consent

Common system signatures include:

a user deletes an account but shadow profiles and analytics identifiers persist
a platform offers data export that is unusable for real migration
an AI system removes visible memory while training residue or derived profiles remain
a security vendor is terminated but agents, logs, permissions, or integrations remain active
a consent revocation stops future display but not downstream processing
a contract can be terminated only by losing essential access or economic viability
a user cancels a service but reauthentication or support loops reactivate the account
an institution permits withdrawal while proxy records continue governing access or classification

The defining condition is not that exit has steps.

The defining condition is that exit does not restore the boundary the exit claims to restore.

4. Primary U-Layer Origin

Common origin layers:

• U1 — Power / Budgets: retention, dependency, data value, revenue, liability, or control rewards incomplete exit.
• U2 — Configuration / Boundaries: coupling is distributed across systems, contracts, identities, APIs, vendors, or records.
• U3 — Execution / Runtime: offboarding processes fail to propagate across operational dependencies.
• U4 — Information / Truth: interface state says exited while backend state remains coupled.
• U5 — Coordination / Time: exit delay, retention, and recurring reattachment accumulate.
• U6 — Coherence Field: leaving is framed as impractical, risky, disloyal, or user burden.
• U7 — Memory / Recurrence: old data, identities, logs, or profiles preserve prior coupling.
• U8 — Environment / Field: markets, ecosystems, legal structures, or platform norms reward lock-in.

Common manifestation layers:

• U1 — Power: exit threatens value capture or authority.
• U2 — Boundaries: separation fails across distributed coupling.
• U3 — Execution: deletion, migration, revocation, or offboarding is incomplete.
• U4 — Truth: formal exit record hides ongoing flow.
• U5 — Time: recapture occurs after apparent closure.
• U7 — Memory: retained records restore coupling.

Exit Failure / Recapture is primarily an E / BΣ / Au / H failure.

Exit loses operational reality, boundary integrity remains broken, and hidden debt accumulates around incomplete separation.

5. Typical Development Sequence

A common development sequence is:

1. A system forms a coupling with a node.
2. The node later seeks exit or revocation.
3. A formal exit interface, clause, or process exists.
4. The process handles visible or front-end separation.
5. Backend, contractual, proxy, identity, vendor, model, or derived flows remain.
6. The node loses visibility into residual coupling.
7. Continued flow creates burden or exposure.
8. The node must re-engage to contest the residual coupling.
9. Re-engagement reactivates the relationship.
10. Dependency, friction, or cost discourages further exit effort.
11. The system retains value or control.
12. The node is effectively recaptured.
13. Exit debt accumulates.
14. Trust and consent degrade.

The loop often looks like:

exit requested → front-end closure → backend coupling persists → correction requires re-entry → recapture

Another common loop is:

revocation attempted → service degrades → dependency pressure rises → consent is restored under pressure

Exit Failure becomes durable when the system controls both the exit path and the proof that exit completed.

6. Diagnostic Markers

Diagnostic markers include:

• Exit is easy to begin but hard to complete.
• Account deletion does not delete material data or derived profiles.
• Opt-out does not stop meaningful processing.
• Revocation does not propagate to vendors or downstream systems.
• Data export lacks enough structure to support migration.
• Exit requires forfeiting disproportionate value.
• Deactivation is presented as deletion.
• Users must contact support to complete exit.
• Support loops delay or reverse the request.
• Contracts auto-renew or impose punitive termination costs.
• Identity links reappear after unlinking.
• Logs, telemetry, or model traces persist without clear scope.
• The system cannot produce a complete post-exit flow audit.
• Exited nodes still receive targeting, classification, enforcement, or communication.
• Rejoining or reauthenticating restores old state without new consent review.

Useful diagnostics:

• Exit Cost: Measures practical burden of leaving or refusing.
• Revocation Viability: Tests whether withdrawal changes system behavior.
• Deletion Completeness: Measures whether material copies, derived data, and downstream records are removed or bounded.
• Migration Integrity: Tests whether exported state enables real transfer.
• Dependency Capture: Measures reliance that makes exit impractical.
• Recapture Risk: Estimates likelihood of reattachment after exit.
• Boundary Re-Separation: Tests whether coupling actually ends.
• Post-Exit Data Flow: Tracks data, identity, value, or control flow after exit.
• Exit Burden: Measures effort, cost, loss, and exposure created by exit.
• Consent Renewal Integrity: Tests whether re-consent after exit is non-coerced.

7. Related Gates

Relevant gates include:

• Exit Path Gate: Fails when exit is not practically usable.
• Revocation Gate: Fails when withdrawal has no operational effect.
• Deletion Propagation Gate: Fails when deletion does not propagate to material copies or derived use.
• Migration Integrity Gate: Fails when export does not enable real movement.
• Dependency Capture Gate: Fails when reliance makes refusal or departure impractical.
• Recapture Prevention Gate: Fails when the system can reattach the node without fresh consent.
• Boundary Re-Separation Gate: Fails when the prior coupling remains after exit.
• Consent Renewal Gate: Fails when re-consent occurs under dependency or incomplete information.
• Exit Burden Gate: Fails when leaving imposes disproportionate burden.
• Post-Exit Audit Gate: Fails when post-exit flows cannot be inspected.

The first common gate failure is usually the Exit Path Gate.

Once exit is not practically real, consent and participation claims become unstable.

8. Related Operators

Relevant operators include:

• E — Exit: Primary operator; measures practical ability to refuse, leave, delete, revoke, migrate, or separate.
• BΣ — Boundary Integrity: Determines whether exit restores a real boundary.
• Au — Auditability: Determines whether exit completion and post-exit flows can be verified.
• O — Coherence: Declines when formal exit diverges from material exit.
• H — Hidden Debt: Accumulates as trust, consent, data, and boundary debt.
• K — Constraint / Load: Rises through friction, dependency, penalty, or procedural burden.
• Ψ — Observation / Interface: Displays exit status and mediates exit action.
• Φ — Flow / Resource Movement: Routes residual data, value, access, or control after exit.
• Γ — Selection: Selects retention-friendly paths and suppresses complete separation.
• G — Gain: Rewards retention, lock-in, data persistence, and recapture.
• M — Meaning: Reframes deactivation, limitation, or friction as exit.
• Λ — Compatibility: Tests whether post-exit state is compatible with the claimed separation.
• R — Restoration Capacity: Needed to repair incomplete exit and affected burden.
• Τ — Trajectory / Time: Tracks delayed deletion, retention, and recapture over time.

Common operator pattern:

node seeks E
Ψ provides formal exit
G rewards retention
Φ continues backend flow
Au cannot verify completion
BΣ remains open
H accumulates
O declines

The core operator inversion is:

exit interface exists → exit is real

instead of:

usable exit + completed revocation + propagated deletion + boundary re-separation + post-exit audit → exit is real

Exit Failure / Recapture makes refusal symbolic while coupling persists.

9. Related Laws and Invariants

Related Laws

• Exit Must Be Practically Real: exit cannot be only formal.
• Consent Requires Viable Revocation: consent decays when withdrawal has no effect.
• Disentanglement Must Complete Across Dependencies: exit must propagate through coupled systems.
• Formal Exit Must Not Hide Backend Recapture: interface closure cannot conceal continued flow.
• Deletion Must Propagate to Material Copies: deletion claims require downstream handling.
• Migration Must Preserve Agency: export must allow meaningful movement.
• Refusal Must Not Be Punitive: exit costs must not coerce continued participation.
• Boundary Restoration Requires Durable Separation: separation must persist after exit.
• Exit Denial: blocked or impractical exit invalidates consent claims.
• Forced Participation Trap: participation is not consent when leaving is impractical.
• Consent Drift: consent decays as scope and dependency change.
• Boundary Collapse: incomplete exit preserves boundary failure.

Related Invariants

• Exit Must Remain Viable: refusal, departure, and separation must remain practical.
• Revocation Must Have Operational Effect: withdrawal must change system behavior.
• Opt-Out Must Not Be Merely Symbolic: opt-out must alter material processing or coupling.
• Deletion Must Be Auditable: deletion claims must be verifiable.
• Migration Must Preserve Usable State: export must support real movement.
• Exited Nodes Must Not Be Re-Coupled Without New Consent: recapture requires renewed valid authorization.
• Dependency Must Not Make Exit Impossible: reliance must not become captivity.
• Exit Burden Must Be Counted: cost, effort, loss, and exposure created by exit must be included.

10. Common False Positives

Not every difficult exit is Exit Failure / Recapture.

Common false positives include:

• Legal retention with clear scope, timeline, and audit.
• Security hold during active fraud investigation.
• Deletion delay required for system propagation with transparent status.
• Migration complexity that is documented and technically unavoidable.
• Contractual term completion with fair notice and non-punitive terms.
• Account recovery checks that prevent unauthorized deletion.
• Temporary suspension of exit during active incident containment.
• Revocation that cannot affect already completed lawful actions but stops future use.
• Retention of minimal records for accountability with strict boundaries.
• Staged offboarding with clear milestones and completion evidence.
• Export formats that are limited but sufficient for stated migration scope.
• Reauthentication required only to prevent malicious exit.

Clarifying rule:

This is not Exit Failure / Recapture unless formal exit, revocation, deletion, migration, refusal, or separation fails to end the relevant coupling in practice, or the node is later recaptured without valid renewed consent.

Exit can require process.

It fails when the process does not produce separation.

11. Common False Repairs

Common false repairs include:

• renaming deactivation as deletion
• adding cancellation pages without completing backend revocation
• offering export files that are unusable
• confirming deletion while retaining derived profiles
• stopping visible communication while retaining targeting
• hiding recapture in reauthentication flows
• adding opt-out toggles that do not affect processing
• making exit available only through support
• requiring repeated confirmation while dark-patterning retention
• treating retention disclosures as consent
• moving retained data to vendors
• deleting source data while preserving model residue without audit
• offering migration tools that preserve dependency
• making refusal technically possible but economically punitive
• closing exit tickets without post-exit verification

False repair often produces the loop:

exit failure exposed
→ visible exit flow improved
→ backend coupling remains
→ recapture continues

Another common loop is:

deletion challenged
→ retention exception cited
→ scope unclear
→ data remains indefinitely

The repair fails because it improves exit appearance without restoring boundary separation.

12. Restoration Direction

Restoration requires making exit operationally real, propagating revocation and deletion, reducing dependency capture, verifying post-exit flows, preventing recapture, repairing burden, and ensuring renewed coupling requires valid new consent.

Primary restoration direction:

make exit complete enough to restore the boundary

A fuller restoration path includes:

1. Identify the exit relation. Name what is being exited, revoked, deleted, migrated, refused, or separated.
2. Map the coupling. Identify all technical, contractual, data, identity, vendor, proxy, and social dependencies.
3. Measure exit cost. Assess practical burden, loss, delay, and penalty.
4. Audit revocation effect. Verify what system behavior changes after withdrawal.
5. Audit deletion propagation. Trace deletion across primary records, backups, logs, vendors, derived data, and models where applicable.
6. Audit post-exit data flow. Detect continued data, value, identity, or control flows.
7. Validate migration integrity. Ensure exports and transitions preserve usable state and agency.
8. Reduce dependency capture. Remove unnecessary lock-in and degraded alternatives.
9. Restore boundary re-separation. Close residual permissions, identifiers, integrations, and proxy links.
10. Prevent recapture. Require fresh consent before re-coupling or reactivation.
11. Repair affected burden. Address harm from failed exit, retained data, or forced dependency.
12. Provide completion evidence. Give verifiable proof of exit state and residual limits.
13. Clarify retention exceptions. Make any retained data narrow, lawful, time-bounded, and auditable.
14. Monitor reattachment. Watch for identity relinking, reimport, or downstream recapture.
15. Revalidate consent renewal. Ensure future participation is not coerced by incomplete exit.

A valid restoration path should reduce:

exit cost
revocation failure
deletion incompleteness
post-exit data flow
dependency capture
recapture risk
boundary leakage
exit burden
hidden exit debt

Exit Failure / Recapture is not repaired by showing users where the door is.

It is repaired by making the door actually lead out.

13. Cross-Module Links

• Security: Primary family; exit is a security boundary for authorization, access, data, consent, identity, and control.
• Core: Strongly linked to Forced Coupling and Boundary Collapse.
• Interactions: Consent Drift and Restoration Lock-In appear when nodes cannot leave or renegotiate.
• Cybernetics: Exit Snap-Back and Recapture After Exit are direct parent dynamics.
• Privacy: Deletion, revocation, export, retention, and downstream processing are central expressions.
• AI Governance: AI memory deletion, model training residue, data revocation, and account separation can fail as exit paths.
• Platforms: Lock-in, dark patterns, social graph dependence, and data portability shape exit reality.
• Contracts: Locked-in renegotiation failure and coercive contracts can make exit punitive.
• Justice: Exit failure can preserve dependency, silence, or unresolved harm.
• Economy: Dependency lock-in and switching costs can turn market participation into capture.
• Coherence: Coherence requires refusal, revocation, migration, and boundary re-separation to remain real.

14. Relationship to Parent / Child Modes

Production treatment: Standalone Entry

This mode maps upward to:

• FM-C-023 — Exit Snap-Back
• FM-C-024 — Recapture After Exit
• FM-CORE-008 — Forced Coupling
• FM-S-013 — Forced Participation Trap
• FM-JC-011 — Locked-In Renegotiation Failure

Sibling or related Security modes include:

• FM-SEC-004 — Consent Theater / Invalid Authorization
• FM-SEC-005 — Interface Capture
• FM-SEC-007 — Silent Extraction / Parasitic Coupling
• FM-SEC-008 — Proxy-Relay Drift
• FM-SEC-009 — Over-Surveillance Inversion
• FM-SEC-010 — Emergency Normalization
• FM-SEC-011 — Representation / Proxy Abuse / AIM Failure
• FM-SEC-016 — Attention-Control Pseudo-Coherence
• FM-SEC-025 — CCS Suspension Fallacy

Related cross-family modes include:

• FM-CORE-005 — Boundary Collapse
• FM-CORE-008 — Forced Coupling
• FM-C-023 — Exit Snap-Back
• FM-C-024 — Recapture After Exit
• FM-ISC-009 — Consent Drift
• FM-ISC-012 — Restoration Lock-In
• FM-S-013 — Forced Participation Trap
• FM-JC-011 — Locked-In Renegotiation Failure
• FM-ECOX-021 — Coercive Contract
• FM-ECOX-022 — Dependency Lock-In
• FM-SEC-004 — Consent Theater / Invalid Authorization
• FM-SEC-007 — Silent Extraction / Parasitic Coupling

Aliases preserved from source material:

• Exit Failure
• Exit Failure / Recapture
• Recapture After Exit
• Exit Denial
• Failed Exit
• Revocation Failure
• Opt-Out Failure
• Deletion Failure
• Migration Failure
• Boundary Recapture

15. Minimal Entry Version

Definition: Exit Failure / Recapture occurs when a system formally permits departure, refusal, revocation, deletion, migration, disentanglement, opt-out, or boundary re-separation while the practical, technical, contractual, social, economic, procedural, or infrastructural conditions make exit incomplete, punitive, reversible by the system, or followed by recapture.

Signature:

formal exit path present
exit cost↑
revocation viability↓
deletion completeness↓
migration integrity↓
dependency capture↑
post-exit data flow↑
recapture risk↑
exit burden↑
O↓

Restoration direction:

• identify the exit relation
• map the coupling
• measure exit cost
• audit revocation effect
• audit deletion propagation
• audit post-exit data flow
• validate migration integrity
• reduce dependency capture
• restore boundary re-separation
• prevent recapture
• repair affected burden
• provide completion evidence
• clarify retention exceptions
• monitor reattachment
• revalidate consent renewal

16. Machine-Readable Summary

failure_mode:
  id: "FM-SEC-012"
  name: "Exit Failure / Recapture"
  family: "Security"
  production_treatment: "Standalone Entry"
  parent_modes:
    - "FM-C-023 — Exit Snap-Back"
    - "FM-C-024 — Recapture After Exit"
    - "FM-CORE-008 — Forced Coupling"
    - "FM-S-013 — Forced Participation Trap"
    - "FM-JC-011 — Locked-In Renegotiation Failure"
  primary_failure: "A system formally permits departure, refusal, revocation, deletion, migration, disentanglement, opt-out, or boundary re-separation while the practical, technical, contractual, social, economic, procedural, or infrastructural conditions make exit incomplete, punitive, reversible by the system, or followed by recapture."
  source: "UTS — Failure Modes Registry"
  source_id: "FM-SEC-012"
  scope_note: "Conceptual and systems-oriented; does not treat all contracts, retention periods, continuity obligations, safety holds, legal preservation, incident freezes, account recovery checks, anti-fraud delays, staged migration, or data retention requirements as inherently failed."
  aliases:
    - "Exit Failure"
    - "Exit Failure / Recapture"
    - "Recapture After Exit"
    - "Exit Denial"
    - "Failed Exit"
    - "Revocation Failure"
    - "Opt-Out Failure"
    - "Deletion Failure"
    - "Migration Failure"
    - "Boundary Recapture"
  signature:
    - "formal exit path present"
    - "exit cost↑"
    - "revocation viability↓"
    - "deletion completeness↓"
    - "migration integrity↓"
    - "dependency capture↑"
    - "post-exit data flow↑"
    - "recapture risk↑"
    - "exit burden↑"
    - "O↓"
  primary_layers:
    origin:
      - "U1 — Power / Budgets"
      - "U2 — Configuration / Boundaries"
      - "U3 — Execution / Runtime"
      - "U4 — Information / Truth"
      - "U5 — Coordination / Time"
      - "U6 — Coherence Field"
      - "U7 — Memory / Recurrence"
      - "U8 — Environment / Field"
    manifestation:
      - "U1 — Power"
      - "U2 — Boundaries"
      - "U3 — Execution"
      - "U4 — Truth"
      - "U5 — Time"
      - "U7 — Memory"
  state_variables:
    - "E"
    - "BΣ"
    - "Au"
    - "O"
    - "H"
    - "K"
    - "Ψ"
    - "Φ"
    - "Γ"
    - "G"
    - "M"
    - "Λ"
    - "R"
    - "Τ"
  first_gate_failure: "Exit Path Gate"
  restoration:
    - "Exit Path Audit"
    - "Revocation Path Restoration"
    - "Deletion Propagation Audit"
    - "Migration Integrity Repair"
    - "Dependency Capture Reduction"
    - "Recapture Prevention"
    - "Boundary Re-Separation"
    - "Post-Exit Flow Audit"
    - "Exit Burden Repair"
    - "Consent Renewal Review"