Free Illusions in the Boardroom The board-level diagnosis

Illusions of Work The operator manual

Reference

The Diagnostic Toolkit

Five questions for boards, a writer-versus-reader scorecard, a 90-day launch sequence for the first autonomous unit, a glossary of corporate euphemism, and sample process definitions you can lift directly.

Use these pages in a board review, a leadership offsite, or the first week of a unit pilot. They are designed to be lifted directly.

Five questions for the board

For one critical business process, the one that creates the most value or carries the most risk:

1. Can you name it? Not as a product label or a portfolio entry, but as a sequence of activities through which a customer receives value. Claims adjudication, payments processing, customer onboarding, order fulfilment. If the answer requires naming six teams that must coordinate to complete a single journey, the process has no owner.
2. Can someone describe it? In structured terms: states, transitions, decision points, failure modes. Not a slide deck. A description precise enough that a machine could compare it against the running system. If the answer is no, the organisation has never written down how its most important process actually works.
3. Who owns it? A single person accountable for whether the description matches the system’s actual behaviour. If the answer is a committee, a shared responsibility, or “it depends,” nobody owns it.
4. Can you reconcile it? If you gave an AI system the process description alongside the code, would the comparison produce meaningful output? If not, the description is either too vague to test or does not exist.
5. Can you trace investment to outcome? Can you connect the money spent on this process to the outcomes it produces? If the money goes to a department and the outcomes emerge from a process, the connection is invisible.

If management cannot answer these questions for one critical process within 30 days, every AI investment is being layered on top of a system the organisation has never properly inspected.

Writer path vs reader path: a scorecard

Count the marks in each column. If you have more in the Writer column, AI is accelerating your fiction. If you have more in the Reader column, AI is accelerating your operations. Most organisations will have a mix, and the mix tells you where to start.

The first 90 days

Days 1–14: Choose one critical process. Name it. Name the owner. The owner must be a person, not a team, a committee, or a shared responsibility.

Days 15–45: The owner and a small team (one domain expert, one or two engineers) produce a v0.1 process definition. The definition will be imperfect. It should describe states, transitions, decision points, and known failure modes in a structured format. The goal is not perfection; the goal is precision sufficient for a machine to compare against the code.

Days 46–60: Run the first AI synthesis against the v0.1 definition and the codebase. Expect false flags. Expect arguments about what the process actually does. Expect the discovery that the process as documented and the process as implemented diverge in ways nobody anticipated. Each discrepancy is a piece of organisational knowledge that was previously invisible.

Days 61–90: Resolve the first round of discrepancies. Update the definition. Run the synthesis again. Begin establishing contracts with adjacent units: what the process produces, what it consumes, in what format, with what guarantees. The contracts do not need to be comprehensive; they need to be testable.

At the end of 90 days, the organisation will have one process that is defined, owned, reconciled against the system, and connected to adjacent processes through published contracts. The process will not be perfect. The organisation will know more about how that process actually works than it has ever known before. The evidence produced by the reconciliation will either build the case for extending the model or reveal that the model requires adaptation for the organisation’s specific constraints.

Either outcome is more valuable than another transformation programme.

Glossary of corporate euphemism

Sample process definition (skeleton)

A v0.1 process definition for claims adjudication looks like the skeleton below. It is deliberately incomplete. A real definition would include sub-processes, data requirements, contract dependencies, and failure-mode detail. The point is that the skeleton is precise enough to test against the system and short enough to produce in two weeks.

process: claims-adjudication
version: 0.1.3
owner: anna.bergström
unit: claims

states:
  - submitted
  - under-review
  - approved
  - declined
  - escalated
  - settled

transitions:
  submitted -> under-review:
    trigger: automated-triage
    max-duration: 2h

  under-review -> approved:
    trigger: reviewer-decision
    requires: [credit-check, identity-verified]

  under-review -> declined:
    trigger: reviewer-decision
    requires: [decline-reason-code]

  declined -> escalated:
    trigger: timer
    max-duration: 24h
    note: regulatory commitment

  approved -> settled:
    trigger: payment-confirmation
    contract: payments-unit/settlement-api v2.1
    max-duration: 48h

failure-modes:
  - escalation-timer-drift
  - payment-timeout-unhandled
  - duplicate-submission

The definition lives in the repository alongside the code. When the code changes and the definition does not, the weekly synthesis flags the discrepancy. When the definition changes, the synthesis verifies the code matches.

Sample inter-unit contract (skeleton)

A contract between the claims unit and the payments unit looks like the skeleton below. The contract specifies what one unit produces and the other consumes.

contract: claims-to-payments/settlement
version: 2.1
producer: payments-unit
consumer: claims-unit

endpoint: POST /api/settlements
request:
  claim-id: string (required)
  amount: integer (cents, required)
  currency: ISO-4217 (required)
  policy-id: string (required)

response:
  settlement-id: string
  status: [accepted, rejected, pending]
  timestamp: ISO-8601 with UTC offset

guarantees:
  availability: 99.9
  response-time: p95 < 500ms
  format: breaking changes require 30-day notice

monitoring:
  violations detected automatically
  attribution: producer
  escalation: unit leads within 1 business day

When the payments unit changes its response format without updating the contract, the claims unit’s monitoring detects the violation automatically, the attribution is immediate, and the resolution follows without a bridge call. The contract is the mechanism that replaced the meeting.

Unit launch checklist

Before declaring a unit operational, verify each item. If any item is missing, the unit has the vocabulary of autonomy without the substance.

• Process named and bounded (start state to end state)
• Owner named (one person, not a committee)
• Process definition versioned alongside code
• Adjacent contracts published and testable
• Deployment authority held by the unit (no external CAB)
• Data owned locally (not dependent on central warehouse for operational data)
• Hiring and performance authority within the unit
• Budget envelope controlled by the unit
• First AI synthesis scheduled within 30 days
• Discrepancy review cadence set (weekly)
• One outcome metric chosen (e.g., resolution time, cost per transaction)
• One flow metric chosen (e.g., deployment frequency, remediation time)
• Executive sponsor named with explicit charter protection authority
• External regulatory obligations identified and mapped to definition

If fewer than ten of these are checked, the unit is a relabelled team. The charter is decorative. The results will disappoint, and the disappointment will be used as evidence that “the model doesn’t work here,” when the evidence actually shows that the model was never tried.

Free Illusions in the Boardroom How AI Forces Structural Honesty. The board-level diagnosis. Read now →

Illusions of Work AI Has Made Reality Non-Negotiable. The operator manual for CTOs. Read now →

See also: All articles · Illusions in the Boardroom · Illusions of Work