Skip to content

epic(governance): authority ladder — observe → suggest → advisory → enforce #3839

@williamzujkowski

Description

@williamzujkowski

Narrative

Formalize the four-tier authority model as a first-class concept: observe (telemetry only) → suggest (files issues) → advisory (votes, non-blocking) → enforce (blocking or acting). Every automated behavior declares its tier in its manifest. Promotion requires documented evidence thresholds + human ratification via consensus_vote — never a default flip. Demotion can be automatic. All tier transitions are audit events.

Ratification vote (dogfooded, 2026-06-09)

consensus_vote strategy=higher_order on the ladder proposal: APPROVED 7/7 (100%). Recorded conditions that are now acceptance criteria across the children:

  • Contrarian: the tier field must have a MACHINE consumer (router/CI enforcement), or it is "documentation dressed as architecture"; the promotion-ratification invariant must be machine-enforced (a gate that fails when a tier-transition audit event lacks a linked ratification vote); the per-loop migration must be UNBUNDLED into discrete issues.
  • DevEx/Architect: ADR must pin the evidence-threshold schema concretely (what counts as promotion evidence); per-loop migration = independently landable PRs.
  • Scope Steward: this epic is documentation+enforcement of EXISTING tiers — no behavior changes smuggled in under "migration".

Grounding (Phase 0 recon, 2026-06-09)

The codebase already practices the ladder implicitly:

Loop Implicit tier today Evidence
suggest_research_tasks suggest (read-only by contract) suggest-research-tasks-tool.ts:1-18
improvement_review suggest (fileIssues=false default, rate-cap 5) improvement-review.ts:62-68
pr_review advisory (wraps consensus, never blocks) tool-prerequisites middleware
auto-remediation suggest/audit (zero writes default; enforce staged) auto-remediate-command.ts:25-35, #3769/#3653
tune loop enforce, bounded (floor 0.5, 0.2-step cap, 30-min decay) tune-stage.ts, tune-adjustment-store.ts:31-35

Anti-degenerate-loop guard verified: LinUCB UCB = reward + α×uncertainty (α=1.0) gives low-pull arms high uncertainty → guaranteed exploration-floor traffic (linucb-bandit.ts:130-136). Plus: capability removal is never autonomous (Epic F routes removals through this epic's ratification path).

Children

Absorbed promotion cases (already-open issues now governed by this ladder)

Dependency notes

Depends on Epic C (#3833) — the tier field lives in the strategy manifest (#3834). Epics E and F consume the ladder (pr_review promotion criterion; never-autonomous tool removal).

Definition of done

  • ADR ratified + merged; tier field machine-enforced (router + CI)
  • Tier transitions are audit events; promotion events REQUIRE a linked ratification vote (gate)
  • Every loop in the table above carries an explicit, documented tier
  • Exploration-floor guard documented where the ladder doc points to it

Metadata

Metadata

Assignees

No one assigned

    Labels

    authority-ladderAuthority tiers: observe→suggest→advisory→enforce (Epic D)epicParent tracking issuegovernanceGovernance and policy enforcementp1Priority 1 - High impact, fits current architectureroadmap:control-planeControl Plane roadmap (M1-M4)

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions