Governance Architecture

Draft 0.1 — 2 August 2026
This document describes a governance architecture. It does not create a legal entity, fiduciary duty, partnership, employment relationship, voting right, ownership interest, or governmental authority.

Objective

ANUKA needs governance that can coordinate a network without pretending that every decision belongs to one global electorate.

The system must support all of the following at once:

protected network-wide commitments;
legally valid action by actual legal entities;
independent resident products;
open technical standards;
bounded authority for maintainers and stewards;
rapid local decisions;
public review of shared rules;
emergency response without permanent emergency government;
voluntary participation and credible exit.

The core rule is:

Authority must be explicit, scoped, reviewable, and exercised at the lowest level capable of making the decision safely.

Governance is not one thing

ANUKA separates several systems that are often incorrectly collapsed into one word.

Legal governance

Legal entities act through applicable law, organizational documents, boards, managers, officers, authorized agents, and contracts.

A network poll cannot by itself:

sign a contract;
transfer corporate property;
appoint a legal officer;
issue equity;
bind a third party;
satisfy a fiduciary duty;
override tax, employment, securities, privacy, or consumer law.

Protocol governance

Protocol governance defines shared schemas, interfaces, compatibility rules, registries, security requirements, and conformance processes.

Community governance

Community governance covers participation, proposals, moderation, shared norms, public discussion, appointments, and collective priorities.

Product governance

Each resident product governs its roadmap, operations, team, customers, risk, and economics subject to its own charter and applicable network commitments.

Repository governance

Repositories use maintainers, CODEOWNERS, pull requests, required reviews, CI, signed releases, and branch rules.

Operational governance

Operational teams make day-to-day decisions within approved budgets, permissions, service levels, and risk limits.

These systems may interact, but one does not silently substitute for another.

Layered authority model

ANUKA uses six governance layers.

Layer 0 — Protected foundation

The protected foundation contains the principles that define what ANUKA is allowed to become.

Examples:

voluntary participation and exit;
no universal human social score;
consent and data minimization;
evidence does not equal automatic truth;
tokenless access to core participation;
due process for material restrictions;
human accountability for AI actions;
portability and forkability of open components;
honest separation between network language and legal status.

Changes at this layer require the highest review and amendment threshold.

Layer 1 — Legal entities and fiduciary authority

This layer contains corporations, nonprofit entities, foundations, LLCs, trusts, contractors, fiscal sponsors, regulated payment providers, and other legal structures.

Their authorized bodies control:

legal assets;
bank and payment accounts;
employment;
contracts;
taxes;
insurance;
trademarks;
regulated activities;
legal filings;
fiduciary decisions.

Network governance may recommend or condition support, but cannot fabricate legal authority.

Layer 2 — Shared network protocols

This layer governs:

identity and Passport schemas;
evidence and attestation types;
reputation graph semantics;
consent request types;
Presence capabilities;
opportunity and payment event schemas;
conformance profiles;
security baselines;
shared registries;
Foundation document versions.

Protocol changes require public specifications, compatibility analysis, implementation evidence, and versioning.

Layer 3 — Shared services and infrastructure

This layer governs hosted services used by multiple resident products, such as:

authentication;
registries;
messaging;
search;
shared APIs;
billing orchestration;
identity wallets;
analytics infrastructure;
source registries;
documentation hosting.

Service operators receive bounded operational authority, not ownership of the network.

Layer 4 — Resident products and communities

Resident products control their own:

positioning;
roadmap;
pricing;
customer policies;
product operations;
contributor programs;
product treasury;
local governance;
brand, subject to trademark agreements;
adoption of optional network capabilities.

They remain accountable for published commitments and cannot claim network certification that has not been granted.

Layer 5 — Working groups and local execution

Working groups, maintainers, project teams, reviewers, and agents execute bounded tasks.

Local decisions should not require network-wide votes when they:

remain within an approved charter;
do not spend outside an approved budget;
do not change protected rights;
do not introduce material shared risk;
are reversible at reasonable cost;
affect only consenting participants.

Source-of-authority order

For legal consequences, the following order applies:

applicable law and binding court or regulator action;
valid contracts and legal-entity governing documents;
authorized legal-entity decisions;
ratified ANUKA constitutional documents;
ratified shared protocols and policies;
resident-product charters and policies;
delegation grants and working-group charters;
local operational decisions.

This hierarchy does not mean higher layers should micromanage lower ones. It identifies what controls when two instructions conflict.

Decision classes

Every material proposal must declare a decision class.

G0 — Local and reversible

Examples:

wording changes;
nonbinding experiments;
local issue triage;
reversible UI changes;
work inside an approved sprint and budget.

Decision authority: designated maintainer, steward, or team.

G1 — Product policy or operations

Examples:

product pricing;
roadmap priority;
contributor acceptance rules;
product-specific data policy;
product budget allocation.

Decision authority: product governance defined by its charter.

G2 — Shared service or protocol

Examples:

API behavior;
common schemas;
registry policy;
identity or consent flow changes;
network-wide conformance requirements.

Decision authority: relevant protocol council or ratification process.

G3 — Shared resource or institutional

Examples:

shared treasury allocation;
appointment of a network council;
licensing changes;
trademark policy;
creation of a common service;
long-term vendor commitments.

Decision authority: designated governing body plus any legally required approval.

G4 — Constitutional or existential

Examples:

changing protected principles;
introducing a mandatory token;
removing portability or exit rights;
creating universal person scoring;
changing amendment thresholds;
transferring control of core trademarks or registries;
dissolving or fundamentally reconstituting the Foundation layer.

Decision authority: constitutional amendment process and applicable legal bodies.

Decision object

Every G1–G4 decision should produce a durable decision object.

Minimum fields:

id: GOV-2026-0042
title: Adopt Passport schema v0.2
decision_class: G2
status: ratified
scope:
  - passport-schema
proposer: participant:anuka:123
responsible_body: Identity Protocol Council
created_at: 2026-08-02T10:00:00Z
review_opened_at: 2026-08-05T00:00:00Z
review_closed_at: 2026-08-19T00:00:00Z
decided_at: 2026-08-21T00:00:00Z
implementation_owner: team:identity-core
supersedes: GOV-2026-0018
sunset_or_review_at: 2027-02-21T00:00:00Z

The object must link to:

proposal text;
impact analysis;
alternatives;
conflicts of interest;
review comments;
objections and responses;
vote or consensus record;
implementation evidence;
later amendments or supersession.

Subsidiarity

A decision belongs at the lowest level where all material effects can be understood and governed.

Escalation is justified when a decision:

changes a shared protocol;
creates cross-product risk;
spends shared funds;
changes access to network rights;
affects legal entities outside the local team;
creates irreversible dependency;
changes public trust claims;
cannot be corrected locally.

Escalation must not be used merely to delay a local team or manufacture veto power.

Participation is contextual

ANUKA does not assume one global voter roll.

Eligibility may depend on:

affected product;
relevant contribution history;
delegated role;
legal membership or directorship;
active maintenance responsibility;
customer or sponsor status;
security clearance;
conflict-of-interest status;
possession of a relevant credential.

Eligibility must be declared before the decision period and must not be changed retroactively to manipulate an outcome.

Influence and earned authority

Contribution may justify influence, but influence remains contextual.

A strong contributor to one product does not automatically gain authority over:

another product;
Foundation legal assets;
security response;
another participant’s data;
treasury funds;
employment decisions;
constitutional amendments.

Authority must be earned, delegated, or legally granted for the relevant scope.

No default token voting

ANUKA is tokenless by default.

Core governance must not require ownership of a speculative or transferable token.

Token-weighted voting is especially inappropriate for:

identity rights;
privacy rights;
moderation appeals;
employment-like decisions;
constitutional protections;
access to correction procedures;
security incident response.

A resident product may use a lawful token or customer-weighted mechanism for a narrow purpose only after publishing the rights, risks, conflicts, and legal analysis.

Legal and network separation

If a community decision requires action by a corporation, nonprofit, or other entity, the record must identify:

which entity must act;
which authorized body or officer can act;
whether the decision is advisory or binding;
what legal review is required;
which assets or contracts are affected;
whether a separate formal resolution is needed.

The public interface must not say the community approved the transfer when the community lacked legal authority to transfer the asset.

Governance service levels

Governance must be timely enough to remain usable.

Each decision class should publish target times for:

acknowledgement;
review start;
response to objections;
final decision;
implementation;
appeal;
scheduled review.

Failure to decide is itself a governance outcome and should be visible.

Governance health metrics

Useful metrics include:

time from proposal to decision;
percentage of proposals with a named owner;
percentage of objections receiving a reasoned response;
concentration of proposal authorship;
concentration of approvals;
inactive roles and expired delegations;
implementation completion rate;
reversal and appeal rate;
participation by affected groups;
conflicts disclosed and recusals recorded;
emergency actions reviewed on time;
percentage of decisions with sunset dates.

Metrics must not become one universal governance score.

Anti-capture controls

The architecture should resist capture by founders, investors, vendors, maintainers, token holders, customers, governments, or highly active insiders.

Controls include:

scoped authority;
term limits or scheduled renewal;
public charters;
conflict disclosure;
recusal;
multi-party approval for sensitive actions;
independent appeal paths;
open source and export rights;
transparent funding relationships;
protected constitutional rights;
product autonomy;
ability to fork open components;
periodic concentration review.

Minimum implementation baseline

Before ANUKA describes its governance as operational, it should have:

published decision classes;
a proposal template;
public decision records;
role and delegation registry;
conflict-of-interest disclosures;
resident-product charters;
amendment rules;
emergency authority limits;
repository protection rules;
appeal and correction procedures;
a clear legal-entity authority map.

Sources

Verification record

Sources opened and checked: 2 August 2026
Governance baseline: Founding draft
Legal-entity implementation review required: Yes
Ratification required: Yes