Roles, Councils, and Delegated Authority

Draft 0.1 — 2 August 2026
ANUKA role names describe network capabilities. They do not automatically create corporate office, employment, partnership, agency, fiduciary duty, ownership, or regulatory status.

Objective

Distributed networks fail when authority is either invisible or everywhere.

ANUKA uses explicit role and delegation records so participants can answer:

who may decide;
for what scope;
under which policy;
until when;
with which budget;
subject to whose review;
what requires additional approval;
how authority is suspended or transferred.

The core rule is:

No title without a charter; no sensitive capability without a scope, expiry, and accountable principal.

Role categories

Participation roles

Participant

May use public or permissioned network capabilities under applicable policies.

Contributor

Has created a recognized contribution such as code, research, design, testing, review, funding, operations, or community work.

Contribution does not automatically create governance authority.

Provides funds or resources to an opportunity, feature, working group, product, or shared program.

Sponsorship does not automatically create roadmap control, equity, or voting authority.

Technical roles

Maintainer

Has authority over a declared repository, package, service, schema, or technical domain.

Maintainer authority may include:

issue triage;
review;
merge approval;
release preparation;
dependency updates;
operational response.

Sensitive releases should require multiple maintainers or separate release approval.

Code owner

Is designated for required review of changes to specified repository paths.

CODEOWNERS is a repository control, not proof of legal ownership.

Reviewer

Evaluates evidence, implementation, quality, security, policy, or conformance against declared criteria.

Release authority

May authorize a specific release after required checks pass.

Product roles

Product Founder

Established a product’s initial mission, legal structure, assets, brand, or operating mandate.

Founder status does not automatically grant permanent unilateral control over every future network decision.

Product Steward

Receives time-bounded authority to operate or improve a product or domain under a Stewardship Grant.

Product Council Member

Participates in product-level governance under a resident-product charter.

Product Treasurer

Administers an approved product budget but may not alter beneficial ownership, merchant status, or legal obligations beyond authorization.

Network roles

Protocol Council Member

Governs a shared protocol or registry under a charter.

Foundation Maintainer

Maintains Foundation documents and may approve editorial or process-compliant changes within scope.

Constitutional Delegate

Participates in constitutional review or ratification under a defined electorate.

Records Secretary

Maintains agendas, minutes, decision records, role registries, and archival integrity.

Governance Facilitator

Runs meetings and proposal processes, categorizes objections, and helps establish whether consensus exists.

A facilitator does not gain substantive veto power merely by controlling the process.

Treasury Approver

Approves shared-resource transactions within declared limits and segregation-of-duties rules.

Security Responder

Receives emergency capabilities under the Security and Incident Charter.

Legal-entity roles

Directors, managers, members, officers, employees, contractors, registered agents, legal counsel, and authorized signers exist only through applicable law and legal-entity records.

ANUKA must not infer these roles from community badges or governance votes.

AI-agent roles

AI agents may receive machine-readable capabilities such as:

draft proposal;
summarize comments;
open pull request;
run checks;
prepare payment allocation;
query a registry;
execute a reversible deployment;
monitor a policy condition.

An AI role record must identify:

principal;
model or service;
tools;
data scope;
action scope;
monetary limit;
expiry;
logging destination;
human approval requirements;
emergency disable path.

Councils

A council is a continuing multi-person body responsible for a declared governance domain.

Possible councils include:

Constitution Council;
Identity and Reputation Protocol Council;
Presence Protocol Council;
Economy and Stewardship Council;
Security Council;
Foundation Editorial Council;
Treasury Council;
Resident Product Council;
Appeals Panel.

Councils must not exist merely to create prestige. Every council needs a clear necessity and accountable output.

Council charter

Every council charter must define:

id: council:identity-protocol
name: Identity and Reputation Protocol Council
purpose: Maintain shared identity, Passport, consent, and reputation standards.
scope:
  - identity-protocol
  - passport-schema
  - consent-registry
reserved_out_of_scope:
  - employment-screening
  - legal-entity appointments
member_count: 5
quorum: 3
decision_method: rough-consensus-with-recorded-vote-fallback
term_months: 12
maximum_consecutive_terms: 3
appointing_body: foundation-governance
reporting_period_days: 90

The charter must also specify:

eligibility;
appointment and removal;
chair or facilitator selection;
conflict rules;
meeting and record requirements;
emergency authority;
budget authority;
appeal path;
dissolution and transition.

Council composition

Composition should reflect the council’s actual risks and affected parties.

A protocol council may need a mix of:

implementers;
security expertise;
privacy expertise;
resident-product operators;
contributor representatives;
user or holder perspective;
legal or compliance advisors;
accessibility expertise.

Advisors may participate without binding decision authority.

No council should imply democratic representation it does not actually have.

Appointment paths

Roles may be granted through:

election;
appointment by a designated body;
earned contributor nomination and confirmation;
product-founder appointment within reserved powers;
legal-entity resolution;
time-limited emergency designation;
service contract;
automated policy for low-risk technical roles.

The appointment path must match the authority being granted.

A repository maintainer may be appointed by project maintainers; a corporate director cannot be appointed merely through a repository pull request.

Delegation Grant

Every material delegation must be a versioned object.

id: DEL-2026-0137
grantee: participant:anuka:456
grantor: council:economy
role: marketplace-operations-steward
scope:
  - opportunity-moderation
  - payout-review
allowed_actions:
  - approve_opportunity_publication
  - hold_payout_for_documented_review
prohibited_actions:
  - change_fee_schedule
  - access_unrelated_passport_data
  - transfer_shared_treasury
monetary_limit_usd: 5000
starts_at: 2026-09-01T00:00:00Z
expires_at: 2026-12-01T00:00:00Z
review_at: 2026-10-15T00:00:00Z
revocation_authority:
  - council:economy
  - security-responder:on-call

Minimum fields:

grantor;
grantee;
legal or governance basis;
role;
scope;
allowed actions;
prohibited actions;
financial and data limits;
start and expiry;
approval requirements;
review date;
logging requirements;
revocation path;
handover requirements.

Capability model

Roles should resolve to capabilities rather than broad administrator status.

Prefer:

proposal.review.security;
registry.schema.publish;
treasury.payment.approve_under_5000;
product.release.sign;
incident.credential.revoke.

Avoid:

superadmin;
all_access;
governance_owner;
permanent wildcard permissions.

A role can aggregate capabilities, but the capabilities remain inspectable.

Segregation of duties

Sensitive operations should separate initiation, review, approval, and execution.

Examples:

the person proposing a shared payment should not be its only approver;
the person issuing a credential should not be the sole reviewer of a dispute concerning it;
a steward should not unilaterally expand their own grant;
a security responder should not permanently ratify emergency policy;
a developer should not alone approve, sign, and deploy a high-risk release.

Segregation must be proportionate; tiny teams may use recorded compensating controls.

Terms and renewal

Continuing roles should have:

fixed terms;
renewal criteria;
activity expectations;
review dates;
succession plans;
maximum consecutive terms where capture risk is material.

Renewal should consider:

contribution and attendance;
quality of decisions;
conflict management;
responsiveness;
completion of reporting duties;
security and policy compliance;
trust of affected participants.

Renewal is not automatic entitlement.

Inactivity

A role may become inactive when the holder:

misses required meetings or reviews;
stops responding;
no longer performs the work;
loses necessary technical access;
has an unresolved conflict;
leaves the relevant product;
cannot meet legal or security requirements.

Inactive roles should be suspended or expire rather than remain silently authoritative.

Conflicts of interest

A conflict exists when personal, employer, investor, family, financial, competitive, or legal interests could materially affect judgment.

Required actions may include:

disclosure;
public or private conflict record;
recusal from discussion;
recusal from vote;
independent reviewer;
narrowed role;
removal from a matter;
termination of the role.

Disclosure alone is not always sufficient.

Compensation

Roles may be volunteer, paid, reimbursed, salaried, contracted, bounty-based, grant-funded, or compensated through another legal arrangement.

Compensation must disclose:

payer;
amount or formula;
period;
expected work;
expense policy;
conflicts;
applicable contract and tax treatment.

Compensation does not invalidate authority, but hidden compensation undermines trust.

Removal and suspension

A role may be suspended or removed for:

expiry;
resignation;
inactivity;
material policy breach;
security risk;
conflict that cannot be managed;
abuse of authority;
failure to report;
loss of required legal status;
governing-body decision under the charter.

Except for urgent containment, removal should provide:

notice;
reasons;
evidence;
response opportunity;
decision record;
appeal where appropriate;
handover and credential revocation.

Handover

A handover must transfer or close:

repository access;
service credentials;
signing keys;
open proposals;
budgets;
vendor relationships;
incident context;
decision logs;
records and documentation;
pending obligations.

No role transition is complete while privileged credentials remain active without a responsible owner.

Public role registry

The network should maintain a registry showing:

active role;
holder or accountable organization;
scope;
grantor;
start and expiry;
charter;
public conflicts;
status;
contact route;
superseding grant.

Private security or personal details may be omitted, but the existence and scope of material authority should be visible.

Anti-capture requirements

High-impact councils should periodically review:

employer concentration;
founder concentration;
investor concentration;
geographic and jurisdictional concentration;
overlapping roles;
repeated recusals;
dependence on one vendor;
inactive seats;
appointment pipeline;
accessibility to new contributors.

Diversity of employers or geography does not automatically guarantee independence; actual conflicts and incentives matter.

AI-agent governance

AI agents may not:

appoint themselves;
renew their own authority;
expand their own scope;
become the accountable principal;
cast independent constitutional votes;
hold private keys without approved custody controls;
make irreversible treasury transfers without required approval;
conceal model or tool changes.

Material model, provider, prompt-policy, or tool changes may require a new agent grant.

Minimum implementation baseline

Before enabling real governance roles, ANUKA should implement:

role registry;
council charter template;
delegation schema;
expiry enforcement;
capability-based authorization;
conflict and recusal record;
multi-party approval for sensitive actions;
credential and key revocation;
handover checklist;
audit logging;
emergency suspension path.

Sources

Verification record

Sources opened and checked: 2 August 2026
Status: Founding draft
Capability registry required: Yes
Legal role mapping required: Yes