Phase 4 (Interface + Pipeline Layer)
(Human-owned, fail-closed, governance-preserving)

Status

Phase: 4 (Proposed)
Depends on: Phase 3 enforcement (immutable)
Does not: Add new governance powers or automate decisions
Purpose: Make post-incident learning structurally binding

Problem Statement

Institutions reliably produce incident narratives.
They rarely produce irreversible constraint changes.

The failure mode is not ignorance, but discretion:
after an incident, nothing forces the system to become narrower.

This protocol defines the minimum closure substrate required so that:

  • incidents cannot silently resolve into documentation,
  • future actions must acknowledge unresolved failures,
  • and learning reduces the available option space.

Core Principle

An incident is not closed until it removes at least one future option,
or an accountable human explicitly preserves that option.

Closure must be visible, traceable, and block forward motion.

A. Incident Declaration Artifact

A1. Incident Record (Required)

Every incident produces a machine-readable record containing:

  • incident ID
  • date/time range
  • affected systems/interfaces
  • incident class (taxonomy)
  • status: open / constrained / closed

Artifact: incident.yaml (or equivalent)
Refusal proof: no downstream artifacts can reference a non-existent incident.

B. Mandatory Closure Candidate Generation

B1. Closure Candidate List (Required)

For every incident, the system must generate a list of closure candidates, each representing:

  • a constraint to add,
  • an option to remove,
  • or a boundary to tighten.

This list may be produced manually or with tooling assistance, but must exist.

Each candidate includes:

  • description of removed option
  • enforcement surface (config, pipeline, interface, runtime)
  • scope (temporary / permanent)
  • reversibility

Artifact: closure_candidates.yaml

Refusal proof: incident cannot move to “closed” without this list.

C. Decision Binding (Human-Owned)

C1. Mandatory Disposition for Each Candidate

For each closure candidate, one—and only one—of the following must be recorded:

  1. Accepted (constraint implemented)
  2. Deferred (time-bounded, with expiry)
  3. Declined (explicitly preserved)

Each decision must record:

  • decision-maker
  • authority basis
  • justification

Artifact: closure_decisions.yaml

Refusal proof: unresolved candidates block incident closure.

D. Forward-Motion Gate

D1. Pipeline Gate on Open Incidents

Any of the following actions must check incident state:

  • enabling new integrations
  • expanding scopes or privileges
  • removing safeguards
  • deploying new interfaces

Gate condition:

  • if relevant incidents are open or deferred but unexpired, action is blocked
  • unless an explicit override is invoked (see E)

Refusal proof: forward motion is impossible without acknowledging unresolved incidents.

E. Override Discipline (Exceptional, Visible)

E1. Incident Override

Overrides must be:

  • explicitly invoked
  • scoped to a specific action
  • time-bounded
  • attributable

Overrides do not close the incident.

Artifact: incident_override.yaml
Refusal proof: override expiry reactivates the gate automatically.

F. Constraint Lineage

F1. Constraint Annotation (Required)

Every new constraint added as a result of an incident must include:

  • incident ID
  • closure candidate ID

Artifact: metadata annotation on constraint/config

Refusal proof: constraints cannot be merged without lineage.

G. Re-Entry Prevention

G1. New Interface / Integration Check

When introducing:

  • a new tool,
  • a new API,
  • or a new execution path,

the system must check whether it reintroduces any open or historically closed incident class.

Artifact: re-entry review record
Refusal proof: enablement blocked without review.

H. Incident Closure Definition

An incident may be marked closed only when:

  • all closure candidates are accepted or explicitly declined, and
  • no deferred candidates are expired.

Closure is not:

  • publication of a report
  • passage of time
  • staff turnover

Phase 4 Completion Signal (for this protocol)

Phase 4 may claim success here when:

  • incidents produce constraint candidates by default
  • unresolved incidents block forward motion
  • preserved risk is explicitly owned
  • constraints carry incident lineage
  • new surfaces cannot reintroduce known failures silently

No new authority is created.
Only discretion is narrowed.

Notes (Non-Prescriptive)

  • This protocol does not require automation.
  • It does not assume good faith.
  • It does not prevent risk-taking.
  • It prevents forgetting.

Why This Is Phase 4 (and Not Phase 3)

  • Phase 3 enforces governance.
  • Phase 4 makes enforcement legible and unavoidable.
  • This protocol does not decide what to do.
  • It decides what cannot be ignored.