The Modern CTO Circle

This appendix provides the five operational boundary protocol templates referenced in Chapter 16: Designing for Role Clarity Under Ambiguity. Each protocol addresses one predictable boundary dispute in a hybrid execution governance model.

Protocol 1 System owner vs escalation owner

Parties	System owner (engineering, governs machine behavior) · Escalation owner (domain expert / PM / business, decides deferred cases)
Predictable dispute	Who bears accountability when an escalated case produces a poor outcome — the system for routing it incorrectly, or the human for deciding it incorrectly.
Resolution criteria	A well-formed escalation from this system meets all three of the following: 1. The case falls within the documented escalation boundary conditions for this workflow. 2. The escalation package includes all required context fields as defined in the system specification. 3. The system confidence score is below the defined escalation threshold. If all three are met: the escalation was correctly formed. Decision accountability sits with the escalation owner. If any are not met: the system owner bears accountability for a mis-routed case.
Decision authority	Domain lead or head of the business function the system serves. Named person: [to be completed]
Escalation timeframe	Resolution within 5 business days of dispute being formally raised.
Review cadence	Annually, or when execution mode or escalation boundary conditions change.
Protocol owner	System owner, in consultation with escalation owner. Filed in ACG governance library.

Protocol 2 Governance owner vs purpose owner

Parties	Governance owner (engineering / technical, owns system behavior) · Purpose owner (PM / business lead, owns outcome fitness)
Predictable dispute	When outcomes deteriorate — whether the cause is behavioral drift the governance owner should have detected, or design parameter misalignment the purpose owner should have identified in their last purpose review.
Resolution criteria	Step 1 — behavioral baseline check (governance owner): Has the executor's behavioral performance changed relative to its documented baseline? If yes: behavioral drift is the primary hypothesis. Governance owner leads the investigation into what changed and when. If no: behavioral performance is stable. Purpose owner leads investigation into whether design parameters remain appropriate for current conditions. If both factors are present: proceed immediately to joint assessment under the recalibration protocol (Chapter 15). Neither owner investigates alone.
Decision authority	Head of engineering. Named person: [to be completed]
Escalation timeframe	Joint assessment initiated within 48 hours of dispute. Resolution within 10 business days.
Review cadence	Annually. Triggered immediately when a dual ownership executor is involved in a significant business outcome failure.
Protocol owner	Both owners jointly. Filed in ACG governance library and referenced in the ownership register entry for this executor.

Protocol 3 Automation owner vs ACG

Parties	Automation owner (product / engineering team) · ACG (governance function, owns standards and review process)
Predictable dispute	Whether a proposed deployment change requires a full governance review or qualifies for the self-certification framework.
Resolution criteria	Full review required: execution mode changes; model architecture or training data changes; threshold changes exceeding ±15% on consequential decisions; deployment to a new domain or population; changes affecting data access scope. Self-certification sufficient: parameter adjustments within documented bounds; monitoring configuration updates; documentation updates; non-consequential output formatting changes. Ambiguous cases: the ACG makes the classification. The automation owner may appeal to the head of engineering within 2 business days. The appeal does not pause the review requirement.
Decision authority	Head of engineering on appeal. Named person: [to be completed]
Escalation timeframe	ACG classification decision within 24 hours of submission. Appeal resolved within 3 business days.
Review cadence	Annually. Change-type criteria updated whenever new executor types or significant technology changes are introduced.
Protocol owner	ACG. Criteria published in governance library and accessible to all product and engineering teams.

Protocol 4 Execution architect vs engineering leadership

Parties	Execution architect (aggregate execution surface design) · VP of Engineering / Engineering leadership (delivery and team organization)
Predictable dispute	When a recommended execution model migration requires platform investment or team capacity reallocation that conflicts with current delivery priorities.
Resolution criteria	The execution architect has advisory authority on execution surface design. They recommend; they do not require. Engineering leadership is not required to act on a recommendation. When a recommendation requires platform investment or capacity reallocation that engineering leadership will not approve, the execution architect escalates to the CTO with a structured brief containing: the migration recommendation, the governance risk of deferral, the required investment, and the proposed timeline. The CTO decides: approve the investment, defer the migration with a defined review date, or explicitly accept the governance risk in writing.
Decision authority	CTO. Named person: [to be completed]
Escalation timeframe	CTO decision within 10 business days of structured brief submission.
Review cadence	Annually, or when the execution architect mandate is updated. Escalation path tested at least once per year.
Protocol owner	Execution architect. Mandate scope documented and confirmed with CTO at role establishment.

Protocol 5 ACG vs platform team

Parties	Automation capability group (governance standards and enforcement) · Platform team (infrastructure, tooling, and deployment infrastructure)
Predictable dispute	When governance requires platform infrastructure — monitoring tooling, deployment gates, observability — that the platform team's roadmap does not currently prioritize.
Resolution criteria	The ACG submits governance infrastructure requirements to the platform roadmap as a formal input at each quarterly planning cycle, with a risk classification: Critical — governance is impossible without this infrastructure. Reviewed by CTO before the roadmap is finalized. Significant — governance is materially degraded without it. Prioritized by platform lead against other roadmap items. Desirable — governance is improved with it. Considered in backlog. Unresolved Critical requirements escalate to the CTO immediately — not at the next planning cycle.
Decision authority	CTO for Critical requirements. Platform lead for Significant and Desirable. Named CTO: [to be completed]
Escalation timeframe	Critical: CTO decision within 5 business days. Significant: resolved within the quarterly planning cycle.
Review cadence	Quarterly, aligned with platform planning cycle. Protocol updated when governance standards change significantly.
Protocol owner	ACG in collaboration with platform team lead. Governance requirements input process documented and shared with both functions.