The Exit Rights Checklist 2.3D.1-3

Bounded interdependence's voluntary-arrangements branch (1.2.6) means participants remain by choice, not by circumstance — a design recommendation grounded in the enterprise's own interest in an arrangement worth staying in, not an entitlement owed to anyone who leaves. But that choice remains real only if exit is possible. This checklist operationalizes that branch by testing whether exit is a first-class capability or an afterthought — and it does so with the same structural honesty that the voluntary exchange conditions checklist (2.1.8) applied at the TO level and the participation test (2.3B.1) applied at the team level. The enterprise-scale version is more demanding because the lock-in mechanisms are more sophisticated and the consequences of captivity propagate further.

The test is not theoretical. Exit rights determine whether an enterprise is practicing Resilient Objectivism (RO) governance or practicing consent theater. Participants who cannot actually leave are not interdependent — they are captive.

Part 1: Can You Leave?

A participant's fundamental right: the ability to end the relationship without forfeiture of claims, without penalty beyond reasonable wind-down costs, and without requiring the enterprise's permission to depart.

The test asks whether the charter explicitly grants the right to exit and names the consequences. Acceptable answers demonstrate structural clarity: exit is available on defined notice, with no forfeiture, and the participant pays only for open commitments they signed — or exit requires board approval within a defined timeframe if it falls within a contract term, but approval is not discretionary.

Unacceptable answers reveal structural lock-in. An exit that requires enterprise permission is capture: the enterprise decides whether you may leave. An exit that forfeits accumulated stake is punitive rather than cost-reflective. Vagueness — "we haven't really had anyone exit" — is itself a warning sign, because governance that has never been tested against departure has never been tested. An enterprise that uses data custody as a lock — "we need to keep your data safe, so we cannot release it when you go" — is using security language to enforce dependency.

The remedy is structural: codify exit rights in the charter. Name notice periods, wind-down costs, what forfeiture does and does not apply, and that the enterprise cannot arbitrarily block departure. The same structural clarity that the team charter (2.3B.1) required for team-level entry and exit terms applies at enterprise scale — with higher stakes and more sophisticated lock-in mechanisms to design against.

Part 2: Can You Take Your Data?

Data is the primary lock-in mechanism in modern enterprises. A participant with years of behavioral data, transaction history, or identity records embedded in proprietary formats cannot actually exit — moving to a competitor means losing all institutional knowledge about them. This is quiet enclosure (1.1.1) operating at enterprise scale: no single act constitutes coercion, but the architecture does.

The test asks whether a participant can extract their complete data in a machine-readable, non-proprietary format, whether the export is affordable, and whether the export includes all data the enterprise holds.

Acceptable answers demonstrate genuine portability: data is exportable in open formats through a documented interface, at a transparent and reasonable cost that can be estimated before it is incurred. Unacceptable answers reveal structural lock-in: a summary rather than complete data (summaries cannot support migration), a requirement to hire consultants for migration (export is prohibitively expensive), vagueness about whether export is supported, or the use of security or intellectual property claims to retain data that describes the participant — behavioral data about a person is still data about that person, regardless of the inferences the enterprise has drawn from it.

Complete data means transaction history (everything the participant did), account data (all records tied to the participant), behavioral data (logs, inferences, and derived insights the enterprise holds about the participant), and identity records (cryptographic keys, verification proofs, and anything the enterprise can use to prove participant identity). Exclusions are appropriate only where legally binding — data about other participants, data held on behalf of regulatory authorities, or data the enterprise is legally prohibited from sharing. The personal data map (2.3A.2) provides the individual-level template for mapping data exposure; this checklist applies the same structural discipline to the enterprise's data obligations.

The remedy: treat data portability as a first-class feature. Document the export interface. Price it transparently. Support it in the product roadmap. Test it regularly — can a departing participant actually migrate to a competitor using the enterprise's export?

Part 3: Can You Verify the Terms?

Participants need to know whether the enterprise is actually doing what it claims. A service that promises "we delete your data after ninety days" means nothing if participants cannot verify that it actually does. This is the enterprise-level expression of the same verification discipline that epistemic integrity (1.2.1) demands at the individual level — the commitment to verifiability rather than trust.

The test asks whether, for each material claim the enterprise makes — data deletion, privacy controls, financial integrity, performance characteristics — participants can independently audit whether the claim is true.

Acceptable answers demonstrate structural verifiability: a public append-only ledger that participants can download and verify, monthly attestation reports signed by an independent auditor, or a published privacy model that participants can run against the enterprise's system. Unacceptable answers reveal reliance on virtue rather than structure: "trust us" (no verification mechanism), aggregate statistics (aggregates hide specific failures), internal audits only (a participant cannot audit whether the audit was done honestly), or security claims deployed to prevent verification (security is not an excuse for unverifiability — the enterprise should commit to what participants can audit before invoking security constraints).

The remedy: build verifiability into system design. Use cryptographic proofs so that claims can be verified without exposing sensitive data. Publish public ledgers for financial claims. Implement append-only logging for data-deletion claims. Engage independent auditors to attest to material claims annually. Not every claim needs real-time public verification — but claims that affect participant trust or lock-in must be verifiable by the participant, not merely asserted by the enterprise.

Part 4: Can You Migrate Without Prohibitive Cost?

Exit has costs. Data migration takes engineering time. Recreating account history in a new system takes effort. Transferring credentials costs time. But if the cost is prohibitive relative to a participant's stake, exit is illusory — the participant is locked in regardless of contractual language.

The test asks what the total cost of exiting is — in money, time, and effort — and whether that cost is proportionate to the participant's stake. A participant with a modest annual stake who faces exit costs exceeding that stake is economically locked in: departure is irrational even if the participant wants to leave. A participant whose exit costs amount to a small fraction of annual benefit retains genuine optionality. Between these extremes, the specific circumstances determine whether exit is practically exercisable.

Acceptable answers demonstrate proportionality and transparency: the enterprise has measured exit costs, publishes estimates for departing participants, and provides tooling and documentation to reduce friction. Unacceptable answers reveal ignorance or concealment: the enterprise does not know what exit costs are (either it is not designed for exit or it is hiding the costs), exit costs are fixed at a level that is prohibitive for most participants, or exit costs are described as variable without the enterprise being able to provide an estimate before the participant incurs them.

A special case: interdependence costs. Some enterprises create genuine interdependence — other participants benefit from a participant's data being present, so departure imposes costs on the remaining community. This is real interdependence, not manufactured lock-in. But the enterprise cannot shift interdependence costs onto departing participants. If departure harms other participants, the enterprise — not the departing participant — bears the cost of maintaining records or providing alternatives. This is why protocol-based systems that can transition data without enterprise involvement are structurally valuable: they solve the interdependence-cost problem at the architecture level rather than at the participant level.

The remedy: measure and publish exit costs. Provide cost estimates before participants incur them. Invest in making exit affordable. Set and track targets — for example, exit costs no greater than a defined percentage of annual participant benefit. Publish actual costs alongside targets. Use the gap to drive engineering investment in portability.

Honesty in the Checklist

The most important quality of an exit rights checklist is honesty — not perfection, honesty.

An enterprise that reports partial data portability, transparent but non-trivial export costs, limited independent verification, and a defined migration timeline is being honest. A participant can make an informed decision about whether to depend on that enterprise. An enterprise that claims perfect exit rights while the system is actually designed so that departing participants lose critical functionality is dishonest — and the dishonesty is structural, not personal, because it prevents informed consent.

The checklist is most useful when grounded in the experience of people who have actually exited. Conduct the checklist interview with departing participants: was it clear when you joined what exiting would cost? Were you able to export your data, and how easy was it? Could you verify the enterprise's material claims? Were there hidden costs when you actually tried to leave? Publish the answers. The evidence from actual departures is more reliable than the enterprise's self-assessment — and publishing it demonstrates the structural honesty that Resilient Objectivism demands.

Each of the four parts admits of degrees. A system that scores well on three parts and poorly on one is better than one that fails on all four. But the checklist makes clear: full exit rights require all four conditions to be substantially met. Missing one weakens the others. Missing two, exit governance is mostly theater.

An enterprise that completes this checklist annually — using honest feedback from departing participants — rates each part, publishes the results, builds exit into architectural planning, tests exit pathways quarterly by designating someone to attempt departure as a participant would, and sets and tracks exit-cost targets has made bounded interdependence operational at enterprise scale. The practice is not zero-friction exit — that is often impossible. The practice is exit rights made real through design, measurement, and honesty about what departing participants actually experience.