Proposals, Consensus, and Decision Lifecycle

Draft 0.1 — 2 August 2026
This process governs ANUKA network and protocol decisions. Legal entities may require additional resolutions, notices, approvals, or filings.

Objective

ANUKA needs a decision process that is open enough to earn trust and fast enough to operate.

The process must not reduce governance to:

popularity contests;
founder intuition without record;
token-weighted voting;
endless discussion without ownership;
hidden executive decisions presented as community consensus;
automated voting by AI agents;
a merge button with no implementation accountability.

The governing rule is:

Seek reasoned consensus, record unresolved objections, use voting only when it clarifies authority, and measure what happens after the decision.

Proposal classes

Discussion note

A nonbinding document used to expose a problem, frame alternatives, or collect evidence.

It does not authorize implementation or spending.

Experimental proposal

A bounded, reversible test with defined guardrails, owner, duration, and rollback.

Product proposal

A decision within one resident product’s charter.

Protocol proposal

A change to shared schemas, APIs, registries, conformance, or network behavior.

Budget proposal

A request to allocate shared funds or commit shared resources.

Appointment proposal

A request to grant a role, council seat, stewardship mandate, or delegated capability.

Policy proposal

A change to shared operational, privacy, security, marketplace, or governance policy.

Constitutional proposal

A change to protected commitments or constitutional mechanisms.

Emergency action record

A retrospective record of a time-sensitive action taken under a valid emergency charter.

An emergency action is not a shortcut for ordinary policy.

Proposal lifecycle

Stage 0 — Signal

A signal identifies a need, risk, opportunity, conflict, or observed failure.

Minimum content:

what happened or may happen;
who is affected;
available evidence;
urgency;
whether immediate containment is required.

A signal is not yet a preferred solution.

Stage 1 — Draft

The proposer creates a structured proposal.

Minimum fields:

id: GOV-PROP-2026-0042
title: Introduce contributor evidence-strength registry
proposal_type: protocol
decision_class: G2
status: draft
proposer: participant:anuka:123
sponsor: council:evidence
problem: Contributors cannot compare evidence quality consistently.
scope:
  - evidence-registry
out_of_scope:
  - employment-screening
implementation_owner: team:evidence-core
review_period_days: 21

The draft must identify:

the problem;
proposed change;
alternatives, including no action;
affected parties;
legal, security, privacy, accessibility, economic, and compatibility impacts where relevant;
implementation owner;
budget;
measurement plan;
rollback or sunset conditions;
decision class;
required approvers.

Stage 2 — Readiness check

A facilitator checks whether the proposal is ready for formal review.

Readiness is procedural, not substantive.

A proposal may be returned when it lacks:

a clear decision request;
an accountable owner;
impact analysis;
required source material;
budget or funding path;
implementation feasibility;
conflict disclosure;
required legal or security review.

The facilitator must not reject a proposal merely because they disagree with it.

Stage 3 — Public review

The proposal receives a declared review period.

Default minimums:

Decision class	Minimum review
G0 local reversible	team-defined
G1 product	7 days
G2 shared protocol	21 days
G3 shared institutional	30 days
G4 constitutional	30–90 days under constitutional tier

Review periods may be shortened for a documented emergency or extended for material unresolved issues.

Review should include affected parties, not merely governance regulars.

Stage 4 — Objection resolution

Review comments are categorized as:

question;
editorial suggestion;
implementation concern;
security or privacy concern;
legal or economic concern;
compatibility concern;
formal objection;
alternative proposal;
support;
abstention.

A formal objection must identify:

the decision or text challenged;
the material harm or defect;
supporting reasoning or evidence;
a change, alternative, or condition that could address it where possible.

Every formal objection receives a reasoned response.

The response may:

accept the objection;
partially accept it;
modify the proposal;
add a safeguard;
create a follow-up requirement;
explain why the objection is not adopted;
escalate the issue.

Consensus does not require accommodating every preference. It requires demonstrating that material issues were understood and addressed.

Stage 5 — Decision

The responsible body determines whether the proposal is:

accepted;
accepted with conditions;
approved as an experiment;
returned for revision;
split into separate proposals;
rejected;
deferred;
superseded;
withdrawn.

The decision record must explain:

who had authority;
who participated;
conflicts and recusals;
consensus assessment or vote;
unresolved objections;
rationale;
implementation conditions;
review or sunset date.

Stage 6 — Implementation

Approval does not equal implementation.

Implementation requires:

named owner;
delivery plan;
repository or service changes;
migrations;
communications;
legal or operational execution;
tests and status checks;
release record;
rollback plan.

A proposal that is never implemented must not remain labeled as completed.

Stage 7 — Measurement

The decision is evaluated against its declared objectives.

Possible outcomes:

achieved;
partially achieved;
neutral;
harmful;
inconclusive;
not implemented;
superseded before measurement.

The measurement record should include unintended effects and affected-party feedback.

Stage 8 — Review, renewal, amendment, or sunset

A decision may be:

continued;
renewed;
amended;
deprecated;
revoked;
superseded;
allowed to expire.

Temporary rules and delegations must not become permanent by neglect.

Consensus model

ANUKA prefers rough consensus for shared technical and policy work.

Rough consensus means:

material issues have been surfaced;
objections have been understood;
alternatives were considered;
the responsible body believes the proposal is the strongest available path;
the decision can move forward despite some remaining disagreement.

Rough consensus is not:

unanimity;
silence from uninformed participants;
the loudest voices winning;
a count of emoji reactions;
a vote held before objections are discussed;
a chair declaring victory without a record.

RFC 7282 emphasizes that rough consensus is about addressing issues, not merely counting people.

Consensus call

The facilitator or chair should publish a consensus call that states:

the current proposal version;
issues believed resolved;
remaining objections;
the proposed conclusion;
a final response deadline;
who will make the decision if consensus remains unclear.

Silence may support lazy consensus only when:

affected participants received reasonable notice;
the decision is low risk and reversible;
the authority to proceed is already delegated;
no protected right is reduced;
the process explicitly allows lazy consensus.

Silence must not be interpreted as consent for privacy, payment, employment, constitutional, or irreversible decisions.

Voting fallback

Voting is used when:

governing documents require it;
appointments or budgets need a clear authorization record;
rough consensus cannot be established;
a constitutional threshold applies;
a legal entity requires a formal vote.

A vote must declare:

eligible electorate;
voter identity requirements;
quorum;
threshold;
opening and closing time;
conflicts and recusal rules;
whether abstentions affect quorum;
whether votes are public or confidential;
how ties are handled;
appeal route.

Default recommendations:

Decision type	Suggested threshold
ordinary operational appointment	simple majority of votes cast with quorum
shared budget or policy	majority or two-thirds depending risk
major protocol breaking change	two-thirds
protected constitutional change	three-quarters plus constitutional safeguards

These defaults do not override legal entity bylaws or contracts.

Quorum and low participation

Quorum prevents a tiny active group from quietly making high-impact decisions.

But quorum alone does not create legitimacy.

The decision record should disclose:

number eligible;
number notified;
number participating;
participation by affected stakeholder group;
abstentions;
conflicts and recusals.

High-impact decisions with low participation may require:

an extended review;
direct outreach;
a second confirmation vote;
an independent review;
a temporary rather than permanent approval.

Formal objections

Any affected participant may register a formal objection to a G2–G4 proposal.

The objection record must remain linked to the final decision even when the proposal passes.

An objection may be closed as:

resolved by change;
withdrawn;
partially resolved;
not adopted with rationale;
escalated;
superseded.

Closing an objection does not erase it.

Retaliation for a good-faith objection is prohibited.

Appeals

Appeals address process failure, authority error, material overlooked evidence, conflict of interest, or unreasonable application of rules.

An appeal is not simply another vote because someone dislikes the outcome.

Minimum appeal fields:

decision challenged;
appellant;
standing or affected interest;
claimed defect;
evidence;
requested remedy;
urgency;
conflict disclosures.

Possible remedies:

uphold;
clarify;
remand for renewed review;
suspend implementation;
narrow scope;
correct the record;
reverse;
refer to a legal entity or specialist body.

Appeal bodies should not include the same conflicted decision-makers when avoidable.

GitHub-native implementation

Foundation and protocol proposals should be managed as docs-as-code.

Recommended implementation:

GitHub Issue or Discussion for early signal;
proposal Markdown file or pull request;
structured frontmatter;
CODEOWNERS for required domain review;
branch rulesets;
required Starlight build;
source and link checks;
public comments;
decision record merged with the proposal;
tagged release for ratified versions.

Required checks may include:

documentation build;
schema validation;
backward compatibility;
security review;
legal review marker;
accessibility review;
source-link validation.

Repository controls implement part of the process; they do not replace legitimate governance authority.

AI participation

AI agents may:

summarize discussion;
identify duplicate proposals;
map affected documents;
check required fields;
compare versions;
identify unresolved comments;
generate impact questions;
draft decision records.

AI agents must not:

fabricate consensus;
cast independent binding votes;
suppress minority objections;
determine conflicts of interest without human review;
make final constitutional or legal decisions;
treat sentiment analysis as legitimacy.

Every AI-produced governance artifact must identify the accountable principal and remain reviewable.

Anti-manipulation controls

The process should detect:

duplicate or coordinated identities;
paid or undisclosed lobbying;
vote buying;
last-minute electorate changes;
hidden conflicts;
mass AI-generated comments without accountable principals;
strategic flooding to exhaust reviewers;
retroactive proposal edits after voting begins;
selective notification;
misleading summaries of objections.

Mitigation should be proportionate and must preserve legitimate participation.

Decision record template

# GOV-2026-0042 — Adopt Evidence Registry v0.2

- Decision class: G2
- Status: Ratified
- Responsible body: Evidence Protocol Council
- Review period: 5–26 August 2026
- Decision date: 30 August 2026
- Implementation owner: Identity Core Team
- Review date: 28 February 2027

## Decision

Adopt schema v0.2 with a six-month compatibility period.

## Rationale

...

## Alternatives considered

...

## Formal objections

...

## Conflicts and recusals

...

## Implementation conditions

...

## Measurement and sunset

...

Process health metrics

Track:

proposal throughput;
median review duration;
percentage with complete impact analysis;
percentage with implementation owners;
unresolved objection rate;
time to respond to formal objections;
implementation completion;
appeal frequency and outcomes;
decision reversals;
participation concentration;
expired proposals and delegations;
proposals created by newcomers versus insiders.

Metrics should diagnose process problems, not rank people.

Sources

Verification record

Sources opened and checked: 2 August 2026
Process status: Founding draft
Required before ratification: electorate, quorum, and council charters