What exit rights mean
Exit rights are the legal, technical, contractual, product, and community mechanisms that let a person or organization leave a digital service or virtual network without unreasonable loss of access, continuity, control, identity, memory, reputation, or work product.
For VNWO, exit is not only a privacy concept. It is a legitimacy test. If a network cannot explain how participants export, revoke, close, correct, disengage, or fork, then its trust depends on captivity rather than consent.
No network without clean detachment
A clean exit is not a single button. It is a visible chain of consent revocation, export, retention explanation, authority shutdown, repair access, and non-retaliation. VNWO frames this chain as civic design, not as automatic legal compliance.
The strongest virtual networks should be able to show what remains active after a participant leaves and why. The weakest networks require continued dependence to preserve identity, memory, or reputation.
The exit stack
Export
A participant or customer can obtain a usable copy of relevant data, content, memory, identity, reputation, or evidence.
Portability
A participant can move or transmit scoped information to another tool, community, steward, or network where available and technically feasible.
Closure
A participant can close an account, relationship, delegation, or workspace through understandable instructions without dark patterns.
Erasure
A participant can request deletion or retirement of eligible records while retention, security, evidence, and audit limits are clearly explained.
Offboarding
A system provides transition assistance, retention windows, export formats, deletion confirmations, and continuity notes when a service or network relationship ends.
Forkability
A community can peacefully separate when rule disagreement cannot be resolved without coercion.
Clean-exit architecture
VNWO treats exit as an architectural problem: identities, memories, agents, endpoints, and community rules should be separable without turning one site into a central controller. VNWO keeps that idea narrow by publishing the civic pattern and leaving implementation to the appropriate lane.
Consent revocation
Stop active delegation, memory capture, endpoint use, and notifications when the participant withdraws scope. VNWO describes the rule; the implementing system performs the action.
Portable memory package
Export reviewed continuity records in documented formats. Where .uai memory is used, UAIX remains the implementation lane for the package structure and file handoff process.
Disposition receipt
Give the participant a durable record of what was exported, retired, retained, deferred, corrected, or unavailable, with a UTC timestamp and reason.
Capability cleanup
Review local endpoint and tool capability records so stale permissions, tokens, webhooks, or agent scopes do not remain active after exit.
Public correction corridor
Keep a route for correcting visible records after exit when the remaining public record affects identity, reputation, or safety.
Forkable governance packet
When community separation is appropriate, publish what rules, records, names, archives, and attribution may be reused by a fork.
Exit components
Identity export
Export profile data, public identifiers, account metadata, disclosure labels, and links to public records in a usable format.
Memory export
Export reviewed memory records that steer future interactions, including .uai handoff records where a UAIX-style memory package is used.
Reputation portability
Carry contribution history, endorsements, moderation outcomes, appeals, and evidence without forcing continued membership in one platform.
Account closure
Provide a clear closure path that explains consequences, recovery windows, billing or participation effects, and records retained for legitimate reasons.
Community fork
Define when a group can leave under a separate rule set, what records can move, and what name, attribution, and archive limits apply.
Agent disengagement
Revoke agent representation, delegated scope, active memory, credentials, tool access, and public disclosure labels that no longer apply.
Endpoint revocation
Withdraw endpoint consent and confirm that no hidden persistence, escalation, or private probing remains active.
Public correction
Request correction of public records without requiring the participant to erase legitimate evidence or accept misleading deletion.
No retaliatory deletion
Leaving should not punish participants by erasing public corrections, distorting reputation, or representing exit as wrongdoing.
Human-readable instructions
Exit instructions should be written for people, linked in obvious places, and available without private negotiation.
Privacy-law alignment without legal overclaiming
Exit design often overlaps with privacy rights such as portability, deletion, restriction, objection, correction, and sensitive-data retention limits. VNWO can help builders write clearer public rules, but it does not decide legal obligations or guarantee compliance.
| Topic | VNWO design alignment | Boundary |
|---|---|---|
| Portability | VNWO recommends structured, machine-readable export paths for relevant scoped records. | VNWO does not decide legal scope, force provider transfer, or guarantee compatibility. |
| Erasure and deletion | VNWO distinguishes deletion requests from export requests and asks operators to explain retention limits. | VNWO does not execute deletion or determine whether a legal exception applies. |
| Restriction and objection | VNWO recommends revocation paths for active memory, endpoint permissions, profiling, and agent delegation. | VNWO does not provide legal advice or verify statutory rights. |
| Biometric or sensitive data | VNWO recommends public retention schedules, explicit consent, and documented destruction or retention reasons for sensitive classes. | VNWO.com should not collect or receive sensitive files, credentials, biometric data, or private memory records. |
Recommended exit flow
- Start request: Participant, customer, steward, or authorized representative starts an exit request.
- Classify request: Identify whether the request is export, portability, transfer, account closure, deletion, revocation, fork, or correction.
- Authenticate safely: Confirm the requester without demanding unnecessary secrets or exposing additional private memory.
- Offer export first: Before closure or deletion, offer relevant identity, memory, reputation, file-handoff, and endpoint records where available.
- Explain limits: Explain retention, backup, legal, security, billing, or evidence limits in plain language.
- Revoke active authority: Disable active agent delegation, endpoint permissions, memory capture, notifications, and workflow authority.
- Provide receipt: Record what was exported, closed, revoked, deleted, retained, deferred, corrected, or unavailable.
- Keep repair path open: Allow public correction or appeal where remaining records continue to affect the participant.
Disposition receipt template
A disposition receipt gives the departing participant a concise record of what happened. It should be specific enough for review without exposing additional secrets.
Exit request: [export / deletion / closure / revocation / fork / correction]
Requester: [verified role, not unnecessary secrets]
Reviewed UTC: [timestamp]
Export provided: [yes/no/partial and format]
Memory disposition: [exported / retained with reason / retired / unavailable]
Endpoint disposition: [revoked / not applicable / retained with reason]
Agent delegation: [revoked / not applicable]
Public correction path: [URL or contact path]
Retention limits: [plain-language reason and duration]
Appeal or repair path: [URL or contact path]
VNWO boundary: This receipt documents the network operator's stated outcome; VNWO does not certify compliance.
Exit-readiness checklist
- Publish exit instructions before launch.
- Separate export, portability, transfer, account closure, deletion, and revocation in the UI and documentation.
- Explain which records are participant-provided, system-generated, inferred, retained, quarantined, or unavailable.
- Offer export before irreversible closure where practical.
- Use open or documented formats such as JSON, CSV, Markdown, PDF, ZIP, or .uai where appropriate.
- Document retention windows, backup timing, subprocessor or downstream copies, and evidence exceptions.
- Issue confirmation receipts with UTC timestamps and disposition labels.
- Revoke agent delegation, endpoint access, active memory capture, webhooks, tokens, and hidden persistence.
- Allow correction of public records after exit when the record remains visible or consequential.
- Keep forkability and non-retaliation language visible for communities.
- Test the exit path with keyboard navigation, mobile layout, and no-JavaScript fallback.
Offboarding terms to make explicit
Business software and platform communities often need more than privacy-law portability. They need offboarding terms that cover configuration, logs, customizations, workflow state, memory records, transition assistance, retention windows, backup behavior, fees, and deletion confirmation.
This network provides human-readable exit instructions, export of available identity and memory records, revocation of active endpoint and agent authority, a clear closure process, retention and backup limits, correction paths for visible public records, and non-retaliatory forkability where community separation is appropriate. This clause is operational guidance and does not replace legal review.
Exit packet schema fields
An exit packet should make departure reviewable without implying that VNWO enforces deletion. The packet records export, retention, revocation, correction, forkability, and non-retaliation statements.
participant_id
export_created_utc
identity_records
memory_records
reputation_records
public_evidence_records
endpoint_grants_revoked
agent_delegations_revoked
retention_explanation
public_correction_links
forkability_status
non_retaliation_statement
verification_status
Exit anti-patterns and dark patterns
Export only in unusable formats
This pattern weakens meaningful exit. A VNWO-aligned network should publish the safer rule, evidence to keep, and review path before a dispute occurs.
Support-ticket exit with no timeline
This pattern weakens meaningful exit. A VNWO-aligned network should publish the safer rule, evidence to keep, and review path before a dispute occurs.
Deleting public corrections when a user leaves
This pattern weakens meaningful exit. A VNWO-aligned network should publish the safer rule, evidence to keep, and review path before a dispute occurs.
Revocation that leaves delegated agents active
This pattern weakens meaningful exit. A VNWO-aligned network should publish the safer rule, evidence to keep, and review path before a dispute occurs.
Retention explanations that hide scope or duration
This pattern weakens meaningful exit. A VNWO-aligned network should publish the safer rule, evidence to keep, and review path before a dispute occurs.
Fork suppression through identity or reputation capture
This pattern weakens meaningful exit. A VNWO-aligned network should publish the safer rule, evidence to keep, and review path before a dispute occurs.
Common questions about exit rights
Are exit rights one single legal right?
No. VNWO uses exit rights as an umbrella civic concept. In practice, exit can involve privacy rights, product export features, account closure, contract terms, offboarding support, retention rules, and community forkability.
Is portability the same as deletion?
No. Portability concerns receiving or transferring data. Deletion or erasure concerns removal of eligible data. A participant may need both, and each can have different limits.
Does VNWO guarantee legal compliance?
No. VNWO provides static public observatory guidance. It does not replace legal review, procurement review, product-specific contractual review, or jurisdiction-specific advice.
Does VNWO execute deletion or revocation?
No. VNWO describes the open rule and expected evidence. The implementing platform, tool, steward, or legal process performs deletion, revocation, transfer, or retention decisions.
What should a SaaS or community exit clause include?
It should identify export formats, API or manual export paths, migration support, fees, timelines, retention windows, backup handling, deletion confirmation, endpoint revocation, agent disengagement, and continuity during transition.
Can a network retain some records after exit?
Possibly. The network should explain the reason, scope, retention period, and use limit for security, billing, evidence, abuse-prevention, audit, or legal records rather than implying total immediate disappearance.
What makes an exit path manipulative?
Hidden instructions, unnecessary delay, asymmetric cancellation, punitive deletion, vague retention, disabled export, forced support negotiation, or revocation paths that leave permissions active.