STD-GATE-001: Canonical Factory Pre- and Post-Execution Gate (BLUEFLY_FACTORY_EXECUTION_GATE)¶
Status: Approved Governing Standard — Binding Factory Directive
Authority: Thomas P. Scola Jr. — Factory Operating Contract & Execution Law
Standard ID: STD-GATE-001
Date: 2026-09-24
Owner: BLU (kingstown-core.blu) — Director & Governance Lead
1. Prime Directives & Central Laws¶
Beads + Documentation are required work, not aftercare. No Bluefly Factory change is complete unless its durable work state and durable knowledge state are updated as part of the same operation.
If the work happened but the Bead was not updated, the Factory does not know it happened.
If the architecture changed but the documentation was not updated, the next Agent will rediscover or contradict it.
If runtime changed without source delivery, the next deployment can erase it.
If the Agent claims success without evidence, the result is not trusted.
Documentation, work state, source delivery, and verification are all part of the work itself.
2. Single Completion Law¶
The required completion lifecycle for every operation across every Agent, Rig, Formula, Infrastructure, Drupal, Policy, or CI change is strictly:
BEAD
└─► CLAIM
└─► EXECUTE
└─► VERIFY
└─► RECORD EVIDENCE
└─► UPDATE DURABLE KNOWLEDGE
└─► SOURCE DELIVER
└─► WITNESS
└─► CLOSE
A change that skips any applicable stage is: DONE=NO.
3. Pre-Execution Gate Schema (18-Vector Check)¶
Before source or runtime mutation, every executing Agent MUST resolve the following 18-point vector:
WORK_AUTHORITY= # Beads ID (e.g. bl-xxxx). Must exist in Dolt.
SOURCE_AUTHORITY= # Canonical GitLab project ID / path.
OWNER= # Assigned executing Agent / Role (e.g. Polecat, Refinery).
RIG= # Bound Gas City Rig (e.g. contextcontrol-ai).
BEAD= # Active claimed Bead ID.
CLAIM= # YES | NO (Claim verified in Beads ledger: ACTIVE_CLAIM_COUNT=1).
CAPABILITY_MATCH= # PROVEN | PARTIAL | NONE (Upstream-first match).
SOURCE_OWNER= # Upstream package / vendor / Bluefly project owner.
AUTHORITY= # Scope ∩ Platform Perms ∩ Safety Policy.
SERVICE_IDENTITY= # Machine service account (NO personal tokens).
POLICY= # Cedar / ContractPlane policy reference.
DEPENDENCIES= # Upstream blocker Beads (must be 0 unresolved).
EXECUTION_SURFACE= # Gas City managed worktree path (NO estate root).
CUSTOMER_OPERATION= # Operation served (CUSTOMER_OPERATION_SERVED=).
ACCEPTANCE= # Explicit testable definition of done.
VERIFICATION= # Independent Witness test definition.
DELIVERY_PATH= # Governed MR target branch (e.g. release/v0.1.x).
EVIDENCE_PATH= # Where immutable receipt and logs are recorded.
Evaluation Results:
- FACTORY_GATE=PASS: All 18 keys populated, claim verified, service account active, dependencies clear $\to$ Proceed to mutation in Gas City worktree.
- FACTORY_GATE=FAIL: Missing Bead, missing claim, personal token, or unmanaged path $\to$ Hard stop. Emit defect event. Do not mutate.
- FACTORY_GATE=READ_ONLY: Investigation / read-only discovery needed $\to$ Read/inspect only. No writes.
4. Execution & Continuous Work Tracking Laws¶
Rule 1: No Work Without a Claimed Bead¶
- Every executing Agent/session MUST maintain
ACTIVE_CLAIM_COUNT=1. - Unclaimed work, invisible work, or "fixing something nearby" without a claimed Bead is strictly prohibited.
- Before starting, search existing Beads (
bd ready,bd list --status in_progress,bd show <id>). Update existing work items rather than creating duplicates.
Rule 2: Continuous Bead State Updates¶
The Bead is the durable work record. Update the Bead immediately whenever any of the following change:
ROOT_CAUSE, SCOPE, BLOCKER, OWNER, BRANCH, MR, COMMIT, RUNTIME_STATE, ACCEPTANCE, VERIFICATION, DEPENDENCY, DISCOVERED_DEFECT.
Minimum structured state required on the Bead:
rig=
branch=
mr=
commit=
owner=
customer_operation=
product_impact=
Rule 3: Evidence Before Claiming Success¶
Before declaring FIXED, DONE, RESTORED, CONVERGED, HEALTHY, or SHIPPED, the executing Agent MUST attach concrete evidence to the Bead:
REQUESTED_EFFECT=
OBSERVED_BEFORE=
CHANGE=
OBSERVED_AFTER=
VERIFICATION_METHOD=
COVERAGE=
KNOWN_LIMITS=
5. Knowledge & Documentation Governance¶
Rule 4: Mandatory Knowledge Updates¶
Documentation update is mandatory whenever work changes: ARCHITECTURE, OWNERSHIP, OPERATING MODEL, SECURITY MODEL, DEPLOYMENT MODEL, CONFIGURATION MODEL, API CONTRACT, PRODUCT BOUNDARY, FACTORY STANDARD, RECOVERY PROCEDURE, or KNOWN LIMITATION.
Rule 5: Documentation Authority Order¶
1. CURRENT SOURCE / LIVE RUNTIME
2. ENGINEERING STANDARD / ADR
3. PRODUCT AUTHORITY
4. PROJECT-SPECIFIC DURABLE DOC
5. BEAD
6. GENERATED REPORT / SCRATCH
Rule 6: Placement Rules¶
BluCity-Docs: Reserved for durable cross-project knowledge (Factory architecture, Gas City standards, identity/auth standards, CI standards, security standards, Oracle/NAS operating models, Drupal engineering doctrine, Factory Interface Contract). Task status belongs in Beads, NOTBluCity-Docs.- Project Repositories: Project-specific implementation details remain in the owning repository.
- ADR (Architecture Decision Records): Mandatory when changing system authority, source ownership, deployment topology, runtime boundary, security boundary, storage authority, public/private pack boundary, API exposure, or identity model.
- Incident Records: Incidents require TWO durable records: a Bead (for executable remediation) and an Incident Record (for durable technical learning distinguishing
OBSERVED,INFERRED,PROVEN,NOT_ESTABLISHED).
Rule 7: Source Delivery for Documentation¶
Documentation is source. All documentation updates MUST follow the standard delivery flow:
WORKTREE → BRANCH → COMMIT → MR → CI → MERGE. Direct inline edits without MRs are prohibited.
Rule 8: RunningTodo.md Projection Status¶
RunningTodo.md is a human navigation projection. Beads are canonical executable authority. RunningTodo.md updates MUST reference actual Bead IDs.
6. Economic & Product Value Gates¶
Rule 9: Product Impact Declaration¶
Every change MUST declare its product/customer impact:
CUSTOMER_OPERATION_SERVED=
PRODUCT_BLOCKER=
REVENUE_EFFECT=
COST_EFFECT=
RELIABILITY_EFFECT=
WHY_IS_THIS_WORK_BEING_DONE= MUST justify the execution.
Rule 10: Binding Economic Gate¶
Every completed material change MUST answer the Economic Gate:
IS_THE_NEXT_RUN_GETTING_CHEAPER_AND_MORE_REUSABLE= [YES | NO | NOT_ESTABLISHED]
WHY=
YES requires empirical evidence of reduced repeated human work, reduced model spend, fewer custom components, more deterministic execution, improved discoverability, or lower runtime cost.
Rule 11: Learning & Repeat Work Promotion¶
- Reusable findings MUST be evaluated for capability candidate status rather than remaining in chat transcripts.
- Substantially identical actions performed
REPEAT_COUNT >= 3times MUST be evaluated for capability candidate promotion (policy, test, procedure, Formula, CI component, or Skill).
7. Handoffs, Witness Verification & Post-Execution Gates¶
Rule 12: Durable Handoff Protocol¶
Agent handoffs require updated Bead state before routing:
BEAD_UPDATED=YES
CURRENT_STATE=
NEXT_ACTION=
BLOCKER=
EVIDENCE=
MAIL_SENT != HANDOFF_COMPLETE. The Bead is the binding handoff contract.
Rule 13: Independent Witness Verification¶
- For material production, security, identity, architecture, customer-facing, work authority, or storage changes, the executor MAY NOT close its own Bead.
- Witness Verification Rule:
EXECUTOR=done AND WITNESS=pass → CLOSE.
Rule 14: Required End-of-Work Receipt¶
Every material task MUST conclude with the structured End-of-Work Receipt:
BEAD=
OWNER=
RIG=
REQUESTED_EFFECT=
SOURCE_CHANGED=
RUNTIME_CHANGED=
DOCS_CHANGED=
BRANCH=
COMMIT=
MR=
CI=
EVIDENCE=
COVERAGE=
KNOWN_LIMITS=
BEAD_UPDATED=
DEPENDENCIES_UPDATED=
CANONICAL_DOC_UPDATED=
DOC_PATH=
SOURCE_DELIVERED=
RUNTIME_VERIFIED=
WITNESS_VERIFIED=
IS_THE_NEXT_RUN_GETTING_CHEAPER_AND_MORE_REUSABLE=
WHY=
NEXT_ACTION=
DONE=NO.
Rule 15: Session End Gate¶
Before any Agent session stops, suspends, or rotates, the following gate MUST be satisfied:
ACTIVE_BEAD_UPDATED=YES
UNCOMMITTED_WORK_ACCOUNTED_FOR=YES
UNPUSHED_WORK_ACCOUNTED_FOR=YES
MR_STATE_RECORDED=YES
BLOCKERS_RECORDED=YES
DOC_CHANGES_RECORDED=YES
NEXT_ACTION_RECORDED=YES
8. Role Enforcement & CI Integration¶
MAYOR Enforcement¶
MAYOR continuously audits for governance defects: unclaimed active work, work without Beads, merged MRs with open Beads, closed Beads without evidence, runtime changes without source, source changes without doc updates, and stale in-progress Beads.
BLU Enforcement¶
BLU owns convergence by asking five questions continuously:
1. What customer operation are we proving?
2. What stage is it in?
3. What is blocking it?
4. Who owns that blocker?
5. Is the next run getting cheaper and more reusable?
CI Automation¶
Where deterministic, CI jobs in gitlab_components enforce: missing Bead references in MRs, missing doc disposition, stale generated docs, direct-runtime changes, forbidden local paths, and missing evidence metadata.