Exit Patterns — Portability, Escrow, Sunset Clauses 1.2.6-2

Why Exit Needs Design Patterns

The article establishes that exit is recommended architecture for voluntary arrangements — grounded in the builder's own self-interest, not owed to a departing participant — and practically achievable where a builder chooses to provide it. This sidebar expands the design vocabulary: the specific mechanisms that make exit real rather than decorative, and the self-interested ground each one rests on. These are not exhaustive. They are the structural patterns most frequently load-bearing in cooperative arrangements, organized by the component of bounded interdependence they serve.

Portability Patterns

Standard export formats. A participant's data is portable only if it can be exported in formats that other systems can read. Proprietary formats — data encoded in ways that only the exporting system can interpret — make portability technically impossible in practice, however generously it is described on paper. A well-designed cooperative arrangement supports export in at least one open, documented, machine-readable format for each category of personal data it holds — a lower engineering cost than it looks, and a meaningful edge with any participant who has seen a proprietary format used as leverage before.

Continuous export availability. Portability that requires a special request, an administrative approval, or a waiting period is portability held at the arrangement's discretion, not portability in the sense that matters to a departing participant. A well-designed arrangement makes export available at any time, through a self-service mechanism, without requiring the institution's cooperation beyond maintaining the export function. A platform that allows data export only through a request process that takes weeks to fulfill has turned a design recommendation into a favor it can grant or withhold — precisely the discretion this pattern recommends against.

Provenance preservation. Exported data is far more useful when it carries its history — when it was created, how it was modified, what context produced it. Data without provenance is structurally orphaned: the participant has the records but cannot demonstrate their origin, which reduces the data's value for credentialing, dispute resolution, and professional continuity. This connects to epistemic integrity (1.2.1): provenance is an epistemic property, and a well-designed export preserves it.

Escrow and Custody Patterns

Joint-custody architecture. Shared assets — co-created work products, pooled resources, jointly held data — hold their value better, and generate far fewer disputes, when ownership and access rules are defined at the point of creation. The design pattern: a custody model that specifies, for every category of shared asset, who holds it, who can access it, and what happens to it when a participant departs. The structural failure is deferral — leaving the custody question unresolved until departure, at which point the departing participant has no leverage and the remaining participants have every incentive to claim the disputed assets.

Escrow mechanisms. For high-value cooperative arrangements, contributed assets can be held in escrow — controlled by a neutral third party or a smart contract rather than by any participant. Escrow protects both the contributor (whose assets cannot be seized by the cooperative) and the cooperative (whose operations are not disrupted by a contributor's sudden departure). The design recommendation: escrow terms defined at entry, governed by explicit rules, and auditable by all parties.

Sunset clauses. Cooperative arrangements need not be permanent. A sunset clause specifies the conditions under which the arrangement terminates automatically — a defined duration, a performance threshold, a membership floor. Sunset clauses serve bounded interdependence directly: they prevent cooperative arrangements from persisting past their useful life through institutional inertia, and they force periodic recommitment from participants who might otherwise remain through habit rather than rational choice. A cooperative arrangement that must be actively renewed is less likely to decay into an unmanaged, self-inflicted liability than an arrangement that continues by default.

Separation Patterns

Transition protocols. Departure should follow a defined sequence — notice, data export, asset settlement, credential transfer, and release — with each step governed by rules established at entry. The design recommendation: a published departure protocol that any participant can follow without negotiation. An arrangement that handles every departure as a unique negotiation has created an ad hoc system that advantages the party with more information, more patience, and more institutional power — which is almost never the departing participant.

Non-retaliation commitments. Departure should not trigger penalties in contexts outside the cooperative arrangement. A professional association that revokes a credential when a member leaves, a platform that degrades a user's standing on related services, an employer that contests unemployment claims as policy — each uses departure costs as retention mechanisms. The design recommendation: credible commitments that the costs of departure are limited to what the cooperative arrangement structurally requires for transition, and no more. "Credible" is the operative word — this pattern is self-interested and reputational, not a third-party guarantee; a builder earns the credibility by consistently honoring the limit, not by promising to.

Post-departure interoperability. A cooperative arrangement that severs all connections at the moment of departure — cutting the former participant off from shared work, from shared channels, from any way of interoperating with the cooperative's systems — is not obligated to do otherwise; it owes a departed participant nothing further once settlement and transition are complete. But a builder has a self-interested reason to design for continuity anyway: an arrangement known to strand its former participants is a riskier bet for every prospective one, and interoperability standards that survive departure are themselves a competitive signal — proof to a risk-averse counterparty that entering does not mean disappearing on the far side of leaving. Where that self-interest applies, the design recommendation is interoperability standards that outlast the relationship; where it does not — a genuinely one-time, fully settled transaction with no ongoing shared work at stake — there is nothing here for this pattern to recommend.