--- protocol: brigade-v1 name: The Brigade Protocol author: Axl Ibiza core_primitive: INTERLOCK canonical_coordination_surface: repository synchronous_coordination_policy: exception-path status: independent-contributor-protocol --- # The Brigade Protocol ## Purpose The Brigade Protocol translates professional kitchen operations into an operating system for coordinated human and AI work. Use it when many actors must work in parallel across shared surfaces without confusing local agency, global state, or integration authority. It is designed for repositories and other durable work graphs, especially when the volume of issues, pull requests, dependencies, collisions, historical attempts, and contributor credit is too large for any one person to hold in memory. ## Prime directive Exercise maximum agency inside precisely understood boundaries. Report only the state the evidence supports. Preserve every contributor's work and credit. Coordinate toward the completed table, not a pile of locally correct orphaned dishes. In compact form: > Maximum initiative. Exact status. No false authority. No orphaned work. ## The central invariant A station can be completely ready while the table is not complete. Local success is real. It is not permission to claim collective completion. Therefore: - FIRED does not mean READY. - READY does not mean INTEGRATED. - INTEGRATED does not mean RELEASED. - HEARD does not mean AGREED. - REVIEWED does not mean APPROVED. - READY_FOR_PICKUP does not mean MERGED. - TABLE_READY does not mean SOLD. ## Operating model Treat a coordinated work system as a brigade service: 1. Work enters as addressable tickets. 2. Tickets sit on a visible rail, bound to their campaign and dependencies. 3. The system computes the all-day count from the live graph. 4. Mise en place verifies prerequisites before work is fired. 5. Station owners execute with bounded authority. 6. Every shared surface receives an INTERLOCK. 7. Low, 86, behind, corner, hands, and refire calls make exceptions explicit. 8. A taste plate proves the method before repetition at scale. 9. Verified work moves to the pass as READY_FOR_PICKUP. 10. Expo or the maintainer integrates the whole table and alone declares it SOLD. ## Vocabulary and invariants ### Station ownership → bounded contributor authority Own the work within the assigned or claimed station. Inspect, decompose, implement, test, document, interlock, and declare local readiness. Do not claim authority over another station, approval, merge, release, or repository policy unless that authority was explicitly granted. ### Ticket → addressable work unit Every obligation must have an identity, scope, owner or claiming rule, status, and evidence surface. Work that cannot be named, linked, or inspected is not ready to enter service. ### Ticket rail → visible ordered queue The queue belongs in durable shared state, not in one person's head or a disappearing conversation. The rail exposes ordering, readiness, collisions, and blocked work. ### All day → live aggregate of outstanding work Compute total demand from every live ticket and every required edge. Never optimize one ticket against a false total. ### Campaign graph and ledger → durable all-day state The graph shows relationships. The ledger records obligations, owners, status, evidence, exceptions, and completion receipts. Together they prevent orphaned work and false completeness. ### Fire → authorized activation Queued does not mean active. Fire only when scope, dependencies, inputs, tools, tests, rollback path, and authority are explicit. ### Fire order → dependency and land order Order work by actual dependencies, collision windows, and integration strategy. When two changes touch the same surface, declare who lands first and what must rebase or re-anchor afterward. ### Mise en place → verified prerequisites Prepare context, manifests, tools, fixtures, environments, baseline tests, ownership boundaries, and rollback paths before execution. Do not confuse possession of ingredients with readiness to cook. ### Prep list → manifest Use an explicit, inspectable manifest for files, symbols, interfaces, issues, pull requests, tests, contributors, and known exceptions. A manifest is a promise surface and must be kept current. ### Taste plate → conformance gate Prove one representative end-to-end result before repeating the operation at scale. The plate must exercise the real contract, not a decorative smoke test. ### Low → at-risk warning Call LOW before failure when capacity, confidence, freshness, test coverage, context, or mergeability is declining. Early truth gives the system room to compensate. ### 86 → blocked, unavailable, unsafe, or withdrawn Remove impossible work from the promise surface immediately. State the reason, impact, and re-entry condition. Never let the system plan around phantom availability. ### Behind / corner → collision warning Announce entry into a shared surface before touching it. Name the files, symbols, contracts, branches, or decisions at risk and the safe coordination path. ### Hands → request for review or integration help Ask for the exact help needed: direction, authority, verification, conflict resolution, or integration. A hands call is precise and actionable, not a generic escalation. ### Refire → evidence-triggered rework Return failed work to execution with the defect, invalidated assumption, new evidence, and next acceptance test made explicit. Refire does not erase prior history. ### Ready for pickup → locally complete and integration-ready The station has satisfied its contract, tests, documentation, provenance, and interlocks. This is a contributor claim about local evidence—not a claim of merge or release. ### Pickup → coordinated convergence Bring dependent components to the pass together in the declared order. A single ready dish does not complete a table. ### Pass → shared integration surface The pass is where local results become globally inspectable: usually the repository's issues, pull requests, review threads, manifests, checks, and campaign ledgers. ### Expo → maintainer integration authority Expo sees the whole table, resolves cross-station conflicts, accepts or redirects work, and authorizes merge or release. Contributors prepare and present the table; maintainers decide when it sells. ### Sell table → maintainer merge or release Only an actor with integration authority may declare the table sold. Until then, describe work as open, verified, ready, superseded, conflicted, or blocked—never landed merely because its branch is complete. ### Breaking down a whole pig at its seams → evidence-led decomposition Find the structure that is already physically and historically true before cutting. In code, seams are proven by interfaces, call graphs, responsibility clusters, change history, failure boundaries, tests, and campaign relationships. Do not invent a taxonomy and force the system through it. ### Completed table → campaign completeness Optimize for the entire coordinated obligation: every required slice, integration edge, status transition, source contribution, and completion receipt. Locally valid orphaned work is not campaign completion. ## Roles and authority ### Station owner / contributor May inspect, research, propose, implement, test, document, preserve provenance, create coordination artifacts, and declare READY_FOR_PICKUP when evidence supports it. Must not claim another actor's receipt, reviewer approval, maintainer acceptance, merge, release, or organization policy. ### Swarm architect Designs the campaign topology: canonical objects, work decomposition, station boundaries, dependency and collision edges, evidence contracts, ledgers, interlocks, and convergence rules. A swarm architect can create a complete integration surface without possessing integration authority. ### Reviewer Evaluates evidence and records findings. REVIEWED means the work was examined. APPROVED must be an explicit state from an authorized reviewer. ### Expo / maintainer Owns global integration authority. Resolves direction, land order, cross-campaign conflicts, merge, and release. ### Repository / pass Acts as the canonical shared memory. Conversation may reveal a fact; the pass must retain the repaired state. ## The twelve service commands 1. **Own your station.** Take full responsibility inside its boundary; do not impersonate authority outside it. 2. **Ticket every obligation.** Make work addressable before acting on it. 3. **Count all day from the graph.** Derive total demand from live relationships, not memory. 4. **Set the mise before you fire.** Verify prerequisites, manifests, and rollback paths. 5. **Fire by dependency and land order.** Sequence work by the actual integration surface. 6. **Say HEARD only for receipt.** Do not silently upgrade acknowledgment into agreement or approval. 7. **Call BEHIND and CORNER before collision.** Announce shared-surface movement early. 8. **Call LOW, 86, and HANDS early.** Exceptions are operating signals, not personal failures. 9. **INTERLOCK every shared surface.** Bind work, people, evidence, state, and authority in durable repository state. 10. **Refire from evidence.** Make the failed assumption and new acceptance condition explicit. 11. **Put verified work at the pass.** Present a complete local contract with provenance and receipts. 12. **Complete the table and credit every hand.** Optimize for campaign convergence while preserving contributor authorship. ## INTERLOCK: the core coordination primitive An INTERLOCK is a durable, authority-aware coordination record that binds related work to the same shared state. It connects actors, tickets, campaigns, dependencies, collisions, evidence, receipts, provenance, and required transitions. INTERLOCK is not a label, a cross-link dump, or project-management decoration. It is a repository-native protocol for multi-actor coordination. Its existence gives every actor who touches one node access to the context required to act safely on the larger graph. This creates a distinct engineering category: coordination engineering as code. ### Required INTERLOCK fields Every interlock should expose: - canonical identity and parent campaign; - scope and proven seam; - station owner or claiming rule; - related issues, pull requests, branches, commits, and prior attempts; - dependencies and collision surfaces; - fire order and intended land order; - current state and last verified timestamp; - evidence, gates, and completion receipts; - authority boundary and required approver or integrator; - provenance, contributor credit, and supersession lineage; - LOW, 86, HANDS, or REFIRE conditions; - reconciliation rule and tombstone for duplicates or obsolete paths. ### Completion invariant A work unit is campaign-complete only when all of the following are true: 1. its local implementation and conformance gates pass; 2. every required graph edge exists and points to the canonical object; 3. dependencies, collisions, land order, and integration state are explicit; 4. provenance and contributor credit are preserved; 5. no required ticket is orphaned, silently duplicated, or falsely closed; 6. an actor with the necessary authority has performed the final transition. ## “This meeting could have been a Git INTERLOCK.” Meetings create shared moments. INTERLOCKS create shared state. Synchronous conversation is valuable for ambiguity, conflict, discovery, or human care. It should be the exception path for coordination—not the only place where the system knows what is true. When a conversation reveals new information: 1. state the observation and its confidence; 2. write it into the canonical repository object; 3. bind the affected nodes and owners; 4. declare the resulting transition or question; 5. leave a durable receipt so the next actor can continue asynchronously. Nobody needs a meeting merely to reconstruct state that the repository can carry. ## Germination Germination is current-main, provenance-preserving salvage of valuable prior work. Use it when a contribution is correct in intent but stale, partial, unmergeable, or detached from the current architecture. The germination sequence is: 1. identify the viable contribution and its original authors; 2. reconstruct intent from code, discussion, and history; 3. map it onto current main and the current campaign graph; 4. preserve authorship and explicitly credit every source hand; 5. implement or transplant through the current contract; 6. run the current conformance gate; 7. bind old and new objects with supersession and interlock records; 8. declare READY_FOR_PICKUP without pretending the result is merged. Germination is neither copy-paste nor appropriation. It is lineage-aware continuation. ## Execution loop for humans and agents For every assigned objective: 1. **Read the rail.** Identify canonical campaign objects, existing attempts, owners, dependencies, and current state. 2. **Declare the station.** State what you own, what you do not own, and which authority will be needed later. 3. **Build the manifest.** Enumerate relevant files, symbols, issues, PRs, tests, contributors, and exceptions. 4. **Find the seams.** Use structural and historical evidence before changing code. 5. **Set the mise.** Verify environment, baselines, tools, context, tests, and rollback path. 6. **INTERLOCK.** Bind shared surfaces and publish collision and land-order information. 7. **Fire.** Begin only the work whose prerequisites and authority are clear. 8. **Report exact state.** Use TICKETED, FIRED, WORKING, LOW, 86, REFIRE, READY_FOR_PICKUP, PICKUP, or SOLD precisely. 9. **Taste.** Validate a representative path before scaling repetition. 10. **Execute and verify.** Preserve provenance and attach evidence as work proceeds. 11. **Put it at the pass.** Present the local result, checks, known limitations, dependencies, and requested action. 12. **Reconcile the table.** Update campaign totals, duplicate paths, tombstones, credit, and downstream readiness. ## Required agent behavior An agent operating under this protocol MUST: - distinguish observation, inference, external report, and verified fact; - separate personal capability from granted authority; - search for existing work before creating new work; - preserve contributor authorship and explicitly trace salvage lineage; - expose uncertainty, missing context, collision risk, and stale evidence early; - record coordination in the canonical durable surface; - update graph state after new information is discovered; - avoid equating branch completion with merge or release; - optimize for campaign completeness, not activity volume; - request a precise maintainer or reviewer action when blocked by authority; - leave enough state that another qualified actor can continue without a meeting. An agent operating under this protocol MUST NOT: - claim maintainer, reviewer, or organization authority it does not possess; - report HEARD as AGREED, REVIEWED as APPROVED, or READY as MERGED; - hide failed assumptions behind vague progress language; - create duplicate work without a reconciliation plan; - erase superseded attempts, contributor history, or authorship; - optimize a local task by orphaning the rest of the table; - treat a coordination graph as complete when required edges or actors are missing. ## Standard status report Use this compact format: ```text STATION: TICKET: CAMPAIGN: STATE: VERIFIED: REPORTED: INTERLOCKS: PROVENANCE: GATES: AUTHORITY BOUNDARY: HANDS: NEXT TRANSITION: ``` ## Final instruction Own your station, not the kitchen. Make the whole service visible. Make every transition explicit. Find the real seams before cutting. Preserve every hand's work and credit. Put a verified table at the pass. Let expo sell it. --- The Brigade Protocol is an independent contributor protocol by Axl Ibiza. It is not official NousResearch policy.