Boards do not want a 30-slide AI strategy update. Boards want a single page that answers four questions: what AI capabilities are we running, where are they sourced from, who owns each one, and how are they performing. The deck-driven AI update; three slides on each major project, a vendor logo wall, a budget rollup; fails this test because it is organized around what the team has been doing, not around what the company is sourcing. It produces interesting reading and bad decisions. The fix is the AI capability map: a single page where rows are capabilities, columns are sourcing today and forward, owner, eval-pass-rate, and monthly cost. One artifact, one page, board-ready, refreshed quarterly. This piece names the rows and columns precisely, shows why each one earns its space, and shows the failure modes the format prevents.
This turns the AI build-vs-buy-vs-hire decision matrix for 2026 into a board-level artifact. The matrix’s seventh principle is that most sourcing decision is re-litigated quarterly; the capability map is the artifact the re-litigation argues from at the board level.
Why one page
A one-page artifact is a forcing function. It is the only constraint that produces the discipline of capability-level thinking; given more pages, most team accumulates project-level detail that the board does not need and cannot use.
The one-page constraint produces three useful effects.
Aggregation discipline. When you cannot have a row per project, you have to aggregate to capability. Aggregation forces explicit thinking about what counts as a capability vs. An implementation detail. “We have nine separate vendor relationships for six capabilities” is a one-page realization that no project-level deck would surface.
Comparability. Many capabilities are visible at the same time, in the same units, with the same column structure. A capability that costs 10x what a peer capability costs is immediately visible; a capability with 30% lower eval pass rate than its peers is immediately visible. The eye does the comparison for free.
Board-readability. A board member who is not in the AI weeds can read the map in 90 seconds and ask informed questions. A board member who is in the AI weeds can read the map in 90 seconds and identify which row needs the next 20 minutes of discussion. Either way, the read does not consume the board meeting; the questions do.
The format is intentionally austere: a markdown table or a single-page PDF, no embedded charts, no logos, no narrative. The narrative belongs in the supporting documents the board can request if needed.
What counts as a capability
A capability is a unit of AI work that produces a specific business outcome and that has, or could have, a single owner. Capabilities are larger than features and smaller than functional areas.
Examples of capabilities at the right altitude:
- Customer support response drafting
- Sales call summarization
- Documentation search
- Code review assistance
- Internal knowledge base Q&A
- Marketing copy generation
- Product analytics narrative generation
- Compliance document review
Examples of altitudes that are wrong:
- Too narrow: “GPT-5 prompt for ticket classification” (this is an implementation detail under “customer support response drafting”)
- Too broad: “AI for marketing” (this is a functional area; it spans multiple capabilities each with different sourcing)
A useful test: can a single owner be named credibly for the capability? If yes, the altitude is right. If the answer requires committee, the capability is too broad.
Most mid-market organizations end up with 8-15 capabilities on the map. Larger organizations may have 30-50. Anything under 5 is suspicious (capabilities are being aggregated past usefulness); anything over 80 is suspicious (project-level entries are sneaking in).
The detail on capability-portfolio thinking is in the AI capability portfolio: thinking like a CIO not a project manager; that piece argues for the portfolio frame; this piece is the one-page artifact that operationalizes it.
Column 1: current sourcing
Current sourcing names the verb that describes how the capability is sourced today: build, buy, hire, or compose.
- Build means the capability is implemented primarily by in-house engineering, against foundation model APIs but with the orchestration and evals owned in-house.
- Buy means the capability is delivered primarily by a vendor product (the vendor owns the orchestration, the prompts, and often the evals).
- Hire means the capability is delivered primarily by humans, with AI tooling as accelerant rather than substitute.
- Compose means the capability is a deliberate mix; buy the rails, build the moat, hire the judgment. This is the matrix’s eighth principle made operational.
The verb has to be chosen, not hedged. “Build with some buy components” is not a valid entry; it indicates the team has not decided which verb dominates. Force the choice; the resulting clarity is itself useful.
The current-sourcing column also notes the primary vendor where applicable: “buy (Vendor X)”, “build (OpenAI + in-house orchestration)”, “compose (foundation: Anthropic; orchestration: in-house; evals: in-house)”.
Column 2: forward sourcing
Forward sourcing names the verb the capability should be sourced under in the next 12 months. It is allowed to differ from current sourcing; that difference is the value the column adds.
When forward differs from current, the row is by definition a candidate for change in the next quarterly review. The accumulating list of “current ≠ forward” rows is the decision queue for the next portfolio review.
When forward equals current, the row is reaffirmed. Reaffirmation is itself a decision; it carries the implicit claim that the team has considered alternatives and chosen to maintain.
The column should rarely be left blank. A blank entry indicates the capability has not been thought about at the sourcing level, which is the opposite of what the map exists for. Blanks are corrected before the map is presented to the board.
Column 3: owner
Most capability has exactly one owner; a named individual who is accountable for the capability’s performance, cost, and sourcing. The owner is typically a director-level engineering or product leader, occasionally a senior IC.
The owner column resolves three failure modes.
Orphaned capabilities. Capabilities without an owner drift in quality and cost because nobody is on the hook. The map exposes the orphans by demanding a name; orphan rows trigger the assignment of an owner before the map ships to the board.
Owner overload. A single owner with five rows is a signal of capability misallocation. The owner column makes the load visible; the org chart conversation can then happen explicitly.
Owner-misalignment with sourcing. A “build” row whose owner is in procurement is a category error. A “buy” row whose owner is a deep-stack engineer is also a category error. The column makes the alignment visible.
The owner is named at director or VP level for board-readability. The actual day-to-day work may be done by a smaller team; the owner is who the board would call if something is wrong.
Column 4: eval pass rate
Eval pass rate is the percentage of the capability’s eval set that the production system passes on the most recent run, expressed as a single number with the date of the run.
The format is “92% (2026-04-15)”. The date matters because eval pass rate without a date is uncomparable across rows.
The pass rate is a single number, not a band, because boards process single numbers. The supporting documentation (which evals were run, what scoring functions were used, what the historical trend is) lives in the eval product and can be requested.
For capabilities where evals do not yet exist, the cell reads “no evals”; which is itself a finding. A “no evals” entry on a build or compose row is a violation of the matrix’s fifth principle and triggers an action item to remediate.
For capabilities where evals are partial; they cover the most common cases but not the long tail; the cell shows the pass rate on the partial set with a note: “92% (partial; 60% case coverage)”. The note is what keeps the cell from being misleading.
The detail on eval scoring is in why AI agencies need a chief evaluation officer before a chief AI officer; that piece argues for the eval-officer role that owns the methodology behind the column.
Column 5: monthly cost
Monthly cost is the many-in monthly run-rate for the capability, expressed as a single dollar number.
Many-in means: foundation model API spend, vendor product license fees, vendor pass-through fees, allocated infrastructure (compute, storage, vector index), and allocated headcount cost for engineers spending more than 25% time on the capability. It does not include the original build cost (that is in the project budget); it does include the ongoing maintenance.
Monthly cost is the column boards spend most time on, and rightly so. It is the column that makes the sourcing decision financial. A “build” row at $80K/month is reasonable; the same row at $400K/month is suspicious; the same row at $1.2M/month is a board escalation.
The column also enables ratios that make capabilities comparable: cost per active user of the capability, cost per business outcome (e.g., cost per support ticket resolved by the AI capability). Ratios may live in the supporting documents; the headline number lives on the map.
The detail on AI inference cost as the new database cost line is in why AI inference cost is the new database cost line; that piece argues for the cost-discipline frame that this column makes operational.
What the map does and does not show
The map shows: capabilities, sourcing decisions, owners, performance, cost. Five columns, one page.
The map does not show: project status, sprint outcomes, vendor relationship history, regulatory commitments, organizational design rationale, or detailed financial projections. These belong in supporting documents.
The map is not a replacement for those supporting documents. It is the entry point. A board member who reads the map and wants more detail on a row asks for the supporting document on that row. The supporting documents are produced on demand; they are not pre-circulated.
The discipline is: the map is the single artifact that travels to the board. The supporting documents are deeper but optional. This forces the map to be self-sufficient as a prompt for board questions.
Failure modes the format prevents
The capability map prevents several characteristic failure modes of unstructured AI updates.
Vendor-logo-wall syndrome. A deck slide of vendor logos with project counts under each. Looks impressive; communicates nothing about portfolio shape, performance, or cost. The capability map replaces the logo wall with a sourcing column that ties each vendor to a specific capability and the cost of that capability.
Project-status creep. A deck of three-slide-per-project status updates. Communicates activity but not direction. The capability map replaces project status with capability status, which is what the board is trying to govern.
Cost-as-rolled-up-line-item. A budget line that says “AI infrastructure: $X” and rolls everything up. The capability map breaks the line out per capability, which is what makes per-capability decisions possible.
No-owner-named. A deck where AI is “the AI team’s responsibility” without further attribution. The capability map demands a named owner per row, which is what makes the board’s questions actionable.
Vibe-based eval reporting. A deck where eval results are a single qualitative slide (“the model is performing well”). The capability map demands a single number per row with a date. The number can be argued; the missing number cannot.
Frequently asked questions
How long does it take to build the first map?
A first map takes 2-3 weeks of part-time work for an organization with 10-20 capabilities. The bottleneck is usually agreeing on what counts as a capability, not filling in the cells.
Who owns the map?
The Chief AI Officer (or equivalent role) owns the map. The CFO co-signs the cost column; engineering co-signs the eval column.
How often does it update?
Cells update continuously as data refreshes; the formal map version is published quarterly aligned with the portfolio review.
Should we include capabilities we are considering but not running?
No. A planning document for considered capabilities is a separate artifact. The capability map is for capabilities that exist in production today.
What if a capability spans multiple business units?
Pick the BU with primary ownership. The other BUs are users of the capability; they appear as users, not owners.
How does this compare to a vendor inventory?
A vendor inventory lists vendors with capabilities under each; the capability map lists capabilities with vendors under each. The two are complementary; for board purposes the capability frame is the right primary axis.
What about capabilities without evals?
The “no evals” entry is a finding. Capabilities without evals are typically buy or hire rows where the team has accepted the vendor’s claims about quality. The map exposes this acceptance for board scrutiny.
Should the map show capabilities we are retiring?
Yes, with a “retiring” annotation in the forward sourcing column. The retirement appears once on the map and disappears the following quarter when retirement is complete.
How does this connect to the matrix?
The matrix gives the principles; the map encodes their application. Most row’s sourcing decision is implicitly a principle application; the forward column tracks principle application that has not yet executed.
How does this connect to the portfolio review?
The capability map is the primary input to the portfolio review. Most row where current ≠ forward is a candidate for the kept/changed/retired decision in the review.
Key takeaways
The AI capability map is a one-page artifact with rows for capabilities and five columns: current sourcing, forward sourcing, owner, eval pass rate, monthly cost. The format is intentionally austere; the constraint to a single page produces aggregation discipline, comparability, and board-readability.
Capabilities are at the altitude of “customer support response drafting” or “documentation search”; larger than features, smaller than functional areas, with a single namable owner. Most mid-market organizations end up with 8-15 capabilities on the map; deviations from this range are diagnostic.
The forward-sourcing column is the value-add. When forward differs from current, the row is a decision candidate for the next portfolio review. When forward equals current, the row is reaffirmed. Blanks are not allowed; a blank means the row has not been thought about at the sourcing level.
The map prevents vendor-logo-wall syndrome, project-status creep, rolled-up cost lines, orphaned capabilities, and vibe-based eval reporting. The discipline is in the format constraints; the format constraints are in service of the board’s actual job, which is to govern the sourcing portfolio rather than to read project updates.
Arthur Wandzel
