campaign

Campaign Protocol v1.0: Architect-Tier Orchestration

Absorb → Survey → Plan → Orchestrate → Dispatch ⇄ Reconcile → Close

This workflow defines the /campaign execution loop for architect-class (expensive, long-horizon) walkers coordinating heterogeneous model tiers across a multi-workstream goal. The council's primary output genre is not code — it is boundary conditions for cheaper walks, and judgment on the work that returns.

---

Philosophy

The Hourglass

Expensive tokens belong at the waist, not the edges:

  wide:   cheap tier + human  — boundary refinement (/boundary → IBC*)
  narrow: one council pass    — exhaustive survey, planning, orchestration
  wide:   cheap tier          — disciplined worker execution (/refine, /core)
          deterministic evaluators between every layer

The council ingests an approved $\text{IBC}^*$ (manufactured by the boundary loop), saturates its shared context through an exhaustive multi-agent survey, and emits a graph of saturated worker IBCs routed to the cheapest capable tier. Error-correction iterations run in cheap space; the council re-enters only to judge and realign.

The Plan Is a DAG of Boundary Conditions

A campaign plan is not a task list. It is a dependency graph of IBCs whose premises reference world state that sibling executions mutate. When worker P3 lands an unexpected fix, the premises baked into pending prompts P4–P9 may now describe a world that no longer exists. An open-loop dependency graph drifts exactly like an open-loop token walk, only at a coarser timescale. Hence two central invariants that are examined together at every RECONCILE boundary:

Premise Freshness: before dispatching any pending node, re-verify its IBC's premises (S1 tripwires) against current HEAD. A stale premise marks the node INVALIDATED; its IBC is realigned before dispatch.

Goal Supremacy / Mutable DAG: execution yields exponentially more context than planning — the higher-level goal reigns over the pre-specified DAG skeleton, not the reverse. At every RECONCILE boundary the composer runs the cheap DAG-vs-goal check; the moment it suggests the graph no longer serves the goal, the architect seat is convened (this, not routine per-node review, is what summons it). DAG amendments — adding, editing, or removing nodes — are the norm, not a deviation; staying faithful to an arbitrary initial structure while overlooking what execution revealed is the failure mode this guards against. Each amendment routes to the architect seat and is TIERED by the contract (§Amendment tiers under RECONCILE): a MECHANICAL amendment proceeds on the architect's recorded single assent; a LOAD-BEARING amendment is ratified by the head before any affected node is re-dispatched.