Chapter 23: How Work Flows
Parts III and IV established what the governance infrastructure requires: the escalation path from system to human, the recalibration protocol when monitoring signals drift, the mode transition cascade when a recalibration crosses into delegation territory, the authority grant that must exist before execution begins. The structures are defined. The decision types are named. The ownership model is in place.
This chapter addresses a different question: how does that infrastructure actually get activated in the daily flow of work?
The governance infrastructure does not activate itself. Someone has to submit the executor for ACG review before it deploys. Someone has to include the authority grant record in the definition of done. Someone has to prioritize the recalibration assessment when the sprint is already full. Someone has to update the ownership register when an executor's state changes at closure. The gap between a well-designed governance model and a functioning one is not structural — it is operational. It is the gap between the governance model that exists and the delivery flow that activates it.
This chapter addresses three specific points in the delivery flow where that gap opens most frequently, and what it takes to close each one.
THE CORE IDEA
The delivery flow of a hybrid organization — intake, prioritize, execute, close — was designed for human work. It handles features, services, infrastructure, and operational requests. It does not naturally handle the governance registration, prioritization, and closure requirements that non-human executors introduce, because it was not designed with those requirements in mind.
Extending the delivery flow to accommodate executors does not require a new process. It requires three targeted additions: a governance registration route at intake, a deadline-aware prioritization category for governance work, and an extended definition of done at closure that includes governance completion alongside delivery completion. Each addition is small. The aggregate is what makes the governance model function rather than merely exist.
INTAKE: THE CONNECTION BETWEEN DEPLOYMENT AND GOVERNANCE
In most hybrid organizations, work enters the delivery flow through an intake process designed for human work. Executors enter the execution surface through a deployment pipeline designed for technical delivery. These two processes run independently. The deployment pipeline does not route through the governance intake. The result is executors appearing on the execution surface without the registration step that triggers ACG authorization review, governance owner assignment, escalation surface design, and monitoring configuration.
The gap is not visible in the delivery metrics. The deployment pipeline shows a healthy deployment rate. The ACG log shows a healthy review completion rate. The discrepancy — executors deployed without reviews — only surfaces when someone compares the two. Until that comparison is made, each process appears to be functioning correctly while together they are producing an executor gap.
The design is a routing rule, not a new process. The intake system already handles multiple work types. It needs one additional category: executor deployment. When work is categorized as an executor deployment — a new automation, an AI agent, a vendor execution dependency entering or materially changing on the execution surface — the intake routing sends it through the ACG authorization review before it enters the sprint. The team's intake process does not change for feature work, technical debt, or operational requests. It gains one additional category and one additional routing branch.
Where this routing rule lives depends on the tools the organization already uses. The implementation pattern is consistent across all of them — no new tool is required in any case.
In a project management tool (Jira, Linear, Asana): A new issue type — Executor Deployment — with a required executor type field and a workflow automation rule: when issue type = Executor Deployment, automatically assign to ACG review queue and block sprint assignment until ACG review status = Complete. This is a configuration change to the existing tool, not a new workflow.
In a deployment pipeline (GitHub Actions, GitLab CI, ArgoCD): A pre-deployment check step that queries whether an ACG authorization record exists for the executor being deployed. If no record is found: deployment is blocked and the ACG lead receives an automated notification. If a record is found: deployment proceeds. This is a pipeline gate configuration — a few lines added to the existing pipeline definition.
In a lightweight or early-stage setup (pull request template): A PR template for any change that deploys a non-human executor, with a required checklist item: ACG review completed — link to record. The PR cannot merge without the checkbox checked. This is a template file added to the repository — no tooling change required.
In all three cases, the structural guarantee is the same: the executor cannot enter the sprint or the surface without passing through the ACG review gate. The gate is reached structurally, not through individual awareness of the requirement.
PRIORITIZATION: GOVERNANCE WORK HAS DEADLINES
Governance work — recalibration assessments, ownership register updates, ACG submissions, authority grant record reviews — competes for team capacity in the same backlog as features, technical debt, and operational requests. Under delivery pressure, governance work is consistently the category that moves to the next sprint. Each individual deferral is defensible. The aggregate is the frozen governance model: an organization whose governance infrastructure exists but whose governance processes have not produced a decision in months.
The structural cause is a prioritization framework that does not distinguish between work with organizational discretion and work with organizational deadlines. A feature can move to next sprint. A recalibration triggered by a monitoring signal thirty-two days ago cannot — it has a deadline set by the protocol in Chapter 15. An ACG submission for an executor deploying in two weeks cannot move without either delaying the deployment or deploying without authorization. An ownership register update for an executor whose governance owner has changed cannot defer indefinitely without breaking the monitoring chain.
The design is a deadline-aware governance category in the backlog. Governance work items carry a protocol deadline — the date by which the work must be complete as specified in the relevant governance process. Recalibration assessments carry the thirty-day deadline from Chapter 15's signal-triggered protocol. ACG submissions carry the deployment gate: the executor cannot go live without the review. Authority grant record reviews carry the quarterly governance session date as their backstop. These deadlines are not negotiable in the same way a feature's sprint assignment is negotiable. They are governance obligations with the structural weight of a regulatory filing deadline.
This does not mean governance work always outranks delivery. It means governance work enters the prioritization conversation with its deadline visible, so that the team is making an informed tradeoff rather than a reflexive one. A team that defers a recalibration assessment knows it is making a governance exception with a named date by which the exception must be resolved. The decision may still be made — delivery pressure is real — but it is made deliberately rather than invisibly.
Left: without deadline-aware governance, all governance items land at P3 — indistinguishable from low-priority features and consistently moved to next sprint. Right: with the deadline field, governance items surface by urgency. Red items cannot move — the executor is undeployed or the protocol is overdue. Amber items require an explicit governance exception to defer. Prioritization becomes a deliberate decision rather than a reflexive one.
CLOSURE: DELIVERY-COMPLETE IS NOT GOVERNANCE-COMPLETE
Work closes in the delivery flow when the output is accepted and shipped. In a hybrid organization, delivery-complete is not the same as governance-complete. An executor that has been built and deployed does not automatically have its authority grant record filed, its monitoring configuration verified, its escalation surface tested, or its ownership register entry created. These governance closure steps are not part of the delivery definition unless they are explicitly added to it.
The most common pattern: a team deploys an executor, marks the work done in the sprint, and moves to the next commitment — leaving the executor on the surface without the governance infrastructure the operating model requires. The executor is running. The authority grant has not been filed. The escalation owner does not know they hold that role. The monitoring is configured but its thresholds have not been validated against the authority grant record. The ownership register has not been updated.
The technical delivery is complete. The governance delivery is not. The gap is invisible in delivery metrics — velocity, throughput, deployment frequency — because those metrics measure the human work flow, not the governance registration that must close alongside it.
Extended definition of done for executor deployments. When work involves a non-human executor entering or changing state on the execution surface, the definition of done includes five governance completion items alongside the technical completion criteria: authority grant record filed in the ACG governance library; monitoring configuration verified against authority grant thresholds; escalation surface tested — at least one test escalation routed to the escalation owner and acknowledged; escalation owner confirmed awareness of their role; ownership register updated. Work involving an executor does not close until all five are checked.
Where this checklist lives also depends on the tools in use. In a project management tool: the Executor Deployment issue type carries a required checklist section — the issue cannot be marked Done until all five items are checked. In a deployment pipeline: a post-deployment verification step runs the five checks and records pass/fail against the authority grant record, blocking release to production if any fail. In a pull request setup: the PR template for executor deployments includes the five-item checklist as required fields. The implementation differs; the structural guarantee is the same — governance completion is verified at closure, not assumed.
The full definition of done for an executor deployment: delivery-complete (left) and governance-complete (right). All five governance artifacts must be filed and confirmed before the work item closes. The bottom row shows where the checklist lives in common tooling — project management tool, deployment pipeline, or pull request template.
THE THREE ADDITIONS IN PRACTICE
None of the three additions requires a new tool or a separate process. Each extends an existing step in the delivery lifecycle with governance content the hybrid operating model requires.
Intake: One additional work type (executor deployment) with one routing rule. Implementation: a new issue type in the project management tool with a workflow automation blocking sprint assignment until ACG review is complete — or a pre-deployment pipeline gate that checks for an existing authorization record. No new tool required.
Prioritization: One additional metadata field on governance work items: protocol deadline. Implementation: a required date field on the governance work item type, visible in sprint planning views. Deferring a deadline-bearing item requires explicit acknowledgment rather than a default backlog drag.
Closure: Five governance completion items in the definition of done for executor deployments. Implementation: a required checklist section on the Executor Deployment issue type — the issue cannot close until all five are checked — or a post-deployment pipeline verification step that records pass/fail against the authority grant record.
These three additions ensure governance is enforced at entry (intake), protected under pressure (prioritization), and verified at completion (closure). Without all three, the governance model leaks. An organization that adopts the intake routing rule but not the deadline-aware prioritization will see its governance backlog quietly drift past its deadlines. An organization that adopts the closure checklist but not the intake routing will find executors on the surface that never needed to meet the checklist because they never passed through the gate. The three additions are interdependent — partial adoption produces partial governance, which is effectively no governance at all.
These three additions do not make the delivery flow heavier. They make it complete. A delivery flow without them is a flow designed for a human-only execution model being applied to an organization that has a substantial system layer. The three additions are what close the operational gap between the governance model that Parts III and IV built and the daily work that activates it.
THE FAILURE MODE
The organization has governance infrastructure, but no mechanism to activate it inside delivery. Governance becomes a parallel obligation rather than a property of the delivery system — and is consistently crowded out.
Executors enter the surface through the deployment pipeline without governance registration. Governance work sits in backlogs competing with features and losing consistently. Executors close in sprints with delivery-complete status while their authority grant records remain unfiled and their escalation owners remain unaware of their role. The governance infrastructure accumulates debt with each delivery cycle — not because teams are negligent, but because the delivery flow was never extended to carry governance obligations alongside delivery obligations.
The correction does not require rebuilding the governance model. It requires three targeted additions to the delivery flow the organization already runs. The structural investment is small. The consequence is significant: the difference between a governance model that requires deliberate effort to bypass and one that requires deliberate effort to activate.