Course / Lesson 17  ·  PT-BR
Lesson 17 · Engine & method · 4 of 8

The gate pipeline: five checkpoints around a run

A run does not just "execute and finish." It passes through a sequence of gates — Scope, Council, Proof, Validator, Publish — each of which can stop it. Some are pre-flight, some close the run, one is optional. Together they are the discipline that turns "the agent produced something" into "the agent produced something verified." This is also exactly where the learning loop's own ReviewGate (lessons 4 & 8) fits. Source: @alembic/coda + @alembic/mission + @alembic/forge.

The pipeline, in order

① Scope materialize run-dir ② Council optional GO/NO_GO pre-flight ③ Proof unit.proof[] · fail-closed ④ Validator independent council + verifier panel ⑤ Publish parks when closed (human gate) ↑ the learning loop's ReviewGate (scoreThresholdGate 0.7) is a gate of the same family it gates what a finished run is allowed to sediment into memory/skills (lessons 4 & 8) every gate fails closed: the default is "do not proceed / park for a human", never "assume OK"

① Scope Gate — materialize the run directory

The on-ramp. loadScope(input) (forge/src/scope.ts) copies GOAL.md, the plan module, and the validation contract into a content-addressed run directory and seeds its layout (council/, units/, workflows/, park/, course/, reports/ + LOOP-LOG.md + review.md). Its key safety rule: a resume cannot switch scope — when resuming, the goal/plan/contract are validated against the saved meta.json, and any mismatch returns err('resume mismatch: …'). You can't accidentally rescope a run you're resuming.

② Council Gate — optional pre-flight GO/NO_GO

runCouncilGate (mission/src/council-gate.ts) runs a board before the work begins and returns an aggregated CouncilDecision. NO_GO means the mission must not proceed. It's optional (gated by --council / plan config) — a pre-flight veto, not a post-hoc review. The harness core enforces the same idea internally: in fanout, council runs first and a NO_GO short-circuits before any worker is dispatched — "a board that does not green-light must not spawn autonomous work."

③ Proof Gate — the deterministic spine

This is the gate that makes "it works" mean something. Each unit.proof[] string in a mission compiles into a bash -c command task that depends on the unit task. The Proof Gate reads task states and fails the run closed on any non-zero exit:

// packages/coda/src/proof.ts:26-99 (condensed) — fails closed, reads the journal
// every task with metadata.kind === 'proof' MUST have exited 0 (status === 'done')
for (const proof of proofTasks) {
  if (state(proof).status !== 'done') failures.push(summarize(proof)); // any failure ⇒ err
}
if (failures.length) return err(perUnitSummary(failures));    // caller fails the run closed

A subtle, important detail: it reads task states from the event journal, not the checkpoint — so it survives checkpoint overwrites across multiple runSwarm calls that share a store. Proof results are persisted to units/<unitId>/proof-results.jsonl. This is the engine-level embodiment of the Proof Gate discipline you've seen throughout the course: no claim counts without a real command exiting 0.

④ Validator Gate — who builds must not validate

runValidatorGate (coda/src/validator.ts) runs an independent council of validators plus a verifier panel over each milestone's evidence. Only approved === true (the panel is verified and not parked) permits emission; a NO_GO or a rejected panel parks for human review. An optional fusion seam handles T4/high-stakes units. The separation is the point — the agent that produced the work is never the one that signs off on it.

⑤ Publish Gate — parks when closed

Any outward-facing publish must pass this gate (coda/src/publish.ts). Closed → the artifact is parked in t4-parked.jsonl and awaits human approval; open → it is published via the supplied gist/pages publishers. This aligns with the human-gate-at-ship principle (ADR-0005): the irreversible, outward step is the one a human signs.

Where the learning loop plugs in

The fusion package's learning pass (lessons 4 & 8) is gated by a ReviewGate with scoreThresholdGate(0.7) — a member of this same gate family. The five gates above govern what a run is allowed to ship; the ReviewGate governs what a finished run is allowed to sediment into memory and skills. Same philosophy, applied to the engine's own self-improvement: learn only from validated wins. This is why the matrix calls the learning loop a CLONE that "composes with the validator gate" rather than replacing it.

1. A unit's proof[] command exits non-zero. What does the Proof Gate do?
Correct: b. Every metadata.kind === 'proof' task must be done (exit 0). Any failure collects into a summary and the gate returns err, failing the run closed. Proofs are the deterministic spine — they don't degrade to warnings.
2. Why does the Proof Gate read task states from the event journal rather than the checkpoint?
Correct: c. A shared store can have its checkpoint.json overwritten by a later runSwarm call, but the append-only events.jsonl retains every task-state event. Reading the journal makes the gate robust across multi-call runs.
3. The Validator Gate exists in addition to the Proof Gate. What does it add that proofs don't?
Correct: d. Proofs are deterministic command checks; the Validator Gate adds an independent qualitative review (who builds must not validate), parking to a human on NO_GO or a rejected panel. The two are complementary, not duplicative.

Common confusions

"The Council Gate and the Validator Gate are the same." No — the Council Gate is an optional pre-flight GO/NO_GO before work starts; the Validator Gate is a post-work independent review of the evidence produced. One decides whether to begin; the other decides whether what was produced may ship.
"Publish just writes the artifact out." Only if the gate is open. Closed, it parks the artifact in t4-parked.jsonl for a human — the outward, irreversible action is deliberately the one that requires a person (ADR-0005).
← Lesson 16Lesson 18 →