AI Deployment Canvas
Module 7 is the AI governance layer of the operating system. It governs every AI component across every other module and determines whether AI deployments proceed, pause, or roll back based on structured scoring and continuous audit.
No other mid-market operating system has a dedicated AI governance module. EOS does not address AI. Scaling Up does not address AI. OKR frameworks do not address AI. This is not a gap they chose to leave. It is a capability category that did not exist when those frameworks were designed. Module 7 was built to reflect the operational reality AI now demands: integration with every other module in the system.
Module 7 receives its primary upstream signal from Module 1's AI Readiness Index. Organizations scoring below 40% start no new AI deployments through Module 7. They must complete foundation work in Modules 2, 3, and 4 first. This is a hard gate, not a recommendation. Module 1 determines whether Module 7 opens. Module 7 determines how AI operates once it does.
Downstream, Module 7 governs AI components in six other modules. These include Module 2's Draft-With-AI workflow, Module 5's churn predictor and QBR deck generator, Module 6's lead scoring and proposal tools, Module 8's scenario modeling, Module 11's turnover risk model, and Module 12's threat detection. Every AI tool appears in Module 7's AI Register with dual ownership, incident logging, and quarterly audit requirements.
Why AI Deployments Fail in Mid-Market Companies
The average mid-market company invests heavily in its first AI initiative. Organizations without structured readiness assessment fail far more often than they succeed. The failures are almost never technical.
Pattern 1: Deploying AI on undocumented processes. A company tries to automate a workflow that exists only in someone's head. The AI model is trained on inconsistent data because the process varies by person. Output quality fluctuates. Trust erodes. The initiative is abandoned. This is why Module 1's process clarity score feeds the AERI gate on Module 7: if Module 2's SOP Codex has not documented the process, Module 7 will not automate it.
Pattern 2: No governance framework. A team deploys an AI tool that works well for six months, then begins producing biased or degraded outputs. Nobody notices because there is no audit cadence. Nobody is accountable because there is no ownership model. The tool quietly damages decisions until someone runs a manual analysis and finds the drift. By then, the damage is measured in months of bad data.
Pattern 3: Shiny object deployment. The CEO reads about AI and mandates adoption. The team selects use cases based on excitement rather than ROI analysis. High-risk, low-readiness projects launch first because they sound impressive. They fail. The organization develops AI skepticism that prevents the practical, high-ROI projects from getting funded.
Module 7 addresses all three patterns through a scoring grid (structured prioritization), a staged deployment pipeline (risk-managed rollout), an AI Register (governance and accountability), and quarterly audits (continuous monitoring).
The Use-Case Scoring Grid
What it does
The Use-Case Scoring Grid evaluates every potential AI project across five dimensions before any resources are committed. This prevents shiny-object syndrome and ensures capital flows to the highest-ROI, lowest-risk opportunities first.
Five dimensions
ROI Potential (1 to 5). Estimated financial or efficiency return. A score of 5 means clear, measurable cost reduction or revenue increase. A score of 1 means speculative or hard-to-quantify benefit.
Data Readiness (1 to 5). Quality and availability of required data. This dimension draws directly from Module 4's Data Quality Monitor. If the integration hub shows data quality issues for the relevant data sources, the readiness score drops.
Data Sensitivity (1 to 5, inverted). Level of personal or regulated data involved. Higher sensitivity means higher risk. A project using anonymized operational data scores 1 (low risk). A project using customer PII scores 4 or 5 (high risk). Every new AI model needs Module 12's Privacy Impact Assessment before go-live.
Error Tolerance (1 to 5, inverted). Consequences if the AI makes mistakes. An email draft assistant that produces a typo: high tolerance, low risk. A financial forecasting model that misallocates capital: low tolerance, high risk. This dimension determines the level of human oversight required.
Implementation Effort (1 to 5, inverted). Practical difficulty including API maturity, data cleaning requirements, and system integration readiness. Module 4's System Inventory provides the raw data for this assessment.
Projects scoring high on ROI and Data Readiness and low on Sensitivity, Error Tolerance, and Implementation Effort rise to the top. The rank is ROI plus Data Readiness plus 6 minus each inverted score. The grid creates a heat map that makes prioritization visual and defensible.
Connection to Module 8
The scoring grid outputs feed directly into Module 8 (Agile Capital Allocation). AI projects that score well enter Module 8's funding pipeline at the appropriate tier. An Exploration-tier AI project can proceed quickly with minimal approval. A Scaling-tier AI project requires gate KPIs from the scoring grid and pilot data before capital is released.
The Pilot-to-Scale Pipeline
Four stages
Stage 1: Sandbox. Isolated testing on historical or synthetic data with zero customer exposure. The team runs the model, measures baseline accuracy, and conducts the initial risk review based on the scoring grid. No production data enters the sandbox.
Stage 2: MVP Pilot. Limited real-world introduction with a small internal team or a tiny fraction of interactions. Human oversight is mandatory at this stage. Every AI output is reviewed before acting on it. Four KPIs are tracked: accuracy percentage, human override rate, cycle time delta, and satisfaction delta.
Stage 3: Controlled Rollout. Gradual expansion (typically 25% of traffic or interactions). KPIs are monitored continuously. A documented kill switch and rollback plan must exist before this stage begins. Only proceed if KPIs meet or exceed defined thresholds from Stage 2.
Stage 4: Full Production. Complete deployment with ongoing monitoring. The model enters the AI Register. Regular audit cycles begin. The quarterly bias and drift audit calendar activates.
Each stage has a go/no-go gate. The gate criteria are defined before Stage 1 begins and locked (consistent with Module 8's gate KPI locking principle). Changing gate criteria after deployment starts requires board-level approval.
How Module 1 controls the pipeline
Module 1's AI Readiness Index determines how fast an organization can move through the pipeline.
Below 40%: Module 7 starts no new AI deployments, and existing models run advisory only. The organization completes foundation work in Modules 2 (process documentation), 3 (measurement baselines), and 4 (data integration) before any AI project enters the sandbox.
40% to 70%: The pipeline operates in supervised mode. Stage 2 (MVP Pilot) requires human review of every output. Stage 3 (Controlled Rollout) operates with monthly accuracy reviews instead of quarterly. Bias audits run monthly.
Above 70%: The pipeline operates at full capacity with standard governance. Quarterly audit cycles apply. Automation is approved at Stage 4 with standard oversight.
This tiered approach means the governance intensity matches the organization's readiness. Companies with strong foundations move fast. Companies with weak foundations build the foundation first. No other operating system ties AI deployment speed to a diagnostic readiness score.
The AI Register
What it does
The AI Register is the central logbook for every AI system in production across the entire VWCG OS. It is the single source of truth for what AI is running, who owns it, what data it uses, and what happened when something went wrong.
Key fields
Each registered AI system includes a unique identifier, description of function, specific model or provider, data sources used, initial risk score from the scoring grid, Model Owner (technical accountability, usually data or ML team), Business Owner (impact accountability, usually the module lead), status (active, paused, or retired), and an incident log.
Current AI deployments across the VWCG OS
The AI Register for a fully deployed VWCG OS includes:
- Module 2: Draft-With-AI SOP generation workflow
- Module 5: Client churn predictor and QBR deck auto-generator
- Module 6: Lead scoring model and proposal generation engine
- Module 8: Scenario modeling engine for capital allocation
- Module 11: Employee turnover risk prediction model
- Module 12: Automated threat detection and anomaly monitoring
Each of these has a dual owner, a risk score, a deployment stage, and an incident history. The Register provides board-level visibility into the organization's AI footprint.
Incident management
The incident log captures date, summary, root cause, action taken, and lessons learned for every AI failure. Quarterly rollups of incident histograms and override trends inform future scoring cycles. The limit is 2 material incidents in 30 days, and a model can be registered with a lower limit but never a higher one. A model that reaches its limit automatically downgrades to Stage 2 (MVP Pilot) with mandatory human oversight until root cause is resolved.
Quarterly Bias and Drift Audits
Why quarterly
AI models degrade over time. The data distribution changes. User behavior shifts. The competitive landscape evolves. A model that was 92% accurate at deployment may be 78% accurate six months later. This degradation happens silently. Without structured audits, nobody knows until the damage is done.
Bias audit methodology
Export a sample of 1,000 predictions. Split error rates by demographic segment, customer size, industry, or geography. Identify whether the model performs significantly worse for any subgroup. If bias is detected, the model returns to Stage 2 for retraining and revalidation.
Drift audit methodology
Compare current quarter accuracy against the baseline established at deployment. Compute a confusion matrix. Compare it to the previous quarter's results. If accuracy has dropped more than 5 percentage points from baseline, the model enters a retraining cycle.
Audit output
A concise two-page PDF audit report, stored in the AI Register, with a summary presented to the board as part of the quarterly governance review. This connects to Module 13 (Core Execution), where the quarterly recalibration cycle includes AI audit review as a standing agenda item.
What makes this different from standalone AI governance
Standalone AI governance frameworks (NIST AI RMF, EU AI Act compliance toolkits, vendor-specific modules) provide solid methodology. They apply horizontally across any organization.
Module 7 is a vertical governance layer embedded in a specific operating system. The difference is integration. A standalone framework tells an organization to audit its AI models. Module 7 tells the organization which models to audit (the AI Register), how readiness affects deployment speed (Module 1 gating), how AI failures route into capital decisions (Module 8 gate KPI impact), how data quality affects model reliability (Module 4 Data Quality Monitor), and how AI-specific adoption challenges are managed (Module 10 Change Enablement Sprint with AI-specific micro-training).
The governance is not a separate initiative. It is a layer of the operating system that touches every module where AI is deployed.
Who This Module Is For
Module 7 was designed for mid-market companies that are deploying or planning to deploy AI, but lack a governance framework that connects AI decisions to the rest of their operations.
These companies have AI tools. Often multiple AI tools, deployed by different teams, with different levels of oversight. Module 7 brings them under a single governance framework that is gated by organizational readiness, funded through structured capital allocation, and audited on a quarterly cadence. The module does not slow AI adoption. It ensures that AI adoption succeeds by connecting it to every other operational discipline in the system.
The Working Specification
The instrument scores five dimensions: Readiness Gate Discipline, Scoring Grid Coverage, Pipeline Stage Control, AI Register Completeness, and Audit Cadence and Response. Weights are version 1.0 calibration defaults from 2026-08-20, tuned to each client during calibration.
The Instrument
The AI Deployment Canvas Diagnostic scores 5 dimensions on a 0 to 5 scale against written anchors. The composite score is a weighted sum with equal weights of 0.20 per dimension. Three standing page rules carry the published thresholds. The AERI gate state locks Module 7 below 40%, runs supervised mode with monthly reviews from 40 to 70%, and allows full capacity above 70%. An accuracy drop above 5 percentage points from baseline enters a retraining cycle. An incident rate at or above 2 material incidents in 30 days auto-downgrades the model to Stage 2 with mandatory human oversight.
| Dimension | Weight | What it measures | Score 1 | Score 3 | Score 5 |
|---|---|---|---|---|---|
| Readiness Gate Discipline | 0.20 | No AI project enters the sandbox while M01 AERI is below 40%. Pipeline mode (locked, supervised, full) matches the current AERI tier. Foundation work routes to M02, M03, M04 when locked | AI deployed regardless of readiness. Gate ignored or unknown | Gate known and mostly honored. Exceptions undocumented | Gate enforced without exception. Mode changes logged with the AERI score that triggered them |
| Scoring Grid Coverage | 0.20 | Every AI project scored on ROI potential, data readiness (M04 monitor), data sensitivity inverted, error tolerance inverted, implementation effort inverted before resources commit. Grid outputs feed M08 tiering | Use cases selected by excitement (the shiny object pattern) | Grid exists. Applied inconsistently. M08 feed manual | No unscored project receives funding. Heat map current. Grid outputs drive M08 tier placement |
| Pipeline Stage Control | 0.20 | Gate criteria defined and locked before Stage 1. Changes require board-level approval. Stage 3 begins only with documented kill switch and rollback plan. Four pilot KPIs tracked (accuracy, override rate, cycle time delta, satisfaction delta) | Projects jump straight to production. No stage evidence | Stages used. Gate criteria loose or changed mid-flight without board approval | Every deployment shows locked gate criteria, stage evidence, kill switch documentation. Zero ungated promotions |
| AI Register Completeness | 0.20 | Every AI deployment across M02, M05, M06, M08, M11, M12 registered with unique id, model and provider, data sources, risk score, Model Owner, Business Owner, status, incident log. Board visibility current | AI tools deployed by different teams with no central record | Register exists. Entries stale or ownership single-sided | Register complete and current. Dual ownership on every entry. Incident logs maintained. Board review happens quarterly |
| Audit Cadence and Response | 0.20 | Bias audits (1,000-prediction sample, subgroup error splits) and drift audits (confusion matrix vs baseline) run quarterly, monthly in supervised mode. Findings trigger Stage 2 return or retraining. Two-page audit PDFs filed. M13 agenda includes audit review | No audits. Drift discovered by accident months later | Audits scheduled. Findings slow to trigger action | Cadence kept without gaps. The 5-percentage-point rule and bias findings trigger documented responses. M13 reviews every audit |
Scoring and Bands
| Band | Range | What it routes to |
|---|---|---|
| Red | 0.0 up to but not including 2.0 | Proposes the owning remediation playbook. Safety routes act on the first reading (Routing table below) |
| Amber | 2.0 to 3.5 inclusive | PB-M07-04 monitoring with 30-day pulse checks |
| Green | above 3.5 up to and including 5.0 | Hold and monitor quarterly through M13 |
The pipeline mode itself follows the published AERI tiers: below 40% locked, 40 to 70% supervised with monthly reviews, above 70% full capacity.
Routing
Red bands fire the routes below. Every amber dimension routes to PB-M07-04. Green dimensions hold and are monitored quarterly through M13. Conditions read the module 0 to 5 bands unless a row names another scale. A color changes only when a score clears the band edge by a margin, or holds for two consecutive scorings. The margin is 0.25 points on 0 to 5 scales and 5 points on the AERI 0 to 100 scale. Safety routes are the routes that set AI mode in any module, the Privacy Impact Assessment rule, or Module 12 classification and response windows. They tighten on the first reading and loosen only after an independent re-score clears the edge. When two routes set the same parameter differently, the most restrictive value wins for safety routes, and the owning module's value wins for every other parameter. A route that fires from a scored dimension is a proposal until leadership confirms it in the M13 Phase 3 review. Routes that fire from measured values and events (PV2, KPI variance, revenue concentration, dates, and logged events) act on the reading. Scorer agreement has not yet passed the reliability test. A proposal is confirmed at the next monthly governance review or the M13 Phase 3 review, whichever comes first, and a playbook's stated duration starts at confirmation. Routes that restore the M13 cadence itself act on the reading. A route that carries evidence feeds the next scoring of the receiving dimension and never sets a score directly. Module instruments are scored quarterly in weeks 11 to 12 of the M13 cycle, Module 1 in Phase 1, and measured signals at their own review cadence. An RT code names the destination action, so several source rows can share one.
Outbound routes
| Signal | Condition | Destination | What fires |
|---|---|---|---|
| Readiness Gate Discipline | red | M07 PB-M07-02 | Scoring Grid and Gate Locking (RT-M07-GATE-RED) |
| Readiness Gate Discipline | red | M02 PB-M02-01 | Below-40 lock routes to foundation work: process documentation |
| Readiness Gate Discipline | red | M03 PB-M03-01 | Foundation work: measurement baselines |
| Readiness Gate Discipline | red | M04 PB-M04-01 | Foundation work: data integration |
| Scoring Grid Coverage | red | M07 PB-M07-02 | Scoring Grid and Gate Locking |
| Scoring Grid Coverage | red | M08 PB-M08-01 | M08 freezes funding for any AI project without a grid score |
| Pipeline Stage Control | red | M07 PB-M07-02 | Scoring Grid and Gate Locking |
| Pipeline Stage Control | red | M12 PB-M12-02 | M12 audits PIA completion for every AI deployment at Stage 2 or later |
| AI Register Completeness | red | M07 PB-M07-01 | AI Register Build (RT-M07-REGISTER-RED) |
| Audit Cadence and Response | red | M07 PB-M07-03 | Audit Cycle Activation (RT-M07-AUDIT-RED) |
| Audit Cadence and Response | red | M13 PB-M13-01 | M13 adds the AI audit backlog to the next Phase 4 agenda |
| Audit result signal | on event | M08 PB-M08-03 | AI failures route into capital decisions via gate KPI impact (RT-M07-AUDIT-M08) |
| Project Data Sensitivity score | >= 4 (grid score 1 to 5) | M12 PB-M12-02 | PIA scope flagged as high-sensitivity: Restricted-tier governance applies from Stage 2 |
| AI deployment launched | on event | M10 PB-M10-01 | M10 runs a calibrated adoption sprint, subject to the M10 materiality threshold |
Dependencies, documented and not routed: M07 pilot KPI tracking reads M03 KPI definitions.
Inbound routes
| Signal | Condition | Source module | What fires in M07 |
|---|---|---|---|
| Data Hygiene | red in M01 | M01 | ML model deployment restricted (PB-M07-02) |
| AERI overall subscore | < 40 (AERI 0 to 100) in M01 | M01 | No new AI deployments in M07. Foundation work in M02, M03, and M04 first (RT-M07-LOCKED) (PB-M07-02) |
| AERI overall subscore | 40-70 (AERI 0 to 100) in M01 | M01 | Supervised pilots only (RT-M07-SUPERVISED) (PB-M07-04) |
| AERI overall subscore | > 70 (AERI 0 to 100) in M01 | M01 | Full capacity, standard governance (RT-M07-FULL) (PB-M07-04) |
| SOP Production Capability | red in M02 | M02 | Draft-With-AI governance state check, manual mode if AERI below 40 (PB-M07-02) |
| Data Quality Monitor Performance | red in M04 | M04 | M07 blocks new deployments that read from sources failing the Data Quality Monitor (PB-M07-02) |
| Churn Predictor Governance | red in M05 | M05 | M07 registers or re-registers the churn predictor and QBR generator with both owners (PB-M07-01) |
| Lead Scoring and AI Governance | red in M06 | M06 | Lead scoring and proposal generator registered with dual ownership and quarterly bias audits (PB-M07-01) |
| Turnover Model Governance | red in M11 | M11 | M07 audits the turnover model within the current quarter (PB-M07-03) |
| Data Classification Enforcement | red in M12 | M12 | M07 holds new deployments that touch unclassified data (PB-M07-02) |
| Compliance Baseline | red in M01 | M01 | Models reading customer personal data run human-in-the-loop while red (PB-M07-02) |
Playbooks
Every playbook follows one lifecycle: open, running, met or missed, escalated, closed. A trigger that arrives while a playbook is open is logged against the open run. An outcome met, with an independent re-score at amber or better, closes the run, and the owner's next queued red opens. An outcome missed at the end of its stated duration escalates to the owner's manager and the next M13 quarter planning agenda. Someone other than the owner re-scores the dimension. Each owner runs at most three red playbooks at once. Further reds queue, ranked by how many modules the red dimension routes into. Safety playbooks (PB-M07-02, PB-M12-02, PB-M12-03) never queue. A red route opens a red playbook. A route that changes a mode, a cadence, or a data feed runs under the module's standing playbook. When a red playbook's outcome is met, any standing duty it set up continues under the standing playbook, which does not count toward the cap. Escalation for a CEO-owned playbook goes to the board.
PB-M07-01: AI Register Build (Register)
Trigger: AI Register Completeness red, AI tools discovered outside governance, or a board request for AI visibility. Also opened by routes from M05 Churn Predictor Governance, M06 Lead Scoring and AI Governance. Inventories every AI system in production or pilot across all modules, from M02 Draft-With-AI to M12 threat detection plus team-level tools. Every entry carries the full field set with dual ownership. The Model Owner holds technical accountability, the Business Owner holds impact accountability, and uncertain incident histories are marked rather than invented. Outcome: every known AI deployment registered with dual ownership and status, board has seen the register, quarterly review calendar set. Owner: AI governance lead with data/ML counterpart, 3 weeks.
PB-M07-02: Scoring Grid and Gate Locking (Gate / Grid / Stage Control)
Trigger: Readiness Gate Discipline, Scoring Grid Coverage, or Pipeline Stage Control red, an unscored project funded, or a stage gate changed mid-flight. Also opened by routes from M01 AERI overall subscore, M01 Compliance Baseline, M01 Data Hygiene, M02 SOP Production Capability, M04 Data Quality Monitor Performance, M12 Data Classification Enforcement. Publishes the five-dimension scoring grid, scores every active and proposed AI project, and freezes new funding for unscored projects. The AERI gate is enforced: locked below 40, supervised 40 to 70, full above 70. Stage-gate criteria lock for every in-flight deployment, and changes need board-level approval. Outcome: heat map current, no unscored project funded, pipeline mode matches AERI, every deployment has locked gate criteria and Stage 3 kill switch documentation. Owner: AI governance lead with CFO delegate for the M08 link, 4 weeks.
PB-M07-03: Audit Cycle Activation (Audit Cadence)
Trigger: Audit Cadence and Response red, audit overdue, accuracy drop suspected, or bias complaint received. Also opened by routes from M11 Turnover Model Governance. Sets the audit calendar: quarterly at full capacity, monthly in supervised mode. The bias audit runs on a 1,000-prediction sample with subgroup error splits. The drift audit runs against the deployment baseline. Response rules apply directly. Bias returns the model to Stage 2. An accuracy drop above 5 percentage points enters retraining. An incident rate at or above 2 material incidents in 30 days auto-downgrades the deployment to Stage 2. Outcome: audit calendar live, first cycle complete with PDFs filed, response rules applied where triggered, M13 agenda and board review updated. Owner: Model Owner per deployment with AI governance lead consolidating, 3 weeks to activate.
PB-M07-04: AI Governance Monitoring (Amber Path)
Trigger: any M07 dimension amber, or green-state standing maintenance. Also opened by routes from M01 AERI overall subscore. Reviews the AI Register monthly for stale statuses, ownership gaps, and unlogged incidents, and adjusts pipeline mode when the AERI tier boundary is crossed. Quarterly rollups cover incident histograms and override trends, audit cadence is confirmed for every deployment, and new proposals must arrive with grid scores before any M08 funding conversation. Outcome: register current, mode matches AERI, rollups produced, no overdue audit, M13 fed. Owner: AI governance lead, standing, with a 30-day pulse check for each amber dimension and green maintenance at the next M13 cycle.
Working templates ship with the module: the AI register, the use case scoring grid, and the bias drift audit report. Template artifacts and full playbook bodies are delivered during an engagement.