Amendments, Forks, and Exit

Draft 0.1 — 2 August 2026
Open licenses create rights in code and documents, not automatic rights to trademarks, private data, legal entities, payment accounts, contracts, or hosted infrastructure.

Objective

A network is more trustworthy when participants can understand how rules change and what happens when alignment ends.

ANUKA must support:

ordinary amendments;
major changes;
constitutional protection;
versioned adoption;
safe deprecation;
independent forks;
participant and product exit;
continuity of evidence and obligations;
historical records;
separation without hostage data.

The core rule is:

Rules may evolve, but changes must be versioned, reviewable, non-deceptive, and accompanied by a credible path to migrate, object, fork, or exit.

Versioned governance

Every ratified document, schema, charter, role grant, and conformance profile should have:

stable identifier;
semantic or declared version;
status;
adoption date;
effective date;
superseded version;
compatibility statement;
amendment history;
responsible body;
review date.

Example:

id: anuka:protocol:passport
version: 1.2.0
status: ratified
ratified_at: 2027-03-01T00:00:00Z
effective_at: 2027-06-01T00:00:00Z
supersedes: 1.1.0
compatibility: backward-compatible-with-migration
review_at: 2028-03-01T00:00:00Z

Change categories

Editorial correction

Fixes spelling, links, formatting, or wording without changing obligations or meaning.

Clarification

Makes intended meaning more explicit without changing substantive rights, powers, or requirements.

Compatible amendment

Adds optional fields, processes, or capabilities without breaking conforming implementations.

Major amendment

Changes obligations, authority, compatibility, data use, governance, or economic behavior materially.

Constitutional amendment

Changes protected principles, amendment thresholds, core rights, or existential network design.

Emergency patch

Temporarily addresses a critical security or legal risk and must enter ordinary review after containment.

Semantic versioning direction

For technical protocols:

patch version — corrections and nonbreaking clarifications;
minor version — backward-compatible capabilities;
major version — breaking behavior or changed mandatory requirements.

Governance documents may use the same pattern, but the change category and legal effect must also be stated.

A version number alone does not prove compatibility.

Amendment proposal requirements

A material amendment must identify:

current text or behavior;
proposed change;
reason;
affected participants and products;
protected principles involved;
legal and contractual impact;
privacy and security impact;
economic impact;
compatibility;
migration;
effective date;
objection and exit routes;
implementation owner;
rollback or sunset.

Adoption is explicit

Merging a specification into a repository does not automatically update every product or contract.

Adoption records should identify:

adopter;
version;
adopted capabilities;
exceptions;
effective date;
transition status;
responsible operator.

Resident products may remain on an older supported version during a published migration period.

Compatibility periods

Breaking changes should provide:

notice;
dual-version support where practical;
test tooling;
migration guide;
deprecation warnings;
data export;
rollback;
final support date;
security exception process.

Compatibility periods may be shortened when an old version creates material security or legal risk.

The reason must be recorded.

Deprecation lifecycle

Suggested states:

active → maintenance → deprecated → read-only → retired → archived

Active

Receives features, fixes, and support.

Maintenance

Receives critical fixes but limited new capability.

Deprecated

Still functions but should not be used for new integrations.

Read-only

Existing records remain accessible; new writes are blocked.

Retired

Operational support ends.

Archived

Documentation and historical artifacts remain available.

Unsafe-version retirement

A protocol or service may be retired urgently when it enables:

known credential compromise;
consent bypass;
unauthorized fund movement;
critical privacy exposure;
unfixable integrity failure;
unlawful behavior;
severe cross-product harm.

Urgent retirement must still publish:

affected version;
risk;
timeline;
migration or containment;
available support;
review and appeal route.

Fork types

Code fork

An independent continuation of open-source software under its license.

Specification fork

An independent continuation of openly licensed protocols or documents.

Product fork

A new product based on lawful code, data, contracts, or assets available to the forking party.

Governance fork

A community adopts different rules, councils, standards, or priorities.

Service fork

An alternative hosted implementation of compatible open protocols.

Network fork

A substantial community and product group creates an independent network using lawful open components.

Fork rights

A valid open-source or documentation license may allow:

copying;
modification;
redistribution;
independent operation;
commercial use;
compatibility implementation.

The exact license controls.

What a fork does not automatically receive

A fork does not automatically receive:

ANUKA trademarks or domain names;
official resident status;
certification marks;
private participant data;
private evidence;
hosted accounts;
customer contracts;
payment-provider relationships;
legal-entity assets;
treasury funds;
proprietary third-party content;
reputation continuity without provenance.

Trademark separation

Fork interfaces must avoid misleading affiliation.

Acceptable descriptions may include:

Forked from ANUKA Foundation version 1.2 under CC BY 4.0;
Compatible with ANUKA Passport schema 1.2;
Independent implementation; not operated or endorsed by ANUKA.

Trademark policy must define permitted compatibility and historical-reference use.

Data portability during fork or exit

Participants should be able to export eligible records including:

identifiers;
credentials;
presentations;
contribution records;
public decisions;
consent receipts;
active grants;
product charters;
protocol schemas;
payment records available to them;
status and correction history.

Export is limited by:

other people’s privacy;
contracts;
security;
intellectual property;
legal retention;
payment-provider rules;
confidential product information.

Portability may use selective or derived records rather than unrestricted raw data.

Participant exit

A participant may exit by:

revoking optional consent grants;
exporting eligible records;
resigning roles;
completing handover;
closing or unlinking accounts;
settling valid payment and contractual obligations;
choosing credential and profile visibility;
receiving a record of remaining retained data and reasons.

Exit must not falsely convert outstanding obligations into deletion rights.

Role exit

A role holder must:

notify the grantor;
transfer records;
rotate credentials;
resign signing and approval authority;
close open decisions or identify successors;
disclose unresolved incidents or conflicts;
complete final reporting.

The role registry should preserve historical term and status.

Resident-product exit

A product leaving the network should:

publish an exit notice;
identify effective date;
settle shared-service and financial obligations;
export or migrate eligible data;
revoke shared capabilities and credentials;
remove current resident or verified marks;
preserve customer and contributor commitments;
complete stewardship handover;
publish continuity and support information;
maintain historical affiliation accuracy.

Involuntary separation

A product or participant may be separated for material breach under applicable policy.

Except for urgent containment, the process should provide:

notice;
evidence;
response opportunity;
corrective path where appropriate;
independent review;
decision;
appeal;
transition;
correction of affiliation and credentials.

Separation should be scoped. Losing one shared capability does not automatically erase every contribution or credential.

Legal-entity exit or dissolution

If an ANUKA legal entity dissolves, merges, or transfers assets, it must follow applicable law and governing documents.

The network should publish:

affected entity;
decision authority;
asset and contract treatment;
trademark and IP treatment;
service continuity;
data controller or processor changes;
treasury and restricted funds;
employee and contractor obligations;
records custodian;
effect on network governance.

A constitutional vote cannot distribute legal assets contrary to law or binding restrictions.

Network continuity plan

Critical open and hosted components should identify successors or recovery paths for:

domains;
repositories;
package registries;
signing keys;
credential status services;
source registries;
documentation;
identity services;
payment records;
public decision archives;
trademarks;
security contacts.

Continuity should not depend on one founder’s personal account.

Key-person failure

The system must plan for a founder, maintainer, officer, signer, or service operator becoming unavailable.

Controls include:

multiple owners;
organization-controlled accounts;
key recovery;
documented credentials;
succession designations;
repository mirrors;
backup domains;
dead-man procedures with strict safeguards;
periodic access review.

Historical integrity

Superseded and forked records should preserve:

original version;
status at the time;
issuer or governing body;
effective period;
successor or fork relationship;
corrections;
revocation;
source links.

History must not be rewritten to imply continuous endorsement.

Exit economics

Exit terms should identify:

earned but unpaid compensation;
outstanding refunds;
sponsorship commitments;
grants and restricted funds;
reserves;
shared-service fees;
IP rights;
licenses;
revenue or ownership rights created by separate legal instruments;
tax records.

Network points, badges, or reputation do not automatically create a claim on treasury assets.

Right to dissent

Participants may support a fork or exit without automatically losing unrelated earned credentials or payment rights.

The network may enforce:

confidentiality;
security;
trademark;
contractual obligations;
acceptable conduct;
legal restrictions.

It must not use reputation punishment merely because someone advocates a lawful alternative governance model.

Amendment and fork transparency

A fork or major amendment announcement should identify:

what changes;
who controls the new system;
what remains compatible;
which data moves;
which credentials remain valid;
which marks may be used;
what participants must do;
risks and deadlines;
support contacts.

Minimum implementation baseline

Before ANUKA reaches ratified governance, it should have:

document and protocol version registry;
amendment classifications;
compatibility policy;
deprecation lifecycle;
resident adoption records;
export formats;
role and product exit checklists;
trademark policy;
continuity plan;
repository and domain succession;
historical archive;
constitutional fork and exit protections.

Sources

Verification record

Sources opened and checked: 2 August 2026
Status: Founding draft
Trademark policy required: Yes
Continuity test completed: No