Bottom line up front: AI initiatives in owner-operated businesses fail for the same reason every prior technology cycle failed — the governing layer is absent. The technology gets deployed; the governance does not. This paper describes the managed-initiative discipline that makes the right problem get solved before the technology is deployed, puts the governing layer in place before agents are authorized to act, and improves the initiative through each cycle rather than letting it drift into the "Sustained" state that defines most SMB AI deployments. It is not a project-management paper and not a technology paper. It is a governance paper, written for the owner who is simultaneously Product Owner, Project Sponsor, and Chief Inspector. The framework runs on ProjectBits’ own business-development pipeline — the receipts are real tables, policies, and decision logs. Paper #9 in the Thought-OS™ reading order.

Don Lovett, Fractional CFO & Managing Principal · ProjectBits Consulting · June 2026

The Missing Layer: the governance gap that produces undetected liabilities and stalled AI initiatives, and the path to trustworthy financials through policy-as-code, audit oversight, and a defined governance role.

An owner-operated business decides to deploy AI. Something specific — categorizing invoices, routing client requests, monitoring for exceptions in the books. The technology works in the demo. The deployment begins. Six months later the owner is spending more time managing the AI initiative than the initiative is saving them. One year later the project has been quietly set aside. The tools remain installed. Nobody talks about them.

Peter Drucker observed that the most dangerous failure mode in any organization is not incompetence. It is solving the wrong problem with great efficiency. The AI initiative that failed did not fail because the technology was poor. It failed because the problem identification was wrong — because the initiative was designed to deploy a capability rather than to solve a specific operational problem within a defined governing framework.

The cycle repeats not because AI is immature but because the managed initiative discipline is absent. The technology is deployed. The governance layer is not.

This paper describes the managed initiative framework — the discipline that ensures the right problem is solved before the technology is deployed, that the governing layer is in place before agents are authorized to act, and that the initiative improves through each cycle rather than drifting toward the quiet abandonment that defines most AI deployments in the SMB market.

It is not a project management paper. It is not a technology paper. It is a governance paper — written for the owner who is simultaneously the Product Owner, the Project Sponsor, and the Chief Inspector of the initiative. The business owner is above the loop. The framework exists to keep them there effectively.

The AI initiative that failed did not fail because the technology was poor. It failed because the governing layer was absent. The cycle repeats until the framework is in place.

The paper is organized in thirteen sections. It begins with the problem identification discipline — the Drucker question applied to AI initiatives — and moves through discovery, the dual-purpose test, the three-state lifecycle, scope management, the governing layer and its physical enforcement, the harness positions, the approval primitive, process mining and signal classification, the continuous improvement cycle, the convergence of governance and security and identity, the people layer, and the receipts that prove the methodology is operational.

The companion package — the Practitioner Roadmap, the governance setup tool, the three analytical notebooks, and the Streamlit monitoring application — is referenced throughout and described in the Companion Package section at the end.

Identify the Right Problem First

Drucker’s problem identification discipline — stated simply, the most common management failure is solving the wrong problem efficiently — applies to AI initiatives with particular force. AI is very good at optimizing toward whatever objective it is given. A miscalibrated objective, optimized efficiently, produces wrong outcomes at scale and at speed. The AI initiative that was supposed to reduce invoice processing time and instead trained on exceptions in a way that institutionalized the wrong categorization behavior is a real pattern, not a hypothetical.

The right question before any AI initiative begins is not: what can AI do here? It is: what is the specific, bounded, measurable problem that the initiative is supposed to solve, and is that the right problem?

The Three-Question Test

Before an initiative is chartered, three questions must have answers precise enough to be documented and verified.

1. What process is this initiative governing? Not a category — a specific named process with defined inputs, outputs, and decision points. ‘Invoice categorization for QBO account assignment’ is specific. ‘Improving financial operations’ is not.

2. What does a successful outcome look like in ninety days, and how will it be measured? The measure must be observable from the event log — not from the owner’s impression of whether things seem better. Override rate. Processing time. Exception volume. Specific and traceable.

3. What is the specific failure mode this initiative is designed to prevent? The corrective dream behind the initiative — the thing that went wrong somewhere, in the owner’s experience or in the client’s history, that this system is designed to make impossible — must be stated. It is the signal the initiative is trying to carry forward.

If any of the three questions cannot be answered precisely, the initiative is not ready to charter. The problem identification is incomplete. The dual-purpose test in Section 3 depends on precise answers to these questions. The harness position assignment in Section 7 depends on them. The Process Miner’s signal classification in Section 10 depends on them. An initiative that begins without them will not be able to distinguish a fit failure from an execution failure when the first Process Miner cycle runs — because there is no baseline to compare against.

The Amplification Risk

The signal clarity argument from Paper 10 applies here with force. The owner’s governing judgment — their specific standards, their specific ICP, their specific understanding of what correct looks like for this process — is the signal the initiative is supposed to amplify. An initiative that begins without a precise problem statement is an initiative that begins without a clean signal. The amplification carries whatever is in the system at deployment time. If what is in the system is vague intent and undocumented assumptions, the amplification carries those.

Clean signal requires a clean problem statement. The problem statement is the owner’s signal encoded into the initiative’s governing intent. Everything downstream — the scope boundaries, the harness positions, the approval gates, the Process Miner’s reference sequences — is downstream of that encoding. The initiative cannot produce signal clarity if the problem statement was never precise enough to encode.

Discovery as a Flashlight

Process discovery in a managed initiative is not documentation work. It is gap-finding work. The flashlight metaphor is precise: you are not trying to illuminate the entire landscape, you are trying to find the gaps — the places where the process, as it actually runs, deviates from how it is supposed to run.

The distinction matters because documentation-first discovery produces documents. Flashlight discovery produces a typed gap inventory. The gap inventory is what the Process Miner reads. The gap inventory is what the Gap Router classifies and routes to the owner for decision. The gap inventory is what the Brief Writer converts into build instructions. If discovery produces documents rather than a typed gap inventory, the entire downstream pipeline has nothing to read.

What Discovery Actually Finds

In a typical owner-operated business at Stage 2 or Stage 3 of the Financial Maturity Staircase, discovery finds four categories of gap.

Process gaps

Steps that should happen but do not. Documents that should be attached but are not. Reconciliation that should run weekly but runs monthly. Approvals that should be recorded but are handled verbally. These are gaps in the intended process — the process design is correct, the execution is incomplete.

Signal gaps

Data that exists but is not being read. Variance reports that are produced but not reviewed. Exception queues that accumulate without anyone working them. Anomaly flags that fire but are not escalated. These are gaps in the signal loop — the governing layer is not receiving the signal the data is producing.

Policy gaps

Decisions that are being made but not governed by documented policy. The categorization rule that varies by who processes the invoice. The escalation threshold that one employee applies and another ignores. The exception handling that depends on who is available rather than what the policy says. These are gaps in the encoding — the owner’s governing judgment exists but has never been made explicit.

Identity gaps

Actions that occurred but cannot be attributed. Credentials that were accessed but the accessor is unknown. Decisions that were made but the decision-maker is unrecorded. These are gaps in the audit trail — the governing record cannot answer the question ‘who did this and why?’ For a managed AI initiative, identity gaps are the most consequential discovery finding because they reveal an access surface without attribution.

The Discovery Output

Discovery produces a structured gap inventory in the format the Process Miner expects: process_type, case_id, activity, actor_type, actor_id, timestamp, status, signal_type (to be classified by NB1), and notes. Every gap is a row. Every row has enough context for the Gap Router to classify it and route it to the owner for a governing decision.

Discovery does not produce recommendations. It does not produce a technology selection. It does not produce a project plan. It produces a gap inventory. The gap inventory tells the owner what the process actually looks like. The owner’s governing decisions about what to do about each gap — accept, redesign, or govern — are the charter that the initiative executes against.

Discovery Scope Boundary

Discovery should be bounded by the initiative’s scope declaration before it begins. An unbounded discovery process finds gaps everywhere — in every process, across every system, including gaps outside the initiative’s governing reach. An unbounded gap inventory produces an unactionable backlog. Bound the discovery to the specific named processes in the initiative scope. Everything found outside that boundary is logged as an out-of-scope finding and reviewed in the next charter cycle, not acted on in this one.

The Dual-Purpose Test

Every process in an AI initiative scope must be classified before harness positions are assigned. The dual-purpose test is the classification mechanism. It asks one question about each process: does this process serve the client or partner directly, or does it serve internal operational efficiency?

The distinction is not about importance. Internal efficiency processes can be critically important. The distinction is about the consequence of an error and the appropriate oversight posture that consequence requires.

Customer-Serving Processes

A customer-serving process touches the client relationship, the client’s financial records, or a communication that reaches the client. An error in a customer-serving process has a relationship consequence — the client experiences the error. The relationship consequence may be significant before anyone inside the business knows an error occurred.

Customer-serving processes require In the Loop or Above the Loop harness positions until the accuracy threshold has been demonstrated through multiple sprint cycles of Process Miner validation. The threshold is not assumed. It is earned. An agent does not graduate from In the Loop to On the Loop on a customer-serving process because the owner trusts the technology. It graduates because the event log shows a demonstrated accuracy rate over a defined period.

Internal Efficiency Processes

An internal efficiency process touches operational records, internal workflows, or internal communications. An error in an internal efficiency process has a correction cost rather than a relationship consequence. The error can be caught and corrected before it reaches the client.

Internal efficiency processes can be assigned On the Loop or Under the Loop harness positions at earlier stages — not because they are less important but because the error recovery path is contained. An error in invoice categorization that is caught in reconciliation is a correction cost. An error in a client-facing communication is a relationship cost. The harness positions are calibrated to the consequence, not to the process’s importance.

The Test in Practice

The dual-purpose test is applied to every process in the gap inventory before harness positions are proposed. It is not a technical judgment. It is a governing judgment. The owner makes the classification because the owner knows the client relationship and the consequence of an error better than any system can determine from the process description alone.

When the classification is ambiguous — when a process touches both internal operations and client-facing outputs — the conservative classification applies. Classify as customer-serving. Apply the higher oversight posture. Let the Process Miner’s track record over subsequent sprint cycles provide the evidence for a reclassification decision.

The Three-State Lifecycle

Every AI initiative ends in one of three states. This is not a preference. It is a structural reality that the initiative’s governance framework must be designed to produce the right one.

Improved

The initiative delivered a measurable improvement to the specific process it was designed to govern. The override rate decreased. The processing time decreased. The exception volume decreased. The accuracy threshold was demonstrated through the Process Miner’s track record. The governing layer is in place. The harness positions are calibrated. The initiative continues and the governing layer compounds.

Improved is the target state. It is reached through a specific sequence: precise problem identification, bounded scope, typed gap inventory, calibrated harness positions, demonstrated accuracy, and a continuous improvement cycle that refines the governing framework through each sprint. An initiative that follows this sequence reaches Improved. An initiative that skips any element of the sequence may reach Improved anyway — but cannot reliably predict that it will.

Abandoned

The initiative did not deliver a measurable improvement and was discontinued. Abandoned is a valid and honest outcome. An initiative that was well-governed and honestly evaluated can reach Abandoned because the problem identification was wrong, or the technology was not ready for the specific use case, or the data quality was insufficient to support the governing layer.

Abandoned reached through honest evaluation is not failure. It is the dual-purpose test applied to the initiative itself: the initiative was a customer-serving process for the practice’s own operations, and the accuracy threshold was not reached. The governing framework correctly produced the Abandoned outcome rather than allowing the initiative to drift into the third state.

Sustained — The State That Must Never Be Accepted

Sustained is the third state. The initiative did not deliver a measurable improvement and was not discontinued. It is running. Nobody has the authority or the mechanism to stop it. The tools are installed. The agents are operating. The event log shows activity. The Process Miner has never been run, or has been run and its findings were not acted on, or has been run and produced findings that contradicted what the owner believed was happening and the findings were disputed rather than investigated.

Sustained is the failure state. It is the state that most AI initiatives in the SMB market are currently in. It is the state that produces the cycle described in the opening of this paper. The initiative running in Sustained is consuming the owner’s time without returning it — because nobody has made the governing decision to improve it or abandon it.

Sustained is not a neutral outcome. It is an ungoverned outcome wearing the appearance of a running system. The governing framework must make Sustained impossible by making the evaluation cadence mandatory and the decision authority clear.

The managed initiative framework makes Sustained structurally impossible through three mechanisms. The sprint review cadence requires a direction check at the end of every sprint — not a status update, a governing decision. The Process Miner produces classified findings that require a typed response: framework problem or execution problem, and what the owner decided to do about each. The owner’s role as Product Owner — not a passive reviewer but the decision authority who holds the charter — means every sprint produces a documented governing decision. An initiative cannot drift into Sustained if the governing decisions are being made and logged.

Scope Management

Scope creep in an AI initiative is structurally different from scope creep in a conventional project. In a conventional project, scope creep adds work. In an AI initiative, scope creep adds autonomous action surface — it expands the set of situations in which the agent acts without human oversight. The consequence of undiscovered scope creep in an AI initiative is not a delayed deliverable. It is an agent operating in a domain the owner did not authorize and the governing framework was not designed to cover.

AI-specific scope creep patterns must be identified before the initiative begins and guarded against throughout.

The Four AI-Specific Scope Creep Patterns

Capability creep

The agent, having demonstrated accuracy on the defined task, is asked to perform an adjacent task without a charter amendment. The adjacent task may be legitimately appropriate — but it was not subject to the dual-purpose test, the harness position assignment, or the process mining validation that the original scope received. Capability creep produces ungoverned capability: the agent is doing something the framework was not designed to govern.

Data creep

The agent, in the course of performing its defined task, accesses data that was not within the original scope. The invoice categorization agent that was granted access to the accounts receivable table and began making assessments about client payment behavior is an example. The data access was technically available. The governing framework did not anticipate it. Data creep produces ungoverned access.

Connection creep

The agent, through MCP tool calls or API connections, reaches systems outside the original scope. A connection to a new data source may be technically straightforward. If it was not authorized in the charter, it is ungoverned. Connection creep is particularly consequential when the new connection reaches external systems — client portals, vendor APIs, financial institutions — because the exposure surface extends beyond the practice’s infrastructure perimeter.

Persistence creep

The agent accumulates context across sessions — in memory files, in database records, in logs — in ways that were not anticipated in the scope definition. The agent that began remembering client preferences, or vendor patterns, or exception histories, without those memory capabilities being explicitly scoped, is exhibiting persistence creep. Accumulated context is a governance liability if it was not designed for: it can influence agent behavior in ways the framework cannot trace.

Scope Management Mechanisms

The scope declaration

Every initiative charter includes a scope declaration that states, explicitly, what processes are in scope, what data sources the agent is authorized to access, what external connections are permitted, and what persistence capabilities are authorized. The scope declaration is not a list of what might be needed. It is the definitive boundary of what is authorized. Everything outside it requires a charter amendment before the agent touches it.

The charter amendment protocol

Scope changes require a formal charter amendment, logged in the governing decision record with the owner’s rationale. The amendment process is designed to be slightly more deliberate than the request — not bureaucratic, but enough friction to ensure the decision is made consciously rather than casually. The amendment is the owner’s governing decision that the new scope was subject to the same rigor as the original scope.

The scope audit

The Process Miner’s monthly audit includes a scope audit: a review of what the agent actually accessed versus what the scope declaration authorized. Any discrepancy — any data accessed, connection made, or context accumulated that was not in the scope declaration — is a finding that requires a governing decision. Accept and amend the charter, or restrict and log the restriction. Either is a valid response. Neither response is required if nobody is running the audit.

The OPA/Rego Enforcement Layer

The scope declaration is a governing document. OPA/Rego is the enforcement layer that makes it operational. Every agent action that would touch data, make a connection, or accumulate context is evaluated against the OPA policy before execution. The policy is the scope declaration encoded in a form that machines enforce rather than humans remember. A scope declaration without OPA enforcement is a document. A scope declaration with OPA enforcement is a governing constraint. The distinction is the difference between governance that reports and governance that governs.

The Governing Layer and Its Physical Enforcement

The governing layer is the architecture that ensures the right thing happens in the agent’s absence — and that the wrong thing cannot happen, regardless of what the agent attempts. It is not a software layer alone. It is a combination of policy enforcement, identity verification, and physical attestation that together make the governing constraints real rather than nominal.

One sentence from the YubiKey integration architecture is the most precise statement of what the governing layer must address: ‘The agent and the human operator share an access surface with no physical boundary between them.’ That shared access surface — where both the human and the agent can reach the same credentials, the same systems, the same policy files — is the structural absence that most agentic deployments leave unaddressed. The governing layer closes it.

What the Governing Layer Must Enforce

Sovereign data ownership

The governing layer must ensure the data it governs belongs to the business that is being governed — not to a vendor, not to the agent, not to the framework provider. The event log, the policy files, the audit trail, the governing decision record — these must reside on infrastructure the business controls. A governing layer that produces its records in a vendor’s system is a governing layer that can be changed by the vendor, discontinued by the vendor, or made inaccessible to the business when the vendor relationship ends. Sovereign data ownership is not a technology preference. It is the prerequisite for everything the governing layer is supposed to do.

Tamper-evident audit trail

The audit trail must be tamper-evident — not merely append-only, but structured so that altering it requires simultaneously altering corroborating records across multiple systems. The events.operational_log table is the authoritative event spine. The Vault audit log is the corroborating credential access record. The Langfuse trace is the corroborating inference record. Together they create a chain of custody that cannot be broken without leaving evidence of the breakage.

The fourteen-step audit chain from the YubiKey architecture illustrates what tamper-evident looks like in production: from workflow_initiated through totp_generated through portal_authenticated through human_approval_required through human_approval_received through payment_executed through qbo_bill_created through workflow_completed. Every step. Every actor. Every timestamp. The chain is complete and unbroken. That is the receipt.

Policy-as-code enforcement

The governing policies — the scope boundaries, the harness positions, the approval thresholds, the data access limits — must be encoded in a form that machines enforce rather than humans remember. OPA/Rego is the enforcement layer. Every agent action is evaluated against the OPA policy before execution. The policy denies by default: everything is prohibited unless the policy explicitly permits it. An action that is not in the policy does not proceed. It logs. It escalates. It waits.

The OPA policy files are themselves under governance: they reside on an SSH-gated VM, modification requires hardware-attested human authentication, and every change is logged with the actor and the rationale. The governing layer governs itself.

The Physical Boundary

A logical governance boundary can be bypassed by a compromised agent session. A physical governance boundary cannot.

Consider the difference between a scope declaration that says ‘agents may not modify OPA policy files’ and a hardware-enforced boundary where OPA policy files reside on a VM accessible only through SSH with hardware key authentication. The scope declaration is a governing document. The hardware boundary is a governing constraint. A compromised agent session can ignore a governing document. It cannot bypass a physical key.

The YubiKey deployment architecture makes the distinction concrete. Human access paths — Vault credential write and policy administration, Proxmox host access, n8n workflow modification, OPA/Rego policy files, MCP server administration — require physical key authentication. Agent access paths — Vault credential read within scoped paths, Postgres event log insertion, Twenty CRM task creation, existing MCP tool calls — require scoped credentials without physical key. The boundary is not a software toggle. It is a physical device that must be present.

The seed for TOTP codes never enters the credential store. Only the YubiKey slot name is stored — meaningless without the physical device. The device generates the code. The code reaches the portal session directly. No network hop. No external service. No phone. The physical boundary is in the same execution environment as the agent action it gates.

Local Inference Does Not Close This Exposure

This point must be stated precisely because it runs counter to a persistent assumption in the self-hosted AI community.

Local inference — whether via Ollama, vLLM, or any other on-premise LLM runtime — means prompts and completions do not leave the network perimeter. That is a meaningful privacy protection. It does not address what happens on the outbound side of an agent action.

When an agent authenticates to a portal, executes a payment, reads from a credential store, or writes to a client record, those actions travel outbound to external systems regardless of where the model inference ran. The model being local controls data flow into the LLM. It does not control what the agent does with the result. An ungoverned agent running against a local model has exactly the same credential exposure surface as one running against a cloud API — because the risk lives in the action layer, not the inference layer.

Once confidential information exits the infrastructure — through a compromised session, an unscoped credential read, or an agent action that traveled further than intended — the speed of propagation is no longer under the owner’s control. The window between exposure and consequence is measured in minutes, not days. There is no undo button for a breach.

Local inference is a privacy control. It is not a substitute for access governance.

The Break Glass Protocol — Governance Humility

A governing layer that cannot fail is a governing layer that has not been designed for production. Hardware attestation creates a new single point of failure: the physical key. The break glass protocol acknowledges this honestly and designs for the failure deliberately.

The break glass credential is a Vault token with scoped read-only access, printed once, never stored digitally, placed in a sealed physical envelope. Using it requires breaking the seal — a deliberate, visible, auditable act. The break glass path is always harder than the normal path. This is intentional: the friction ensures break glass is used for genuine emergencies rather than for convenience.

The Proxmox console break glass account is a local user that is denied SSH access — accessible only from the physical console. Physical presence at the machine is required. The governing layer requires physical presence to bypass its own physical constraints. That is governance humility: the acknowledgment that the controls can fail, combined with the design discipline to make the bypass more deliberate than the protected path.

The annual renewal reminder in the n8n scheduler — the first Monday of June, generating a Twenty CRM task to verify break glass credentials and confirm secondary key enrollment — is the governance layer maintaining itself. Not a calendar note. An automated governing reminder that produces an auditable task with a completion record.

The Four Harness Positions

The harness is the mechanism that determines where the human sits relative to the agent’s decision cycle. It is not a static setting. It is a calibrated position that changes as the agent demonstrates accuracy and the governing framework matures. The owner, as Product Owner, holds the authority to change harness positions — and every position change is logged in the governing decision record with the rationale.

The four positions are not a technology configuration. They are an amplification architecture. Each position determines how much of the owner’s governing judgment flows into every decision the agent makes — and how much direct owner involvement each decision requires. Understanding the positions in terms of what they do to the owner’s time investment makes the calibration decision meaningful rather than technical.

Above the Loop — Harness A: Rails and Runway

The owner sets the intent, approves the consequential decisions, and reviews outputs before they affect clients or partners. The agent proposes. The human decides. The agent executes the decision.

Above the Loop is appropriate for: any process involving a new or unproven agent capability, any process where a single error could damage a client relationship, any governing decision about the initiative itself (scope changes, charter amendments, harness position changes), and any process where the dual-purpose test classification was customer-serving and the accuracy threshold has not yet been demonstrated.

The owner’s time investment in Above the Loop is highest per decision. The amplification ratio is lowest. This is correct — Above the Loop is the learning position, where the owner is calibrating the governing framework before trusting it to operate with less oversight. The goal of Above the Loop is to produce the evidence that justifies graduating to In the Loop.

In the Loop — Harness B: Staged Gate

The human is present during execution and can intervene in real time. The agent processes and produces output. The human reviews the output before it proceeds to the next stage. The agent does not wait for approval before starting — it waits for approval before completing.

In the Loop is appropriate for: customer-serving processes where the accuracy threshold is being demonstrated but not yet confirmed, complex processes with multiple decision points where the agent’s handling of edge cases is still being evaluated, and any process where the Process Miner has identified a fit signal (process design problem) that is being resolved. While the redesign is in progress, human review at each step is the safety net.

Jupyter notebooks natively implement In the Loop through their cell-by-cell execution model. Every cell boundary is a potential gate. The notebook itself is the audit trail. This is not an approximation of In the Loop. It is the canonical implementation.

On the Loop — Harness C: Async Monitor

The agent operates autonomously within defined policy bounds. The human monitors the event log for exceptions and reviews the Process Miner’s weekly findings. Intervention is triggered by exception, not by routine execution.

On the Loop is appropriate for: internal efficiency processes where the accuracy threshold has been demonstrated across multiple sprint cycles, customer-serving processes where demonstration is complete and the governing framework has been shown to catch errors before they reach clients, and any process where the Process Miner consistently classifies deviations as execution signals (harness problems) rather than fit signals (design problems).

The owner’s time investment in On the Loop is lowest per decision. The amplification ratio is highest. This is the target position for mature, well-governed processes — not because the human has stepped away, but because the governing framework is doing the work that the human was doing manually.

Under the Loop — Harness D: Autonomous Action

The agent acts autonomously without human review. Used exclusively for deterministic, rule-matched tasks where the governing policy completely specifies every possible outcome. Not for tasks that require judgment. Not for tasks where an error has a relationship consequence. Not for any task where the agent is interpreting ambiguous input.

Under the Loop is appropriate for: mechanical data transformations with fully specified rules, scheduled report generation from governed data sources, and TOTP code generation from hardware-attested credentials. These are not AI tasks — they are automation tasks that happen to run in an agent framework. The distinction matters: Under the Loop is not the destination for AI capability. It is the position for deterministic automation that does not require AI.

Harness Position Graduation

Graduating from a higher oversight position to a lower one requires evidence, not intent. The Process Miner’s track record is the evidence. The governing decision record is where the graduation is logged. The owner approves the graduation with a stated rationale: ‘Accuracy threshold of 95% demonstrated across eight sprint cycles on internal efficiency classification. Graduating from In the Loop to On the Loop. Next review in 90 days.’ That is a governing decision. It is logged. It is auditable. It can be reversed if the Process Miner’s findings change.

The Approval Primitive

The await_approval() primitive is the mechanism that makes Above the Loop and In the Loop operationally real rather than aspirationally documented. Without a first-class approval primitive, the harness position is a label on a governance document. With it, the harness position is an enforced constraint on the agent’s execution path.

The primitive is a blocking async Python call. The agent reaches a configured gate point in the workflow. It calls await_approval() with a context payload describing what it is about to do. It blocks. It does not proceed until a human has made a decision. If the human does not decide within the defined window, the agent escalates — it does not self-approve. There is no code path under which the agent resolves its own approval request.

The Six-State Machine

Every approval request transitions through a six-state machine. The states are not labels. They are governing positions, each with defined actions and defined transition triggers.

The Critical Design Constraint

The agent never self-approves under any code path. This is not a configuration setting. It is an architectural invariant. If the approval polling loop exits without a confirmed human decision — timeout, network failure, CRM unavailable, any reason — the agent writes a TIMEOUT_ESCALATE event and halts. Resumption requires a manual human trigger. There is no fallback that allows autonomous continuation.

The Postgres record is the source of truth. The Twenty CRM task is the human-facing interface to that record — not the authoritative state store. If the CRM is unavailable, the Postgres record persists. When the CRM is restored, the task can be acted on and the webhook will update the Postgres record. The governing state does not depend on the availability of the human-facing display layer.

The Webhook Defense Layer

Human decisions in Twenty CRM reach the Postgres state machine through an n8n webhook handler. The handler implements three layered defenses against the failure modes that would allow an unintended state transition.

• HMAC-SHA256 signature verification on all incoming webhooks. A webhook from any source other than the authorized Twenty CRM instance is rejected before the payload is read.

• WHERE status=PENDING idempotency guards on all UPDATE statements. A webhook that fires twice for the same decision — a retry, a duplicate, a delayed delivery — cannot cause a double-state transition. The second update finds the record already in APPROVED or REJECTED state and logs without modifying.

• FOR UPDATE SKIP LOCKED row-level locking to prevent duplicate webhook concurrent writes. Two simultaneous webhook deliveries for the same approval request cannot both execute their UPDATE statements. One locks the row. The other skips and logs.

A webhook_dead_letter table captures all failed webhook events with full diagnostic context. Nothing is silently lost. Every failure is recoverable and auditable.

Process Mining and Signal Classification

Process mining is the analytical discipline that reads what actually happened and compares it to what was supposed to happen. In the managed initiative framework, the Process Miner — NB1 in the companion package — is the mechanism that closes the feedback loop between agent execution and governing framework refinement.

The Process Miner reads the events.operational_log event log, reconstructs the sequence of steps each case went through, and identifies where the actual sequence deviated from the intended sequence for that process type. When it finds a deviation, it asks the diagnostic question that determines the right intervention.

The Diagnostic Question

Is this deviation because the process design is wrong — the policy was miscalibrated, the scope boundary was incorrectly drawn, the harness position was set too high or too low, the governing criteria did not match what reality was actually producing?

Or is this deviation because the execution was wrong — the agent operated outside its scope, the approval was not obtained, the policy rule fired incorrectly, the human reviewer did not act within the SLA?

These are the fit signal and the execution signal. They require completely different responses. Applying the wrong response to the wrong signal compounds the problem.

Fit Signals — Process Redesign Required

A fit signal tells you the process design is wrong. The framework was asking the right question but the wrong question for this situation. The governing criteria produced the wrong outcome consistently — not because the execution was poor, but because the design was wrong.

The correct response to a fit signal is process redesign. Not tightening the harness. Not increasing oversight. Redesigning the process. The harness positions should be moved up (more oversight) while the redesign is in progress, because you are operating a process you know is wrong and you need maximum human review until the redesign is validated. After the redesign, the positions return to their calibrated levels and the Process Miner validates the redesign’s effect over subsequent sprint cycles.

Applying harness tightening to a fit signal produces more consistent wrong outcomes. The agent executes the wrong process more reliably. The error rate may appear to decrease because the agent is applying the wrong policy more consistently — but the outcomes are wrong because the policy is wrong. The Process Miner’s fit/execution classification is what prevents this failure mode.

Execution Signals — Harness Tightening Required

An execution signal tells you the process design is correct but the execution was inconsistent. The governing criteria were right. The policy would have produced the right outcome. Something in the execution path did not follow the policy.

The correct response to an execution signal is harness tightening: identify where the execution deviated, adjust the enforcement mechanism, and validate through the next sprint cycle. Not process redesign. The process is correct. The execution is the problem.

Applying process redesign to an execution signal discards a working design. The redesigned process will be executed just as inconsistently as the original — because the problem was never with the design. The Process Miner’s classification prevents this: you know which intervention is right before you apply it.

The Signal Taxonomy

The Process Miner classifies each deviation from the modal sequence into one of three signal types. The classification is the output of NB1 and the input to NB2 (the Gap Router), which routes each classified gap to the owner for a governing decision.

The Modal Sequence

The Process Miner compares actual sequences to the modal sequence — the intended sequence of activities for this process type, defined in the process-type registry. The registry is the source of truth for what the process is supposed to look like. Every deviation from the modal sequence is a candidate finding. The Process Miner’s job is to classify those findings, not to identify them from scratch. The quality of the classification depends on the quality of the modal sequence definition. A vague modal sequence produces vague classifications. A precise modal sequence — with specific activity names from the controlled vocabulary — produces actionable classifications.

The Continuous Improvement Cycle

The managed initiative is not a deployment. It is a practice. The distinction is the difference between installing a system and building a governing capability. A deployment is an event. A practice is a recurring discipline that produces compounding returns.

The continuous improvement cycle is the mechanism that converts the managed initiative from a deployment into a practice. It runs on a defined sprint cadence — two weeks is the default, adjustable to the initiative’s pace and the owner’s review capacity. Each sprint produces findings. The findings require governing decisions. The governing decisions produce improvements. The improvements produce cleaner signal in the next sprint. The signal compounds.

The Sprint Cycle

NB1 — The Process Miner

Runs at the beginning of each sprint review. Reads events.operational_log filtered by the initiative’s domain and process types. Reconstructs case sequences. Compares to modal sequences. Classifies deviations as fit, execution, or fit+execution signals. Outputs the typed gap inventory for the sprint.

NB2 — The Gap Router

Takes the typed gap inventory from NB1. Routes each classified gap to the appropriate governing decision path. Fit signals route to the owner as process redesign decisions. Execution signals route to the harness position review. Fit+execution signals route to the owner with a structured decision framework. The Gap Router runs the Hermes six-state machine for each gap that requires owner approval. Every gap is classified. Every classification produces a governing action or a documented decision to defer.

NB3 — The Brief Writer

Takes the owner’s approved decisions from NB2. Synthesizes the current backlog state with the sprint’s findings and decisions. Generates the Claude Code handover brief for the next build cycle. The handover brief is not hand-authored. It is machine-generated from the governing decisions the owner made in this sprint. The Claude Code session that follows has precise, current, governing-decision-based build instructions — not stale documentation from three sprints ago.

The Sprint Review

The sprint review is not a status update. It is a governing session. Three questions are asked in every sprint review, in order.

1. What did the system do that it should not have done? This identifies scope violations, harness position overruns, or policy gaps. Each finding requires a governing decision: amend the charter, tighten the enforcement, or log as acceptable deviation.

2. What did the system fail to do that it should have done? This identifies gaps in coverage, capability shortfalls, or process design problems. Each finding requires a governing decision: redesign, extend scope, or log as backlog.

3. Are we still building toward the right thing? This is the direction check. The initiative was chartered to solve a specific problem. Is that still the right problem? Has the business context changed? Has the owner’s understanding of what success looks like evolved? If the answer to this question is ‘no longer certain,’ the correct response is not to continue the sprint cycle. The correct response is a charter review.

The third question is the one most sprint frameworks omit. It is also the most important. An initiative executing well against a direction that has quietly become wrong is an initiative in the Sustained state without having been named as such. The sprint review’s third question makes the direction check mandatory rather than optional.

Kaizen: Encoding the Learning

The continuous improvement cycle produces learnings. The learnings must be encoded — in the policy file, in the modal sequence registry, in the harness position calibration record, in the governing decision log — or they are lost. The next sprint starts from the same position as the previous sprint, and the improvement does not compound.

When NB1 finds a fit signal, and the owner decides to update the governing policy, and that update is made to icp_policy.rego, and the update is logged in the governing decision record with the rationale, and the updated policy propagates to every subsequent evaluation — that is Kaizen applied to the governing layer. Small improvement. Captured. Encoded. Applied consistently going forward. The governing layer gets more precise with each sprint. The signal it carries gets cleaner. The amplification ratio increases.

Governance, Security, and Identity as One Concern

Most organizations treat governance, security, and identity as three separate disciplines with three separate frameworks and three separate implementation workstreams. In an agentic AI system, this separation produces a governing layer that looks complete on paper and fails in practice — because the three disciplines converge at the layer where the framework meets the systems it governs, and separation at that layer produces gaps that no individual discipline can close.

Why They Converge

Governance without identity

A governance record that cannot attribute every action to a specific, verified actor is not a governance record. It is a log. Anyone with access to the event log can write ‘actor_id: don_lovett’ regardless of whether Don Lovett made the decision. The tamper-evident audit trail is only tamper-evident if the identity claims it contains are trustworthy. Identity verification is not an add-on to governance. It is the foundation on which the audit trail’s credibility rests.

Governance without security enforcement

A governing policy that can be bypassed is advisory, not governing. The OPA/Rego policy says agents cannot modify workflow logic. If the Vault credential the agent uses has read-write access to the n8n workflow database, the policy is a document. The security enforcement — scoped credentials, deny-by-default access, hardware-gated modification paths — is what makes the policy operational. Without enforcement, the governing layer reports what should happen. With enforcement, it determines what can happen.

Security without governance context

A security control that does not know what it is protecting or why produces perimeter security without governing intelligence. The firewall that blocks unauthorized access without understanding that the OPA policy has classified certain actions as Above the Loop regardless of authentication status is a security tool, not a governance tool. It correctly blocks unauthorized access and has no basis for evaluating whether authorized access is being used to serve the governing intent or to circumvent it.

The Unified Requirement

The requirement the three disciplines share is: every action in the system must be attributable, bounded by policy, and resistant to forgery. Identity addresses attributability. Security enforcement addresses policy boundedness. Governance provides the policy and the audit trail that makes both meaningful. These are not three separate requirements. They are three expressions of the same requirement.

The practical implication is that the governing layer must be designed as a unified system — not as a governance layer with security bolted on and identity assumed. The event log field actor_id is only meaningful if identity verification ensured the actor was who the record says they were. The OPA policy is only governing if enforcement prevented access to what the policy prohibited. The audit trail is only tamper-evident if security controls protect its integrity.

The Credential Architecture as Signal Integrity

In the managed initiative stack, credentials are stored in Vault rather than in code or configuration files. This is not primarily a security decision. It is a signal integrity decision. When credentials are centrally managed and access is audited, the governance record can answer: which process accessed which credential at what time, and was that access authorized by the current governing policy?

Without central credential management, that question has no answer. A governance record with an unanswerable question about credential access has a gap in its signal — a place where the amplification could be carrying something other than the owner’s governing intent without the governing layer knowing.

The Vault audit log — time=2026-06-21T14:32:07Z type=response accessor=utility-agent/xxxxx path=secret/data/utility/verizon operation=read — is signal integrity at the credential layer. It is the first link in the chain of custody that runs from credential access through agent action through governing record.

The People Layer

The governing layer is architecture. It does not govern itself. It requires the owner — and the people the owner delegates to — to have developed specific capabilities before the architecture can function as designed. The people layer is not a training program layered on top of the technical implementation. It is the human capability development that makes the technical implementation meaningful.

The Product Owner’s Capabilities

The owner’s role in the managed initiative is Product Owner — simultaneously the charter authority, the approval decision-maker, and the Chief Inspector who holds the initiative accountable to its stated governing intent. These are not administrative roles. They require specific capabilities that the governance intake interview and the sprint cycle develop over time.

Making implicit judgment explicit

The governing policies — the ICP criteria, the harness position thresholds, the approval SLA commitment, the scope boundaries — can only be as precise as the owner’s ability to articulate their governing judgment. The owner who knows, intuitively, which client situations require their involvement and which do not has accumulated governing judgment. That judgment must be made explicit before it can be encoded in policy. The governance intake interview is the process that surfaces the judgment. The policy encoding is the process that captures it. The sprint cycle is the process that refines it as reality reveals where the initial encoding was imprecise.

The override logging commitment

Every time the owner overrides an agent recommendation, the governing framework requires a logged rationale. This is not a documentation burden. It is a signal generation mechanism. The override record — what the agent recommended, what the owner decided, why — is the raw material for the Process Miner’s next classification cycle. An override logged with a rationale is a data point that improves the governing framework. An override made without logging is a signal that the framework never receives.

The owner’s commitment to override logging is a commitment to the continuous improvement cycle. Without it, the sprint cycle produces findings without the evidence needed to distinguish a framework problem from an execution problem. With it, every override contributes to the governing layer’s precision.

The Delegation Posture

As the initiative matures and harness positions graduate from higher to lower oversight, the owner’s role shifts from direct reviewer to system governor. The people who operate within the governing framework — the employees who work with the agent’s outputs, the practitioners who run the sprint cycle, the operators who maintain the infrastructure — need to understand not just what the framework says but why it is designed the way it is.

A delegatee who understands the governing principles can handle situations the framework does not cover. A delegatee who only knows the specific rules cannot. The goal of the delegation posture is people who can extend the framework, not merely execute within it. That capability develops through the work — through the sprint cycles, through the override discussions, through the Process Miner’s findings becoming a shared organizational language rather than a technical report that only the owner reads.

Accountability Without Punishment

The sprint cycle produces failures. Agents deviate from modal sequences. Override rates exceed thresholds. Approval SLAs are missed. The governing framework’s response to these failures determines whether the initiative produces organizational learning or organizational anxiety.

The diagnostic response treats every failure as a classified signal. Was this a fit signal — the framework was wrong? Was it an execution signal — the framework was right but not followed? The classification determines the intervention. The intervention is logged. The log is the evidence for next sprint’s calibration. The failure is information that improves the governing layer.

The punitive response converts failures into signals that stop being produced. People stop logging overrides honestly. Practitioners stop surfacing Process Miner findings that might reflect poorly on their execution. The governing layer stops receiving the signal it needs to improve. The initiative drifts into Sustained.

The managed initiative framework requires the diagnostic response. It is not a cultural preference. It is an architectural requirement: the continuous improvement cycle depends on honest signal production, and honest signal production depends on accountability without punishment.

The Receipts

The receipts standard at ProjectBits Consulting states that every capability claim must cite verifiable evidence. A production system. A dated measurement with a before and an after. If the evidence does not exist, the claim does not ship.

The managed initiative framework described in this paper runs on the ProjectBits Consulting business development operations. The BD agent system is the first live managed initiative running through the Paper 9 pipeline. It is not a demonstration. It is the methodology applied to the practice’s own operations, producing the receipts that prove the claim.

The Evidence

The governing policy

The ICP scoring policy for the BD pipeline is encoded in icp_policy.rego — a Rego policy file under version control, reviewed and approved by Don Lovett as Product Owner before any agent code was written. The policy encodes the qualifying dimensions, the deny rules, the confidence thresholds, and the partner type classification rules. Every subsequent triage decision is evaluated against this policy. Not against the agent’s judgment. The policy.

The event log

The events.operational_log table records every step in every BD pipeline contact’s journey. Card capture, enrichment, ICP policy evaluation, Hermes approval request, human decision, track assignment, Apollo sequence trigger. Every step. Every actor. Every timestamp. The event log exists and is queryable. The Process Miner runs against it on the sprint cadence.

The governing decision record

The governance.po_decisions table records every governing decision the Product Owner has made about how the system should behave — every threshold adjustment, every scope boundary clarification, every harness position change, every charter amendment. Every entry has a timestamp, a rationale, and an affected policy reference. The governing decision record is the institutional memory of the initiative — readable by a future owner, auditable by a reviewer, and queryable by the Process Miner.

The Process Miner findings

NB1 has run against the BD pipeline event log. Its findings have been classified as fit signals and execution signals. The Gap Router has routed classified gaps to the owner. The owner has made governing decisions. Those decisions have been encoded in updated policy. The sprint cycle has run. The governing layer has improved.

The Self-Demonstration Claim

The managed initiative framework claims that a business owner can run an AI initiative the way product teams run products — with a governing charter, a calibrated harness, a typed gap inventory, a continuous improvement cycle, and a governing decision record that makes every consequential choice auditable.

That claim is demonstrated, not described, by the fact that the practice building the framework applied it to its own business development operations first. The event log exists. The policy file exists. The governing decision record exists. The Process Miner has run. The cycle has turned.

The methodology is not described. It is operational. The governing layer that this paper describes is running on the practice’s own operations. The receipts are there for anyone who wants to verify the claim against the evidence.

The Implementation Infrastructure

The Finance-Grade AI Advisory Engine: the automated growth engine and secure advisory pipeline — Postgres as the central brain, strict human-in-the-loop guardrails, plumbing-vs-thinking agent separation, and the three-tier ladder from Tax Ready Bookkeeping to CFO reporting to strategic advisory.

The managed initiative framework is not a methodology that requires a separate toolset. The companion package is the toolset built specifically to implement the framework — designed to be operated by a practitioner working with Claude Code, not by a platform engineering team.

The Governance Setup Tool

An interactive JSX component that walks the Product Owner through eleven governance questions sequentially. Each answer is validated by the Claude API before proceeding to the next question. At the end of the interview, the tool produces a completed, signed initiative charter — the governing document that authorizes the initiative to proceed. The charter is not a template filled in. It is the Product Owner’s answers to the eleven questions, synthesized into a governing document that includes the problem statement, the scope boundaries, the harness positions, the approval SLA, the override logging commitment, and the sprint review cadence.

The governance setup tool is the implementation of the product owner initiation interview described in the BD initiative specification. It runs before any agent code is written. It produces the charter that gates everything that follows.

NB1 — The Process Miner

A Jupyter notebook that reads the events.operational_log table, reconstructs case sequences by process type, compares actual sequences to modal sequences from the process-type registry, and produces a typed gap inventory with fit/execution signal classification. Operates in demo mode against synthetic data or live mode against the production Postgres instance. A single MODE = 'demo' | 'live' config cell controls the connection.

NB2 — The Gap Router

A Jupyter notebook that takes NB1’s typed gap inventory and routes each classified gap through the Hermes six-state machine. In demo mode, a mock Hermes implementation simulates realistic approval latency and decision logic. In live mode, gaps route through the production await_approval() primitive to the owner’s Twenty CRM task queue. Produces the hermes audit log with every state transition recorded.

NB3 — The Brief Writer

A Jupyter notebook that takes the Gap Router’s approved decisions and synthesizes the current backlog state into a Claude Code handover brief. The handover brief is the build instruction set for the next sprint’s implementation work. It is machine-generated from governing decisions, not hand-authored. The Brief Writer ensures the build instructions always reflect the current governing state of the initiative rather than the state at the time someone last updated the documentation.

The Streamlit Monitoring Application

A four-page dashboard that provides continuous visibility into the initiative’s governing state. Page one: the live harness position matrix showing every in-scope process and its current harness position. Page two: the Process Miner’s most recent findings with fit/execution classification and disposition status. Page three: the governing decision log showing every charter amendment, harness position change, and policy update. Page four: the Hermes queue showing open approval requests, their state, and their time in state.

The Streamlit app is the operational nerve center of the managed initiative. It makes the governing state visible without requiring the owner to query the database. The override rate, the approval SLA compliance, the harness position graduation track record, and the open gap inventory are all visible from the dashboard without a technical intermediary.

This paper is the ninth in the ProjectBits reading order. Read the series in order at projectbits.com/method. It builds on The Third Perspective (the human discipline behind the harness) and is followed by Signal Clarity. Owner Amplification. (the owner’s strategic frame for governed AI). Its claims are grounded in the first live application of this governance — the ProjectBits business development pipeline.

ProjectBits Consulting · projectbits.com/method · Reston, VA. Tax Ready Bookkeeping™, CFO Operating System™, Financial Maturity Staircase™, and Thought-OS™ are trademarks of ProjectBits Consulting, Inc. This paper is published for practitioner and client education.