ACP CANONICAL PHASE DEFINITIONS

What follows is the canonical Phase Definition artifact for ACP, synthesized across all reviewed variants and hardened against drift, UX laundering, and premature implementation.

This is written as a governance document, not a roadmap, pitch, or product plan.

PHASE DEFINITIONS

(Phases 1–6, with docking semantics)

This document defines:

• the purpose of each phase
• entry criteria
• exit criteria
• failure states
• explicit prohibitions

Phases are gates, not milestones.
Advancing a phase without meeting exit criteria constitutes ACP failure, not partial success.

PHASE 1 — EPISTEMIC & GOVERNANCE GROUNDING (COMPLETE)

Purpose

To establish ACP as a governance protocol, not a behavioral model, product, or assistant.

This phase exists to prevent:

• automation bias
• narrative coherence masquerading as authority
• premature claims of governance

What happens here

• Define ACP scope, claims, and non-claims
• Establish epistemic posture: all outputs are claims
• Identify core failure modes:
  • unauthorized epistemic authority
  • interface-laundered truth
  • compression-induced harm
• Explicitly reject simulation of governance

Entry criteria

• None (this is the foundation)

Exit criteria

• Clear statement of:
  • what ACP is
  • what ACP is not
  • what constitutes failure
• Explicit rejection of:
  • “partial governance”
  • “MVP governance”
  • “alignment without authority”

Failure states

• Treating coherence as correctness
• Treating explanation as governance
• Allowing ACP language to justify decisions

Prohibited in Phase 1

• UX design
• feature work
• enforcement claims
• external representation as “governed”

PHASE 2 — AUDIT & DIAGNOSTIC ALIGNMENT (COMPLETE)

Purpose

To make existing authority, power, and risk visible without pretending to control it.

This phase is observational, not operational.

What happens here

• Repository audits (permissions, secrets, CI, branches)
• Authority mapping (who can change what, where)
• Identification of enforcement gaps
• Classification of diagnostic-only deployment

Entry criteria

• Phase 1 epistemic grounding complete

Exit criteria

• Known:
  • authority surfaces
  • enforcement surfaces
  • blind spots
• Explicit classification of diagnostic mode as ACP FAILURE — DIAGNOSTIC MODE
• No claims of implementation or control

Failure states

• Calling audits “governance”
• Treating visibility as authority
• Using audit artifacts to justify decisions

Prohibited in Phase 2

• Enforcement
• UX abstraction of findings
• Claims of readiness
• “We’ll fix this later” narratives

PHASE 2.6 — SEQUENCING & PRE-DOCKING ENFORCEMENT PREP (COMPLETE)

(Transitional, but mandatory)

Purpose

To ensure that enforcement is possible before attempting it.

This phase exists because skipping sequencing is a dominant institutional failure mode.

What happens here

• Ordering work so authority can actually be enforced
• Identifying prerequisites for docking
• Refusing work that assumes authority not yet present
• Freezing premature UX/product exploration

Entry criteria

• Phase 2 audit complete
• Known enforcement gaps

Exit criteria

• Explicit list of:
  • prerequisites for enforcement
  • blockers to docking
• GitHub issues rewritten with:
  • acceptance criteria
  • authority assumptions made explicit
• No unresolved “magic happens later” steps

Failure states

• Beginning enforcement without prerequisites
• Allowing UX or feature work to outrun authority
• Treating sequencing as project management trivia

Prohibited in Phase 2.6

• Docking claims
• Interface design
• Payload programs
• Immersive systems

PHASE 3 — HARD DOCKING / GOVERNANCE ENFORCEMENT (IN PROCESS)

Purpose

To make ACP operational, not symbolic.

This is the phase where governance becomes real, interruptible, and costly.

Definition: HARD DOCKING

ACP is hard-docked only if all of the following are true:

• A named human authority exists
• That authority can interrupt execution
• Refusal or revocation produces a material change in system behavior
• Enforcement does not require escalation to a separate body
• Authority is auditable

If any condition fails, ACP is not operational.

What happens here

• Enforcement of authority at real control surfaces (e.g., GitHub)
• Refusal becomes a first-class outcome
• Interruption is tested, not assumed
• Claims are ratified or rejected by named authority

Entry criteria

• Phase 2.6 sequencing complete
• Enforcement prerequisites satisfied

Exit criteria

• Demonstrated interruption
• Demonstrated refusal with real effects
• No reliance on trust, intent, or future fixes

Failure states

• Diagnostic mode masquerading as implementation
• Soft enforcement presented as governance
• Authority implied but not executable

Prohibited in Phase 3

• UX smoothing
• Delegation of authority to AI
• External claims of safety or alignment
• Payload programs

PHASE 4 — UX / INTERFACE AS GOVERNANCE INFRASTRUCTURE

Purpose

To translate real authority into human-facing control surfaces
without laundering, smoothing, or obscuring it.

This is the most failure-prone phase.

Core premise

Interfaces are not presentation layers.
They are control surfaces.

What happens here

• Design interfaces that:
  • make authority visible
  • make refusal legible
  • make uncertainty explicit
  • preserve friction
• Prevent interface-induced epistemic authority
• Encode interruption and refusal into interaction flows

Entry criteria

• Phase 3 hard docking complete
• Enforcement proven
• Phase 4 acceptance criteria defined before design

Exit criteria

• No UI path can imply:
  • certainty without authority
  • completion without ratification
  • permission without a named human
• Refusal and interruption are as visible as success

Failure states

• Smooth UX that hides power
• Delight that implies legitimacy
• “Helpful” interfaces that decide by implication

Prohibited in Phase 4

• Persuasive design
• Progress metaphors
• Implicit authority
• Personalization of governance signals

PHASE 5 — PAYLOADS / PROGRAMS (IMMERSIVE SYSTEMS, ETC.)

Purpose

To apply ACP-governed systems to substantive domains
(e.g. immersive simulations, policy exercises, institutional workflows).

What happens here

• Immersive systems
• Scenario engines
• Domain-specific applications

Entry criteria

• Phase 4 complete
• Governance preserved through interface
• No authority regression

Exit criteria

• Payloads operate within ACP constraints
• No domain-specific erosion of governance

Failure states

• Payload demands overriding governance
• UX exceptions for “important use cases”

Prohibited in Phase 5

• Domain-specific authority shortcuts
• Special rules for high-stakes scenarios

PHASE 6 — FEDERATION, SCALING, & EXTERNAL GOVERNANCE

Purpose

To extend ACP beyond a single system or organization without loss of control.

What happens here

• Agora governance
• Multi-AI norming
• Enterprise deployment
• Regulatory interfacing

Entry criteria

• Proven stability through Phase 5
• No unresolved authority ambiguities

Exit criteria

• Federated governance with auditable authority
• External interfaces that preserve ACP constraints

Failure states

• Scale used to justify loosened governance
• External pressure overriding refusal

Prohibited in Phase 6

• “Trust us” scaling
• Silent delegation of authority

SUMMARY: NON-NEGOTIABLE PRINCIPLES

• Diagnostic ≠ governance
• Capability ≠ authority
• Refusal is not failure
• UX is governance
• Enforcement precedes interface
• Non-action is preferable to false action