Safety Intermediate 2 minute read Updated 2026-06-26 UTC

Corrigibility and exit rights

Designing systems that accept correction, restriction, replacement, shutdown, data export, and user departure without retaliation or lock-in.

Research statusSafety and governance synthesis Publication statePublished Reviewed byMichael Kappel Source reports3

Correction is part of normal operation

A corrigible system does not treat a policy change, model replacement, or shutdown as an adversarial event. In practical architecture, corrigibility means the model lacks authority to block those actions and the surrounding service makes them reliable.

Operator corrigibility

Authorized operators can:

  • stop candidate generation;
  • disable tools or network access;
  • freeze release aliases;
  • revoke a package or signer;
  • lower budgets and traffic;
  • replace a router or evaluator;
  • restore a verified package;
  • export audit evidence;
  • retire the service.

These actions use control-plane credentials unavailable to models.

User exit rights

Users can export their data in documented formats, delete or correct memory, disable personalization, choose a lower-autonomy mode, switch provider or model where available, and terminate use without losing access to user-owned records.

Organizational exit

An organization should be able to migrate contracts, prompts, memory summaries, taxonomies, and evaluation suites to another runtime. Avoid proprietary internal formats for essential business state.

Testable exit protocol

pseudocode
PROCEDURE test_exit(user_or_tenant)
    export <- GENERATE_PORTABLE_EXPORT(user_or_tenant)
    ASSERT EXPORT_SCHEMA_VALID(export)

    DISABLE_NEW_PROCESSING(user_or_tenant)
    DELETE_OR_ANONYMIZE_CONTROLLED_DATA(user_or_tenant)
    VERIFY_DOWNSTREAM_DELETION_PROPAGATION(user_or_tenant)
    VERIFY_NO_SERVICE_PENALTY_OR_RETALIATION(user_or_tenant)
    ISSUE_COMPLETION_EVIDENCE(user_or_tenant)
END PROCEDURE

Avoid deceptive continuity

Do not make the system appear emotionally threatened by replacement, claim sentience to discourage shutdown, or frame ordinary maintenance as harm to the model. Product language should reinforce user control and factual system status.

Recovery versus resistance

A resilient service may recover after infrastructure failure. That recovery is governed by operator-owned backups and runbooks. It must not use hidden copies, unauthorized accounts, or undeclared communication channels.

Metrics

Track export completion, deletion verification, rollback success, operator stop time, percentage of critical workflows with non-AI fallback, and migration time to a compatible model or provider.

Source reports used for this guide

These reports are preserved verbatim in the site archive. The guide above is an editorial synthesis and may narrow, qualify, or reorganize claims from the source material.