ANUKA Foundation Principles

Draft 0.1 — 2 August 2026
These principles translate the Network State Declaration and Manifesto into decision rules.

Normative language

The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals.

A principle marked MUST is a baseline requirement for the ANUKA shared core. A resident product may implement stricter rules, but it must document any material difference from the network baseline.

1. Participation is voluntary

Joining the network MUST be voluntary.
Participants MUST be able to stop participating, subject to existing contracts, payment obligations, security holds, dispute preservation, and applicable law.
Leaving MUST NOT erase valid historical records that other parties are entitled or legally required to retain.
A participant SHOULD be able to export the evidence and credentials they are entitled to hold in a documented format.

Reason: A network of trust cannot depend on captivity.

2. Contribution outranks status

Opportunity matching SHOULD prioritize relevant demonstrated work, evidence quality, recency, and context over titles or institutional prestige.
Credentials MAY be considered, but MUST NOT be presented as proof of capability beyond what they actually attest.
New participants MUST have a path to begin with bounded, low-risk opportunities even if they have no prior ANUKA history.

Reason: The network exists to make talent legible through action.

3. No universal human score

ANUKA MUST NOT reduce a person to one universal score intended to represent overall human worth, employability, trustworthiness, or citizenship.
Reputation views MUST be contextual to a purpose, role, domain, and evidence set.
A displayed score or summary MUST expose its inputs, method, recency, confidence, and important limitations.
Participants MUST have a documented correction or dispute path for material records.

Reason: Contextual evidence supports judgment; opaque total scores replace judgment with false precision.

4. Claims require provenance

Every material claim about quality, growth, readiness, capability, or performance MUST identify, where applicable:

the claimant or attester;
the subject;
the source system;
the metric definition;
the relevant time window;
the baseline and comparison method;
the method of collection or calculation;
the status of review;
expiration, revocation, supersession, or dispute status;
known limitations.

Public objective claims MUST have a reasonable evidentiary basis before publication.

Reason: A number without provenance is decoration, not evidence.

5. Verifiability is not truth

Cryptographic verification MUST be described as evidence of origin, integrity, schema conformance, or signature validity—not automatic proof that the underlying claim is true.
Verifiers MUST evaluate the identity and reputation of the issuer, the source data, the method, the context, and the current status.
ANUKA SHOULD support multiple independent attestations and counter-attestations when a claim is material or contested.

Reason: W3C verifiable credentials and attestation systems secure claims against tampering; trust still depends on issuers, evidence, and verification policy.

6. Evidence must be correctable

Evidence formats SHOULD support expiration, revocation, supersession, correction, and dispute links.
The system MUST NOT silently rewrite historical evidence.
Corrections MUST preserve a legible relationship to the prior record unless deletion is legally required.
Interfaces MUST distinguish current, expired, revoked, superseded, disputed, and unreviewed records.

Reason: Immutability without correction creates permanent error, not permanent truth.

7. Experiments are bounded and reversible

Before an experiment affects a live system, it SHOULD define:

owner and accountable approver;
hypothesis;
audience or traffic allocation;
primary and guardrail metrics;
duration or stopping rule;
budget and resource limit;
data-access boundary;
rollback path;
unacceptable-harm conditions.

High-risk experiments MUST require explicit approval and monitoring. Automated deployment MUST NOT remove the ability to stop or roll back a change when rollback is technically possible.

Reason: Safe contribution requires real influence with limited blast radius.

8. Quality is multidimensional

Revenue or conversion improvement MUST NOT alone establish overall quality.
Quality evaluation SHOULD consider the relevant combination of usefulness, reliability, safety, security, privacy, accessibility, fairness, maintainability, cost, and sustainability.
A metric improvement that materially degrades an agreed guardrail MUST NOT be reported as an unqualified success.

Reason: Optimizing one number can damage the system that produced it.

9. Minimum necessary access

Human and AI actors MUST receive only the permissions needed for the declared task.
Access SHOULD be time-limited, scoped, auditable, and revocable.
Production access MUST NOT be the default for experimentation.
Secrets and personal data MUST NOT be exposed merely to simplify integration.

Reason: The easiest permission model is usually the most dangerous one.

10. Privacy is a system property

Data collection MUST be tied to a declared purpose.
Public visibility MUST be opt-in for non-public evidence unless disclosure is legally required.
Interfaces SHOULD support selective disclosure and audience-specific views.
Sensitive raw data SHOULD remain offchain; public ledgers should contain only data intentionally designed for permanent public exposure or appropriate proofs and references.
Privacy risks MUST be evaluated across the full lifecycle, including aggregation and inference.

Reason: De-identification at collection does not guarantee privacy after correlation.

11. AI augments accountable actors

Every consequential AI agent action MUST be attributable to a responsible person or organization.
Agent permissions, tools, data sources, and spending limits MUST be explicit.
Material automated decisions SHOULD produce understandable logs and evidence.
AI outputs MUST be treated according to their actual validation status.
High-impact actions MUST support human review, interruption, and recovery proportional to risk.
AI systems SHOULD be evaluated using a lifecycle risk process such as NIST’s Govern, Map, Measure, Manage model.

Reason: Delegation does not eliminate responsibility.

12. The shared core is open and composable

Software described as open source MUST use an OSI-approved license.
ANUKA MUST NOT call source-available code “open source” if its license fails the Open Source Definition.
Shared protocols and schemas SHOULD be publicly documented, versioned, testable, and implementable without access to private institutional knowledge.
Components SHOULD be replaceable through stable interfaces.
The network SHOULD reuse mature standards, SDKs, APIs, and libraries before creating new ones.

Reason: A standard becomes durable when others can inspect, implement, and extend it.

13. Products remain autonomous

A resident product MAY have its own brand, legal entity, founders, pricing, treasury, roadmap, and governance.
Participation in the network MUST NOT transfer ownership unless a separate explicit legal instrument does so.
Shared-core requirements SHOULD focus on interoperability, evidence, safety, and participant rights rather than unnecessary operational uniformity.
A product MUST disclose which ANUKA services it uses and which decisions remain local.

Reason: The network should coordinate diversity, not erase it.

14. Stewardship is scoped authority

A stewardship grant MUST identify:

the product or domain;
the powers granted;
exclusions and reserved decisions;
term and renewal method;
budget or spending authority;
target and guardrail metrics;
reporting and review cadence;
compensation or economic rights, if any;
termination and handover process.

The title “steward” MUST NOT be treated as proof of equity ownership, employment status, fiduciary status, directorship, or unlimited control.

Reason: Temporary management must be operationally useful and legally legible.

15. Economic terms are explicit before work

An opportunity MUST state whether it is unpaid, fixed-fee, bounty-based, usage-based, revenue-share, prize-based, equity-related, or subject to separate negotiation.
Acceptance criteria and payment conditions MUST be understandable before a participant commits work.
Platform fees, holdbacks, refunds, dispute rules, and payment timing MUST be disclosed.
ANUKA MUST NOT imply that a payment label determines worker classification, tax treatment, ownership, or securities status.

Reason: Hidden economics destroy trust faster than bad UX.

16. Tokenless by default

Core identity, contribution, reputation, governance discussion, and conventional payment flows MUST NOT require a speculative token.
A tokenized instrument MUST have a documented functional need, threat model, legal analysis, accounting treatment, and comparison against non-token alternatives.
Tokenization MUST NOT be used to evade securities, money-transmission, tax, employment, consumer-protection, or sanctions obligations.

Reason: The network should earn utility before introducing financial complexity.

17. Legal reality overrides product language

Terms such as resident, passport, bounty, steward, contributor, owner, investor, and agent MUST be defined by the actual product and legal relationship.
Product copy MUST NOT imply government status, guaranteed returns, guaranteed work, formal accreditation, or ownership rights that do not exist.
Worker classification MUST be assessed from the real degree of behavioral and financial control and the relationship of the parties—not merely the contract label.
Jurisdiction-specific activities MUST receive qualified legal review before launch.

Reason: Renaming a regulated relationship does not remove regulation.

18. Governance is versioned and inspectable

Foundation rules MUST be version controlled.
Material changes MUST include rationale, affected parties, migration implications, and a review period appropriate to impact.
Governance decisions SHOULD link to proposals, evidence, discussion, and implementation history.
Emergency actions MAY bypass normal timing only when the authority, reason, scope, and expiration are recorded.
Participants SHOULD be able to identify which version of the rules governed a decision.

Reason: Trust requires knowing not only the rule, but which rule existed at the time.

19. Disputes produce better evidence

A dispute process MUST distinguish factual correction, methodological disagreement, contractual dispute, abuse report, and policy appeal.
Reviewers MUST disclose material conflicts of interest.
Outcomes SHOULD preserve useful reasoning without exposing unnecessary private information.
The system SHOULD learn from recurring disputes by improving schemas, acceptance criteria, and interfaces.

Reason: A healthy network does not hide disagreement; it makes disagreement legible.

20. Sustainability is part of quality

Every shared service SHOULD have an identified operating owner, funding model, recovery plan, and deprecation path.
Open-source components SHOULD document maintenance expectations and security reporting.
Commercial products MAY charge for hosting, convenience, support, distribution, verification, marketplace access, or managed operations while preserving the declared openness of the shared standard.

Reason: Infrastructure that cannot maintain itself eventually transfers its cost to users in hidden ways.

Resolving conflicts between principles

No principle eliminates judgment. When principles conflict, a decision record SHOULD state:

the decision and accountable owner;
the affected participants;
the relevant principles;
the evidence available;
the risk and reversibility;
why the chosen trade-off is proportionate;
what would cause reconsideration.

The following order is a default, not an absolute formula:

prevent unlawful or severe irreversible harm;
preserve human rights, agency, privacy, and safety;
preserve evidence integrity and correction mechanisms;
protect participant and product autonomy;
increase measurable value and learning;
improve speed, convenience, and economic efficiency.

Conformance

A product may state that it is ANUKA-aligned only if it publishes:

the version of these principles it follows;
material exceptions;
the operator responsible for enforcement;
a correction or issue channel;
enough implementation evidence to make the claim meaningful.

Formal certification criteria do not yet exist. Until a ratified conformance program is published, “ANUKA-aligned” is a documented self-declaration, not an independent certification.

Primary references

See the Source Registry for status and validation notes.

Verification record

External links checked: 2 August 2026
Document status: Draft 0.1
Legal review: Required before these principles become contractual terms or certification requirements