Deprecation, Transfer, Shutdown, and Archival

Draft 0.1 — 2 August 2026
Product exit must preserve legal duties, user rights, payment obligations, evidence integrity, and honest affiliation history. A shutdown notice does not erase outstanding obligations.

Objective

Products end, split, merge, get sold, lose maintainers, outgrow their architecture, or discover that the original idea should stop.

ANUKA treats ending well as a product capability.

The governing rule is:

No participant should lose legitimate data, earned evidence, money, appeal rights, or historical truth merely because a product changes operator or stops operating.

Transition types

Feature deprecation

A capability is being replaced or removed while the product continues.

Protocol deprecation

A product stops supporting a schema, API, event, credential, or integration version.

Provider migration

The product changes infrastructure, payment, analytics, identity, or other service provider.

Stewardship transfer

Operational authority moves to another steward while ownership remains.

Operator transfer

The operating legal entity or responsible organization changes.

Ownership transfer

Legal ownership or controlling assets change through an authorized transaction.

Product merger

A product is combined with another product or brand.

Product split or fork

One product becomes several independent products.

Dormancy

Operations pause but may resume.

Shutdown

The product or material service ends.

Emergency retirement

A capability is removed rapidly because continued operation is unsafe, unlawful, incompatible, or materially harmful.

Transition record

Every material transition creates a record containing:

transition ID;
product and affected capabilities;
transition type;
reason;
authority and decision record;
current and future operator;
affected users, contributors, sponsors, customers, and products;
dates;
obligations;
data plan;
payment plan;
credential and evidence plan;
protocol and API plan;
support plan;
communication plan;
risk and rollback;
archive location;
completion evidence.

Deprecation stages

A default lifecycle:

proposed → announced → discouraged → read_only_or_limited → unsupported → removed → archived

Emergency retirement may compress stages but must record the reason and retrospective review.

Deprecation notice

A notice states:

what is changing;
why;
who is affected;
current status;
replacement or alternative;
migration steps;
dates;
data and financial impact;
support path;
compatibility implications;
whether the change is reversible;
how to object or request assistance.

Do not hide deprecation only in release notes when users must act.

Notice periods

Notice periods depend on:

contract;
legal obligation;
product risk;
availability of alternatives;
user migration burden;
dependency use by other products;
security urgency;
data export complexity;
financial commitments.

The compatibility protocol may define normal support windows, but contracts and emergency safety can alter them.

Feature deprecation requirements

identify usage and affected journeys;
stop new adoption where appropriate;
provide replacement guidance;
support accessible migration;
preserve necessary exports;
update documentation and support;
clean feature flags and dead code;
remove permissions and data collection no longer needed;
archive decisions and metrics;
verify no hidden dependency remains.

Protocol and API deprecation

A protocol transition includes:

old and new versions;
compatibility matrix;
migration guide;
conformance tests;
SDK and CLI changes;
webhook and event behavior;
credential or schema implications;
consumer inventory;
telemetry of remaining use;
final disablement criteria;
archive of schemas and documentation.

Historical records remain interpretable with their original schema versions.

Transfer due diligence

Before operator or ownership transfer, review:

legal authority;
assets and contracts;
domains and trademarks;
repositories and licenses;
user terms and notices;
privacy roles and data transfers;
payment processor accounts;
outstanding balances, refunds, disputes, and taxes;
credentials and signing keys;
cloud and provider accounts;
security findings;
incidents;
support obligations;
contributor rights and evidence;
sponsorship commitments;
governance and founder rights;
jurisdictions;
sanctions or counterparty restrictions.

ANUKA network status does not substitute for transaction counsel or diligence.

Authority transfer

Transfer requires an explicit capability and account map.

Items may include:

product-owner role;
organization administration;
domain registrar;
DNS;
code repositories;
CI/CD;
cloud infrastructure;
payment processor;
banking or payout account;
support systems;
analytics;
signing keys;
extension stores;
app stores;
documentation and status page;
social and communication accounts;
emergency access.

Each transfer records old owner, new owner, time, approver, evidence, and revocation of obsolete access.

Key and credential transition

A transfer plan covers:

rotation of secrets;
signing-key continuity or replacement;
credential issuer changes;
verification-method updates;
DID or controller-document changes where used;
certificate renewal;
webhook secret rotation;
revocation of former operator access;
recovery contacts;
archival verification.

Private keys should not be copied casually when rotation is safer.

Data transition

For each data class decide:

continue under new operator;
export to participant or organization;
migrate to replacement service;
retain for obligations;
aggregate or anonymize where appropriate;
delete;
archive under restricted access;
preserve status and provenance.

The plan identifies controller or responsible party before and after transfer where applicable.

A new operator or materially different purpose may require:

updated notice;
new authorization or consent;
opt-out or exit;
limited transition processing;
suspension of secondary uses;
new processor agreements;
changed data-request routing.

Existing consent must not be stretched silently to unrelated purposes.

Participant data export

Before shutdown, participants should have a reasonable way to export relevant information such as:

profile and account data;
submitted feedback;
opportunities and assignments;
contribution evidence;
credentials and presentations;
consent and connected-access records;
payment and transaction records;
dispute and appeal records;
public content;
preferences.

Exports must protect third-party privacy and secrets.

Reputation and contribution continuity

A shutdown must not invalidate legitimate earned evidence merely because the issuing product no longer operates.

The plan should preserve:

issuer and product identity;
credential and attestation status;
contribution records;
review and outcome evidence;
revocation or supersession information;
schema and verification methods;
historical operator dates;
dispute context.

Where future status checks cannot be maintained, this limitation must be recorded and a durable status strategy considered.

Payment reconciliation

Before financial closure:

reconcile charges;
complete or refund sponsorships;
resolve earned but unpaid contributor amounts;
process authorized refunds;
handle disputes and chargebacks;
settle reserves and negative balances;
stop new transactions;
close payouts safely;
preserve tax and accounting records;
notify affected parties;
retain access for required reconciliation.

A product must not disappear while holding ambiguous participant balances.

Contracts and subscriptions

Shutdown planning addresses:

renewals;
prepaid periods;
credits;
data-processing terms;
enterprise commitments;
service levels;
vendor obligations;
termination rights;
notices;
refunds or transition support.

Roadmap intent is separate from contractual obligation.

Support during transition

The transition provides:

dedicated support route;
accessible communication;
migration help;
account and identity assistance;
payment and refund escalation;
security contact;
status updates;
final support date;
post-shutdown contact for residual obligations.

Communication audiences

active users;
account administrators;
contributors;
sponsors;
paying customers;
integration consumers;
Resident products;
providers;
employees or contractors;
investors or counterparties;
regulators or authorities where required;
public registry viewers.

Messages are tailored to actual impact.

Accessibility of transition

Migration and shutdown flows must be accessible.

This includes:

notices;
export tools;
cancellation;
refunds;
support;
authentication and recovery;
replacement-service instructions.

Users with disabilities must not receive shorter or harder migration routes.

Product registry update

The ANUKA registry records:

current lifecycle state;
transition type;
announcement date;
effective date;
replacement or successor;
operator history;
supported protocol status;
verification expiration;
archive links;
support contact;
historical affiliation.

Verification and badges

Current verification must be:

suspended, expired, transferred, or reissued according to the verification program;
visibly dated;
removed from active claims when no longer valid;
preserved historically.

A successor does not inherit verification automatically.

Forks and independent continuation

Open-source or open-content components may continue under their licenses.

A fork must distinguish:

code and content rights;
ANUKA trademarks;
product identity;
hosted services;
private data;
contracts;
credentials and issuer identity;
historical affiliation;
current network status.

Forking code does not transfer users, money, domains, or legal authority.

Archival package

A product archive may include:

final Product Charter;
operator timeline;
public documentation;
schemas and protocol versions;
release manifests;
public roadmap and decisions;
public incident reports;
credential verification information;
known limitations;
shutdown record;
source code and license where applicable;
preservation instructions.

Sensitive records remain under controlled retention.

Archive integrity

Archives should use:

stable URLs where possible;
content hashes;
version tags;
immutable release artifacts;
provenance;
readable open formats;
multiple storage locations for critical public history;
periodic integrity checks.

Data deletion versus archival

Products must distinguish:

deletion of active operational copies;
legal or contractual retention;
immutable public history;
revoked credentials;
de-identified aggregate records;
controlled evidence preservation;
backups and expiration.

“Deleted” must not mean merely hidden from the UI.

Emergency shutdown

Emergency retirement may be required for:

active compromise;
unsafe financial behavior;
unauthorized data disclosure;
unavailable accountable operator;
unlawful operation;
critical provider failure;
dangerous autonomous-agent behavior;
inability to verify integrity.

Emergency actions remain logged, scoped, time-limited where possible, and reviewed retrospectively.

Shutdown completion record

Completion requires evidence that:

new use is stopped;
users were notified;
exports were offered;
payments reconciled;
credentials and verification status handled;
provider and access shutdown completed;
secrets rotated or destroyed;
domains and redirects configured;
registry updated;
support route remains for residual issues;
archive created;
open obligations assigned.

Dormancy review

Dormant status must not become indefinite ambiguity.

A review decides whether to:

reactivate;
continue dormancy with a date;
transfer;
merge;
fork;
shut down.

AI-agent shutdown

Agent transitions include:

disable registrations;
cancel tasks;
revoke grants;
rotate credentials;
preserve execution evidence;
stop memory writes;
export or delete memory according to policy;
disable tool access;
disclose model or host changes;
retain accountable principal history.

An abandoned agent must not retain standing authority.

Anti-patterns

disappearing without notice;
leaving domains or extension listings uncontrolled;
closing support before refunds and exports;
transferring data without reviewing purpose and authority;
copying private keys instead of rotating them;
inheriting verification automatically;
deleting negative history during a sale;
leaving webhooks and API keys active;
keeping stale feature flags and collection;
marking balances as zero without reconciliation;
calling a shutdown “maintenance” indefinitely.

MVP acceptance criteria

transition types and records exist;
deprecation stages are visible;
user-facing notices state dates and migration;
authority and credentials are transferred through a checklist;
data purpose and consent changes are reviewed;
participant export exists;
legitimate contribution evidence remains interpretable;
payments and sponsorships reconcile before closure;
verification and registry status are updated;
support persists for residual obligations;
archives preserve public history and schema meaning;
dormant products receive review;
agent grants are revoked during shutdown.

Verification record

Transition baseline checked: 2 August 2026
Shutdown as obligation erasure: Prohibited
Participant export and financial reconciliation: Required
Successor verification inheritance: Not automatic