Gate Checkpoint Protocol

ELI5

A gate is a stop-light installed inside a chain. The light is green only after a named human-or-agent says so. Yellow doesn’t exist: the light is one of approved, rejected, timed-out, or escalated. None of those can flip backwards to anything else.

Technical Deep Dive

Source: config/gate-rules.yaml, packages/cli/src/commands/gate.ts, packages/graph/src/protect.ts.

Four Terminal States

Forbidden Transitions

• TIMEOUT → APPROVED — explicitly forbidden; expired gates require a fresh request.
• REJECTED → any — terminal.
• APPROVED → any — terminal.

Lifecycle

stateDiagram-v2
    [*] --> Pending : gate step reached
    Pending --> APPROVED : authority approves
    Pending --> REJECTED : authority rejects (with reason)
    Pending --> TIMEOUT : 24h elapsed
    Pending --> ESCALATED : escalation policy fires
    APPROVED --> [*]
    REJECTED --> [*]
    TIMEOUT --> [*]
    ESCALATED --> Pending : re-resolved by escalation owner

Resolution Flow

sequenceDiagram
    autonumber
    participant Chain
    participant Engine as ChainExecutor
    participant Auth as Gate Authority
    participant Trace as Trace store
    Chain->>Engine: reach step where gate=true
    Engine->>Auth: gate packet (chain_uri, step_id, inputs_hash, deadline=now+24h)
    alt Authority approves before deadline
        Auth-->>Engine: APPROVED + packet_hash
        Engine->>Trace: gate_resolution {state: APPROVED, resolved_by, resolved_at, wait_duration_ms}
        Engine->>Chain: resume
    else Authority rejects
        Auth-->>Engine: REJECTED + reason
        Engine->>Trace: gate_resolution {state: REJECTED, reason}
        Engine->>Chain: terminate
    else Deadline elapses
        Engine->>Trace: gate_resolution {state: TIMEOUT}
        Engine->>Chain: halt (no auto-approve)
    end

Authorities & Scope

Veritas Gate (SPEC-05 link)

A specialised gate triggered by quality-score regression > 0.05 between versions. Lives in lib/veritas.ts (VeritasGate class), supports live 3-run and dry-run modes via stratt gate veritas --dry-run.

FM-05: Gate Removal

Removing a gate step from a chain composition is a breaking change requiring a major version bump. Detected by protect.ts comparing prior published version’s composition against the new one.

Key Terms

• Hard synchronisation → Chain halts completely; no parallel branch can advance until resolution.
• Packet hash → Blake3 hash of the gate packet, recorded with the resolution for non-repudiation.
• Veritas → Quality-regression-triggered gate, distinct from human-approval gates.

Q&A

Q: What are the four terminal gate states? A: APPROVED, REJECTED, TIMEOUT, ESCALATED. None can transition to APPROVED after the fact (the TIMEOUT→APPROVED edge is explicitly forbidden in gate-rules.yaml).

Q: Why doesn’t TIMEOUT auto-approve? A: Auto-approve on timeout would let an absentee approver gate decisions silently. The chain halts to force an explicit re-request.

Q: Can a chain have zero gates? A: Schema permits it, but FM-04 still requires the council’s protected agent to be on a step. A chain with no gates and no protected agent fails CI.

Examples

A docs chain reaches step-06 with gate: true and agent: EDITOR-04. The packet is dispatched. EDITOR-04 reviews for 8 minutes, approves. Trace records gate_resolution.state=APPROVED, wait_duration_ms=480000, resolved_by=EDITOR-04. Chain resumes at step-07.