Governance (π)

π is the decision process by which the rules themselves change. Everything below π — α’s middleware, β’s FSM, κ’s rule bodies, θ’s quorum, the constitutional axioms — is the output of a π process. π is the one layer that can legitimately alter a rule that earlier rounds locked in.

Phase 0 reality: π is specified but not activated. The single T0 human operator is the effective governance authority in Phase 0. Votes, proposals, and time-locks are scaffolded in the spec so later phases can turn them on.

Authoritative spec: ../../../spec/s19-governance.md.

The proposal lifecycle

A π proposal passes through six phases:

DRAFT → SUBMITTED → DISCUSSION → STAGED VOTING → LOCK → ENACTED
                                        ↓
                                     REJECTED (terminal)

Each phase has an explicit time bound and an explicit outcome. A proposal that stalls between phases beyond its time bound becomes REJECTED by default — silence is a no-vote.

Phase	Duration (default)	Who acts
DRAFT	unbounded	proposer
SUBMITTED	7 days	proposer finalizes; others read
DISCUSSION	14 days	constituents comment; proposer may amend
STAGED VOTING	3 × 30 days = 90 days	constituents vote in three windows
LOCK	30–90 days	no-one; change-freeze before enactment
ENACTED	terminal	κ rule version bumps; θ arbiters pick up the new hash

Proposal FSM (explicit)

  DRAFT ─── submit ──► SUBMITTED ─── 14d ──► DISCUSSION ─── close ──► STAGED_VOTING
                                                                          │
       ┌───────── reject at any stage ◄─── fail threshold ────────────────┤
       │                                                                  │
       ▼                                                 pass all 3 stages│
   REJECTED (terminal)                                                    ▼
                                                                       LOCK (30–90d)
                                                                          │
                                                                          ▼
                                                                      ENACTED

A proposal can transition to REJECTED from any voting stage that fails threshold. Post-ENACTED, a rollback path exists: if post-enact monitoring flags an axiom drift (see integrity.md), π can open a fresh proposal to revert; during rollback, LOCK on the enacted parameter applies normally.

Quadratic voting

π uses quadratic voting: the cost of N votes on a single proposal is N² credits. The effective power is sqrt(credits_spent). This dampens whale influence — a constituent with 100 credits can cast 10 full-weight votes, not 100.

Credits are earned via participation in governed processes (running an arbiter, authoring rule upgrades, resolving merges) and decay on an epoch schedule. The decay rate is itself a κ rule, which means changing it is a π proposal.

Quadratic voting cost table

Votes `N`	Cost `N²`	Power `√N`
1	1	1
4	2	2
9	3	3
16	4	4
25	5	5
100	10	10

Cost is capped at the constituent’s available credit balance — an agent with 25 credits cannot spend 30 on a single proposal even if it would buy more power elsewhere.

Supermajority thresholds

Proposal class	Threshold	Stages	Duration
Constitutional-adjacent (AX-*)	>80% yes of cast weight	3 (staged time-locked)	~134d
Structural / rule-engine built-in	>75%	3	~134d
Non-constitutional parameter (GOV-, PR-)	>66%	1	~44d + LOCK
Cosmetic / documentation	>50%	1	~44d

The PR-* prefix denotes “parameter” proposals; GOV-* denotes governance-process tweaks; AX-* denotes axiom-adjacent. Every proposal declares its class at DRAFT; misclassification is grounds for rejection at SUBMITTED.

Three voting modes

A proposal’s voting stage is one of three shapes, picked by the proposal’s class:

Simple — a single window, simple majority of cast votes. Used for low-impact changes (e.g. adjusting a cosmetic parameter).
Supermajority — a single window, quorum = floor(2n/3) + 1 matching θ’s quorum bound. Used for constitutional axiom amendments.
Staged time-locked — three windows at 30-day intervals; each window must pass independently; any window’s failure abandons the proposal. Used for irreversible changes (e.g. fork reason additions, rule-engine DSL extensions).

The default is staged time-locked for anything that touches a constitutional axiom or changes κ’s built-in function set.

The seven axioms

π operates under seven constitutional axioms, AX-01 through AX-07, enumerated in ../constitution.md and authoritatively in s01. Axioms cannot be changed through the simple or supermajority paths; they require the full staged process plus an additional LOCK extension.

Axiom	One-line statement
AX-01	History is append-only; no event is ever retroactively deleted.
AX-02	Reputation is derived from events, never assigned directly.
AX-03	No absolute authority — every power is subject to a challenge path.
AX-04	Consequence windows: every action’s effect is bounded in time and space.
AX-05	Finality is subjective — each consumer picks its required level (SOFT/QUORUM/HARD/ABSOLUTE).
AX-06	Right to exit with stake penalty ≤10%.
AX-07	Technical sovereignty — no participant can be forced onto a specific runtime.

A proposal that violates an axiom is rejected at DRAFT validation, before any voting begins.

Entropy injection

Pure majoritarian voting tends to stagnate around the median. π counters this by injecting a 10% random element into the vote tally when the margin between yes and no is less than 5% of cast weight. The randomness source is a VRF over the previous round’s Merkle root (see ADR-002), so the injection is deterministic-given-history but unpredictable-in-advance.

This mechanism applies only to the simple mode. Supermajority and staged time-locked modes have their own margin requirements and do not inject entropy.

Entropy injection algorithm

When a proposal’s parameter delta exceeds 5% of its current value, the VRF selects a subset of voters to receive equal-weight (1 vote each) rather than credit-weighted votes:

seed            = H(proposal_id || stage || chain_entropy)
selected_voters = VRF(seed, voter_set, sample_fraction=0.10)
for voter in selected_voters:
    voter.effective_weight_this_stage = 1    # overrides quadratic-weighted

chain_entropy is the previous round’s finalized Merkle root; by θ’s rule this is already public but unpredictable at proposal time. sample_fraction=0.10 means 10% of the constituent set has equal weight; the remaining 90% vote normally under quadratic rules. The sample is deterministic given seed, so any observer can re-verify the selection post-stage.

Effect: large deltas cannot pass on pure whale weight; they must survive a small-voter jury effect.

Change-freeze

Between a successful vote and enactment, no related rule may be proposed or enacted. This is the LOCK phase, and it prevents a “cascade through” attack where a small rule change is exploited immediately to pass a second rule change before the first has been properly observed.

LOCK duration defaults to 30 days; a proposal may request up to 90 days for structurally significant changes.

During LOCK:

Related proposals are blocked — same parameter family + same domain (e.g. while “reputation decay rate” is locked, no other reputation-decay proposal can enter STAGED_VOTING).
Unrelated proposals pass normally — a LOCK on min_stake does not gate a proposal about logging verbosity.
Relatedness is declared by the proposer and audited at SUBMITTED; disputed relatedness is resolved by a π process-metadata proposal.

Proposal timeline example

Proposal: reduce reputation-decay from 5.0% to 4.5% per epoch (class PR-*, staged because the delta crosses the 5% parameter-family sensitivity threshold).

Day	Phase	Event
0	SUBMITTED	Proposer finalizes; notice broadcast
14	DISCUSSION closes	Comment window ends; amendments locked in
44	Stage 1 vote	>66% threshold required
74	Stage 2 vote	>66% threshold required again; entropy injection if delta > 5%
104	Stage 3 vote	Final >66% check
134	LOCK begins	30-day quiet window
164	ENACTED	κ bumps `rule_version_hash`; θ arbiters pick up new rv; post-enact monitoring armed

If post-enact monitoring (see integrity.md) flags axiom drift in the next 6 months, a rollback proposal can enter the queue — it does not short-circuit, it runs the normal 164-day path.

Exhaustion protection

Three safeguards prevent governance from being weaponised via rapid-fire parameter churn:

±10% cumulative cap per 6 months per parameter. A parameter can move at most ±10% from its value at the start of a 6-month window. Proposals that would breach this cap are rejected at SUBMITTED.
2-epoch stability period. After any change in a domain, no further change in the same domain can enter STAGED_VOTING for 2 epochs (≈60 days in Phase 2+).
Test-corpus parity. Both v_old and v_new must produce identical effects on the standing test corpus before activation (see ../laws/rule-engine.md §versioning). Deviation outside the declared scope = auto-reject.

Credit-reputation coupling

Voting credits are derived from λ reputation per the canonical formula credits_available = f(reputation_by_domain, epoch_decay). The full derivation is specified in s19-governance; what matters here is:

Credits are earned, not assigned — every credit traces back to a reputation event, which traces back to an action event, which traces back to a rule-engine evaluation. The chain is auditable.
Credits decay per epoch at a rate that is itself a κ rule (and therefore a π proposal to change).
Credits are fungible within a domain but not across domains — a BUILDER-heavy agent cannot spend arbitration-domain reputation on a GOVERNANCE-class proposal.

What π is not

Not a permission system. Whether a specific agent can call a specific tool at a specific moment is κ’s question, not π’s.
Not an elected body. There is no “governance council” separate from the constituent set. Everyone who holds credits votes on every proposal.
Not emergency response. Emergencies use the ι EMERGENCY fork reason, not a π proposal. π seals the outcome of an emergency fork retroactively.

Phase 0 posture

The Phase 0 tool surface exposes no governance_* tool. The 19 Phase 0 tools (ADR-004) are all operational, not governance.
Rule changes in Phase 0 happen by the human operator (T0) editing the repo and merging the PR — T0 is the effective governance authority, serving as single-voter surrogate for the full π flow.
π activation target: R151+ (Phase 6) per ../../../5-time/roadmap.md; first multi-arbiter run comes no earlier than Phase 1.5 per ADR-005.