Portability, Recovery, and Exit

Draft 0.1 — 2 August 2026
Portability does not mean that every private record can be copied or that legal obligations disappear. It means that ANUKA should not hold identity and earned evidence hostage to one interface or provider.

Objective

A network built on portable reputation must work when:

a participant loses a device;
a key is compromised;
a company changes administrators;
a product is sold or rebranded;
a steward leaves;
a credential issuer disappears;
a participant wants to leave ANUKA;
the hosted ANUKA service is unavailable;
an independent implementation replaces a network component.

The governing rule is:

Exit must be a supported protocol, not a punishment.

Portability domains

ANUKA distinguishes portability of:

account data;
identifiers;
credentials and attestations;
contribution records;
public profile and passport views;
organization and product relationships;
schemas and capability definitions;
configuration;
financial records;
private source evidence;
governance history.

Not every domain has the same owner, controller, retention duty, or export right.

Participant export

A participant export should include, where authorized:

stable ANUKA participant identifier;
linked identifier metadata;
credentials held by the participant;
attestations naming the participant;
accepted contribution records;
reviews written by or about the participant;
rewards and payment references appropriate for export;
disputes and corrections;
passport presentation definitions;
public profile content;
consent and sharing history;
machine-readable provenance and schema versions.

The export should distinguish:

participant-authored data;
issuer claims;
organization-confidential evidence;
platform-generated summaries;
records retained under legal obligation.

Organization export

An organization should be able to export:

organization and product identity records;
verified domains and relationships;
project configuration;
public and permissioned passport definitions;
capabilities and module settings;
contribution and opportunity records it is entitled to retain;
evidence manifests and connector metadata;
stewardship grants and handovers;
audit and governance records;
credentials it issued;
status and revocation records;
billing and contract records available under applicable agreements.

Exports must not include private participant data beyond the organization’s lawful and contractual rights.

Product continuity

Products may change:

domain;
operator;
legal owner;
brand;
repository;
steward;
infrastructure;
ANUKA service provider.

The product ID should remain stable when continuity is genuine. Material ownership or operating changes create dated relationship events.

A product split, merger, or fork should create explicit successor relationships rather than silently reuse one identity.

Credential portability

Portable credentials should be exportable in their native signed form with:

schema reference;
issuer;
subject;
proof;
status information;
evidence references permitted for export;
terms of use where present;
human-readable rendering metadata.

ANUKA should support standards-based issuance and presentation so a credential can move to compatible wallets or verifiers.

Hosted passport pages are convenience views, not the only form of the credential.

Contribution portability

A participant should be able to carry evidence of legitimate contribution without exposing a company’s confidential details.

Possible portable forms:

public contribution credential;
redacted work record;
capability credential;
outcome credential with aggregate metric;
company endorsement;
cryptographic digest with permissioned evidence available on request.

The company and participant should agree to portable disclosure terms before or during the assignment where practical.

Data export formats

The baseline export should use:

UTF-8 JSON for structured records;
JSON-LD where required by adopted credential vocabularies;
signed credentials in their native format;
CSV for simple tabular transaction or event summaries where useful;
Markdown or HTML for human-readable reports;
media files in standard formats;
manifest files listing checksums, schemas, and versions.

A compressed archive should contain an index explaining each file and its privacy class.

Export manifest

{
  "exportVersion": "0.1",
  "exportId": "anuka:export:01J...",
  "subject": "anuka:person:01J...",
  "generatedAt": "2026-08-02T00:00:00Z",
  "scope": [
    "credentials",
    "contributions",
    "disputes",
    "passport-definitions"
  ],
  "files": [
    {
      "path": "credentials/credential-001.jsonld",
      "mediaType": "application/vc+ld+json",
      "sha256": "...",
      "schema": "https://www.w3.org/TR/vc-data-model-2.0/"
    }
  ],
  "excluded": [
    {
      "category": "organization-confidential-evidence",
      "reason": "Not controlled by export subject"
    }
  ]
}

Recovery classes

Restores access to an ANUKA account after loss of an authenticator.

Key recovery

Replaces or rotates cryptographic keys used for credentials, attestations, organization control, or product manifests.

Organization recovery

Restores authorized administration after staff departure, compromise, or governance change.

Product recovery

Resolves control of a product identity, domain, repository, or presence manifest.

Issuer recovery

Handles loss or compromise of an issuer’s signing infrastructure.

Evidence-source recovery

Reconnects a source integration while preserving prior provenance and marking gaps.

These recovery paths must not be conflated into a single email reset.

Account recovery policy

Recovery strength should match the impact of the recovered authority.

Possible evidence includes:

recovery codes;
another enrolled passkey;
verified email or identity provider;
trusted organization administrator;
domain or repository challenge;
delayed manual review;
previously issued recovery credential;
multi-party approval for high-impact organization roles.

Recovery must generate an audit event and notify existing trusted channels where safe.

Key rotation

Key rotation should support:

planned rotation;
emergency compromise rotation;
overlap period;
historical verification;
new signing key publication;
old key deactivation;
credential or attestation status review;
dependent service update.

Historical proofs should remain verifiable against the key material and controller state appropriate to their issue time where the adopted method supports it.

Issuer compromise

If an issuer key is compromised:

disable new issuance;
publish compromise status;
rotate keys;
determine affected time range;
suspend or revoke affected credentials where justified;
reissue valid claims;
notify holders and relying parties;
publish an incident report appropriate to risk;
preserve evidence for investigation.

Do not revoke every historical credential reflexively if the compromise scope can be established more accurately.

Organization administrator recovery

Organization control should not depend permanently on one founder account.

A mature organization profile should support:

multiple administrators;
role separation;
emergency contacts;
two-person approval for critical actions;
domain and registry recovery evidence;
succession policy;
removal of departed administrators;
recovery waiting periods;
dispute escalation.

Steward handover

When a Product Steward leaves or a grant expires, handover should record:

effective time;
outgoing and incoming steward;
current goals and metrics;
open decisions;
active experiments;
budgets and commitments;
credentials and secrets transferred through secure channels;
unresolved disputes;
rollback or emergency contacts;
final review and sign-off.

A steward’s reputation retains legitimate historical contribution, while active authority ends according to the grant.

Agent recovery and continuity

AI agents require lifecycle controls:

revoke agent credentials;
rotate tool tokens;
bind records to model and policy versions;
transfer principal only through explicit authorization;
disable an unsafe version;
preserve action history;
re-run or reproduce critical outputs where possible;
prevent a replacement agent from inheriting hidden authority automatically.

Leaving the network

A participant may stop using ANUKA while legitimate historical records remain in systems controlled by other parties.

Exit controls should allow:

account closure;
public profile removal;
revocation of optional sharing links;
disconnection of integrations;
export of portable records;
deletion requests for eligible data;
retention explanation for records that cannot be deleted immediately;
withdrawal from governance and notifications;
revocation of active roles and agent authority.

Exit must not erase a company’s lawful payment record or another party’s signed claim automatically. The system should instead distinguish deletion, loss of visibility, revocation, and retained history.

Right to contest versus right to erase

A disputed claim may need correction or contextualization even when deletion is not appropriate.

The product should provide separate actions:

correct inaccurate data;
dispute an interpretation;
hide an optional public presentation;
revoke a consented sharing link;
request deletion of eligible personal data;
request restriction of processing;
append a response or context;
appeal a decision.

Forkability

Open foundation components should be forkable under their licenses.

A fork may reuse:

open-source code;
public schemas;
published protocol documents;
reference implementations;
public data licensed for reuse.

A fork does not automatically receive:

ANUKA trademarks;
private network data;
hosted credentials or secrets;
contractual relationships;
user consent for a new controller;
governance legitimacy;
access to payment infrastructure.

Service-provider exit

ANUKA should design for migration away from any one infrastructure provider.

Requirements include:

documented data exports;
provider-independent IDs where practical;
replaceable storage and signing components;
standard credential formats;
source connector abstraction;
DNS and domain-control procedures;
infrastructure-as-code or reproducible deployment documentation;
dependency inventory;
recovery of encrypted backups;
migration tests.

Backup and restoration

Backups must include:

encrypted data;
schema and migration versions;
key-management metadata without exposing secrets improperly;
credential and status records;
audit logs;
organization and role state;
restore instructions;
integrity checks.

Restoration exercises should be tested, not merely documented.

Availability without central ANUKA

Where feasible, a verifier should still be able to inspect a signed exported credential if the hosted ANUKA service is unavailable.

However, verification may still depend on:

issuer keys;
status lists;
schemas;
evidence access;
chain or registry availability.

Offline verification limitations must be explicit.

Retention

Retention rules should state:

data category;
controller or responsible entity;
purpose;
duration;
legal or contractual basis where applicable;
deletion or archival process;
effect of disputes and litigation holds;
public versus private retention;
status after account closure.

Permanent because blockchain is not a valid universal retention policy.

Deceased or incapacitated participants

A later governance and legal policy may support trusted succession, estate requests, or memorialization.

The MVP should not invent informal access-transfer rules for accounts containing funds, company authority, or sensitive records.

Prohibited lock-in patterns

ANUKA must not:

make hosted passport rendering the only credential format;
require payment to export basic participant records;
destroy reputation because a subscription ends;
require public disclosure to achieve portability;
let a former steward retain hidden active credentials;
silently transfer organization control after email-domain reuse;
make a lost wallet permanently destroy a person’s identity history;
use immutable public ledgers for unnecessary personal data;
claim full deletion when retained records still exist;
prevent lawful forks of open-source components.

MVP acceptance criteria

The first portability release is ready when:

participants can export credentials, contributions, disputes, and passport definitions;
organizations can export project configuration and records they control;
exports include a checksum and schema manifest;
public passport removal is separate from credential revocation;
login recovery and cryptographic key rotation are separate flows;
organization administration does not rely on one account;
stewardship grants expire and handover records exist;
integrations can be disconnected cleanly;
account closure explains retained data;
standard signed credentials remain independently inspectable where technically possible.

Sources

Verification record

Sources opened and checked: 2 August 2026
Portability and recovery status: Draft
Privacy, records-retention, estate, tax, employment, and jurisdiction-specific deletion review required: Yes