Chapter 15: The Accountability Model

Chapter 12 established that ownership is active accountability — and that for most executors, one named owner carrying the five ownership components is sufficient. It also signaled that for executors consequential enough to affect significant business outcomes, a single owner may not fully close the accountability surface. This chapter addresses that condition: when a second owner is required, what each owner is specifically accountable for, how they collaborate, and how the recalibration process works when the two owners need to act together.

THE TWO OWNERSHIP ROLES

Every significant executor has two accountability dimensions. For most low- and medium-consequence executors, both dimensions can be held by the same person. When the executor is consequential enough, they require two distinct owners.

The governance owner is accountable for how the executor behaves — its technical fitness, its execution mode, its behavioral health, its documentation, and its handover. This is the automation owner role from Chapter 12. The governance owner answers: is this system performing correctly and governed appropriately right now?

The purpose owner is accountable for whether the executor remains appropriately designed for the outcome it was deployed to achieve. This is typically a product manager, business lead, or domain expert. The purpose owner answers: are the system's design parameters still right for the current context — and is it producing the outcomes the organization needs it to produce?

These are complementary, not competing. The governance owner governs the machine. The purpose owner governs the fit between the machine and the purpose it serves. For low- and medium-consequence executors a single person can hold both roles when their context is broad enough. For high-consequence executors, the roles require different expertise and should be explicitly separated.

Figure 1: Single vs dual ownership — when each applies

Single ownership is correct for most executors. Dual ownership is required when the executor affects significant business outcomes, its parameters can drift from current conditions, and the governance owner lacks domain context to evaluate purpose fitness.

GOVERNANCE OWNER: SCOPE AND DELIVERABLES

Behavioral monitoring and drift detection. Weekly monitoring for AI agents making consequential decisions; monthly for automations; continuous alerting for significant output distribution changes between formal reviews.

Execution mode verification. Quarterly confirmation that the documented execution mode matches actual practice — that human review steps are genuine where they exist, and that escalation paths are operational in system-led workflows.

Technical documentation and behavioral history. A living record of the executor's current behavior, known edge cases, dependency structure, and — for AI agents — the full behavioral history including drift events and interventions.

Ownership transfer. When the governance owner changes roles, a structured transfer that passes the documented context, behavioral history, and current governance state to the incoming owner before the transition is complete.

Recalibration execution. When a recalibration is jointly decided, the governance owner owns the technical implementation — assessing feasibility, implementing the parameter changes, and ensuring the change meets governance standards before deployment.

PURPOSE OWNER: SCOPE AND DELIVERABLES

Outcome monitoring. The purpose owner monitors the business metrics the executor was designed to move — default rates, conversion rates, error rates, customer outcomes — not the system's performance metrics. When outcome metrics diverge from expectations, the purpose owner is the first to see it and is accountable for determining whether the divergence requires investigation.

Periodic purpose fitness review. A structured review conducted quarterly for high-consequence executors: are the executor's current design parameters still appropriate for the current business context? Has anything changed in the market, regulatory environment, customer base, or strategy that would warrant a parameter adjustment or a fundamental redesign?

Business context and strategy alignment. The purpose owner maintains awareness of the strategic and operational context that the executor's design parameters depend on. When that context changes, they are accountable for flagging that a purpose review is needed before the next scheduled cadence.

Recalibration initiation. When the purpose review reveals a mismatch between the executor's design and current conditions, the purpose owner initiates the recalibration process. They cannot initiate technical changes unilaterally. They initiate the joint process that produces them.

HOW THE TWO OWNERS COLLABORATE

Figure 2: Governance owner vs purpose owner — scope and coordination zone

Each owner governs their own zone independently. The coordination zone is the shared infrastructure that connects their accountability — without it, dual ownership produces the appearance of governance while leaving the critical gap between system behavior and business purpose unaddressed.

Shared review cadence. The governance owner and purpose owner meet or share structured information quarterly at minimum. The governance owner provides a summary of the executor's behavioral health. The purpose owner provides a summary of outcome performance and any changes in business context.

Anomaly escalation protocol. When the governance owner detects a behavioral anomaly that might indicate a purpose mismatch, they escalate to the purpose owner immediately. When the purpose owner detects an outcome divergence that might have a technical or design cause, they escalate to the governance owner. The protocol defines what constitutes a trigger and the expected response time.

Joint recalibration decision. When either owner's review suggests a recalibration may be needed, the decision to proceed is joint. Neither owner can initiate a recalibration unilaterally. For high-consequence recalibrations, a leadership sign-off acts as a third gate. This is not a veto mechanism. It is a visibility and alignment check — ensuring senior technical and business leadership is aware of significant changes to consequential executors before they are implemented.

THE RECALIBRATION PROCESS

Figure 3: Recalibration process — decision authority at each step

Five steps with explicit decision authority. The process ensures neither owner can act unilaterally: the trigger is initiated by the purpose owner, the decision is joint, execution is owned by the governance owner, and the ACG review gate applies the same standards as a new deployment.

Step 1 — Trigger (purpose owner). The purpose owner identifies a mismatch between the executor's current design and current conditions. She documents the mismatch: what the current design assumes, what has changed, and what outcome the recalibration needs to achieve.

Step 2 — Joint assessment (both owners). Both owners assess the situation together. The governance owner contributes technical context: is the executor's behavior consistent with its design? What would a parameter change require technically? The purpose owner contributes business context: how significant is the mismatch? What outcome parameters should the recalibration target?

Step 3 — Decision (both owners, leadership sign-off if high-consequence). The decision to proceed, defer, or redesign entirely is made jointly. Neither owner can move to execution without the other's explicit agreement. For core design changes, a leadership sign-off is required before execution begins.

Step 4 — Execution (governance owner). The governance owner owns the technical implementation — assessing feasibility, implementing the change, and ensuring it meets the same deployment standards as a new executor deployment: behavioral baseline established, monitoring configured, documentation updated.

Step 5 — Governance review gate (ACG). Before the recalibrated executor goes live, the ACG conducts the same governance review it would apply to a new deployment. A recalibration that bypasses this gate is a new deployment that has avoided governance review. It is not permitted.

THE RECALIBRATION TEMPLATE

The recalibration template is the working instrument for Steps 1 through 3. Both owners complete it together before the decision gate is reached.

Executor record	Name · Executor type · Execution mode · Governance owner · Purpose owner · Date of last recalibration or deployment
Trigger	What prompted this review — the outcome metric that diverged, the context change, or the periodic review finding. Include the data: what the metric was, what it is now, and what threshold was crossed.
Current design assessment	What assumptions the current parameters encode, when they were last reviewed, and whether behavioral health is consistent with design. Completed by governance owner.
Business context assessment	What has changed in the business context since parameters were last set, and what outcome the recalibration needs to achieve. Completed by purpose owner.
Proposed change scope	Description of the change proposed and rationale for why it addresses the mismatch. Joint section.
Risk assessment	Risks of making the change and of not making it. Expected impact on both technical performance and business outcome metrics. Joint section.
Decision + approvals	Decision: proceed / defer / redesign. Signatures from both owners. Leadership sign-off if required. Date.
Post-deployment review	Date on which both owners will review performance against outcome targets. Typically 4–6 weeks after deployment.

WHEN DUAL OWNERSHIP IS REQUIRED

Not every executor warrants two named owners. The three conditions that identify when the structure is necessary: the executor affects significant business outcomes directly, its design parameters can become misaligned with current conditions, and the governance owner lacks the domain context to evaluate purpose fitness alone.

When these conditions are absent — a low-consequence automation whose outputs are reviewed by a human team before they have business effect — single ownership is correct. Adding a purpose owner where none is needed creates governance overhead without governance value.

The accountability design decision is binary per executor: is the executor consequential enough to require a purpose owner, or is governance ownership sufficient? That decision should be made explicitly at deployment, documented in the ownership register, and reviewed when the executor's business criticality changes.

THE FAILURE MODE

The failure mode specific to this chapter is one of three gaps — presented in order of the risk they carry.

Dual ownership without coordination. Both owners are named and functioning within their individual accountability. But the coordination zone is empty: no shared cadence, no anomaly escalation protocol, no joint decision process. Each owner is governing their own domain correctly while the connection between the system's behavior and its business purpose remains invisible to both. This is the most dangerous condition — because it produces the appearance of complete governance while leaving the critical gap unaddressed.

Governance ownership without purpose ownership. The system is technically well-governed. No one owns its fitness for current conditions. The system continues executing on outdated parameters, accumulating purpose drift that surfaces eventually as a business outcome failure.

Purpose ownership without governance ownership. The business outcome is monitored. The system's technical behavior is not. When an outcome failure occurs, the investigation is blind — no behavioral history, no drift record, no governance owner to consult.