Lesson 1 · Clear the AI noise

Clear the AI noise

Length: 20 minutes across 7 sections
You will be able to apply: The Constraint First Pass · The Two-Week Proof
You will produce: Commit Statement
You will work: 5 gated questions

Personalize the practice

Apply this to your environment

These details adapt the application prompts and coach questions. They do not affect your score.

RoleSectorOrganization sizeAI maturity

Reading

Which of the hundred things AI could do for this business is the one thing worth governing first?
Core question

classification

Sort the first AI pitches before you open a trial

Required practice

Jo Halvorsen, Ruth Ainsworth, and Gina Marchetti are all hearing persuasive AI ideas at once. Before reading the lesson, sort each pitch by what deserves attention now versus what should wait or be ignored.

OmniCorp Studio drafts internal meeting summaries from transcript notes, with Sam Oduya reviewing every summary before filing.OmniCorp Ledger uploads real client documents into a free trial so it can auto-draft month-end client letters before the practice has checked the contract terms.OmniCorp Trades wants an AI scheduling assistant to sequence daily jobs, but the task may include private home addresses and entry details unless the data boundary is redesigned first.A vendor promises one assistant that will handle proposals, scheduling, bookkeeping, and customer complaints for every team by next month, but cannot name a metric for any one problem.

Complete each part before committing.

Every small business owner with a browser open has been told, repeatedly, that AI will transform their industry. The signal embedded in that noise is narrow: most of what AI can do for an eleven-person agency or a twenty-two-person bookkeeping practice does not matter yet, because the business has neither the volume nor the margin to absorb the cost of getting it wrong. What matters is finding the one decision where the payoff is real and the blast radius is contained, and starting there.

Starting anywhere else is expensive in a unit small businesses feel immediately: the owner's time. An owner who spends six weeks evaluating four tools has spent six weeks not solving the problem the tool was meant to address. The discipline is not adoption. The discipline is selection under constraint.

Next: The pathology: Tool Tourism

Section 2 of 7

The pathology: Tool Tourism

Watch a small business engage with AI for the first time and you will see the same pattern in nearly every case. Someone reads an article, signs up for a trial, runs one impressive demonstration, and moves on to the next trial. Six weeks later the business has four dormant accounts, no policy, and no measurable outcome. The owner cannot say what problem was solved because no problem was named before the tool was chosen.

PrincipleTool Tourism is the reflex of selecting AI tools before articulating the business problem they are meant to solve, in a pattern that reliably produces breadth of experimentation and zero depth of result. It is not laziness. It is the ordinary human response to abundant novelty under time pressure, operating on a surface where every vendor makes the first ten minutes compelling. The tell is a growing list of trials and a stable list of unresolved problems.

The counter is a constraint that forces the business problem to be named, bounded, and measurable before any tool is considered.

Next: The Constraint First Pass

Section 3 of 7Framework

The Constraint First Pass

Definition

Before evaluating any AI tool, write down four things: the business problem in one sentence, the metric that would prove the problem is smaller after intervention, the data the task touches, and the person who will review the output. If any of the four is missing, the pass fails and no tool evaluation begins. This is a gate, not a suggestion.

The pass is deliberately incomplete. It does not evaluate vendors, weigh features, or estimate ROI. It exists to prevent Tool Tourism by requiring that the problem be real and bounded before anyone opens a browser tab.

When to Use It

Run the pass before any new AI tool evaluation, before renewing a trial that has not demonstrated value, and before expanding an existing tool to a new task. The pass takes ten minutes on paper. Skipping it costs weeks of undirected experimentation.

Do not use the pass to evaluate tools you already operate against a measured outcome. Those tools have already cleared the gate. The pass exists for the moment of entry, not for ongoing review.

How to Apply It

Write the business problem in one sentence. If it requires two sentences, it is two problems.
Name the metric that moves. Hours saved per week, error rate on a named output, or days to complete a named process.
State the data category the task touches: public only, internal only, confidential, or regulated.
Name the person who reviews outputs before they leave the team. A name, not a role.

If you cannot complete all four lines, stop. The problem is not ready for a tool. It may not be ready for a solution at all.

Interactive modelConstraint First Pass sequenceflow · 4 elements

Business problem

A single sentence naming what the business needs solved.

Each gate must be completed before any tool evaluation begins.

Business problem: A single sentence naming what the business needs solved.
Metric: The number that proves the problem shrank after intervention.
Data category: The sensitivity ceiling that governs which vendors are permissible.
Named reviewer: The person who approves every output before it leaves the team.

Worked example 1 of 3

Jo Halvorsen at OmniCorp Studio wanted to reduce the time her team spent writing internal meeting summaries. She completed the pass before evaluating any summarisation tool.

Constraint	Answer
Business problem	Account managers spend 45 minutes per meeting writing summaries that are read once and filed.
Metric	Minutes per summary, measured weekly across the team.
Data category	Internal only. Summaries reference project names and timelines but no client confidential data.
Reviewer	Sam Oduya, studio manager, reviews every summary before it is filed.

The pass took eight minutes. It ruled out tools that required client data access before Jo opened a single vendor page. That constraint, which would have emerged three weeks into a trial, was visible before the trial began.

Why This Works

The pass works because it converts a vague intention into a testable claim before any tool can distract from the question. A named metric prevents success from being redefined retroactively. A named data category prevents scope creep into sensitive territory. A named reviewer prevents the output from reaching anyone without human verification.

For a small business, the cost of Tool Tourism is not the subscription fees. It is the owner's attention, which is finite and irreplaceable. The pass protects attention by making the cost of proceeding without clarity visible at the moment it matters.

Worked example 2 of 3Optional depth

Felix Nnamdi at OmniCorp Ledger proposed using AI to draft month-end client letters. Ruth Ainsworth asked him to complete the pass. Problem: senior bookkeepers spend two hours per client writing letters that follow a predictable structure. Metric: hours per letter. Data category: confidential, because the letters reference account balances and tax positions. Reviewer: Ruth herself, before any letter leaves the practice. The data category flagged a constraint immediately: no tool that trains on uploaded content would be permitted. Felix found that constraint in ten minutes rather than after a three-week pilot with client data already in a vendor's system.

Worked example 3 of 3Optional depth

Gina Marchetti at OmniCorp Trades was asked by a field technician to trial an AI scheduling assistant. She ran the pass. Problem: dispatch takes forty minutes each morning to sequence jobs by travel time. Metric: minutes to produce the daily schedule. Data category: internal, covering technician availability and site addresses but no customer financial data. Reviewer: Wes Corrigan, dispatch lead. The pass surfaced an immediate question: site addresses might include private residences under contract. Gina reclassified the data category to confidential and added a retention constraint before any tool was evaluated.

Edge Cases and NuancesOptional depth

The pass does not guarantee a good outcome. It guarantees that a bad outcome is traceable to a bounded decision rather than to drift. When a problem genuinely requires two tools, run the pass twice, once for each problem, because combining them hides which metric belongs to which intervention. When the metric is qualitative rather than quantitative, force a proxy: fewer revision rounds, fewer escalations, or shorter time to a named deliverable. If no proxy exists, the problem is not measurable enough to govern.

A pass that names public data is not permission to skip all caution. Public data can still produce reputational harm if the output is wrong and published under the business name. The pass constrains scope; it does not replace judgment.

Knowledge check

A team member wants to trial an AI tool but cannot name the metric that would prove it works. According to the Constraint First Pass, what should happen next?

Answer first, then check.

Next: The Two-Week Proof

Section 4 of 7Framework

The Two-Week Proof

Definition

After the Constraint First Pass clears, run the tool for exactly fourteen calendar days against the named problem, measuring only the named metric, with only the named reviewer approving outputs. At the end of fourteen days, answer one question: did the metric move in the direction claimed? If yes, continue. If no, stop. No extensions, no pivots, no redefinition of what the tool was meant to do.

The proof is deliberately short. Two weeks is long enough to gather a signal and short enough that stopping costs almost nothing. A three-month pilot with no decision gate at two weeks is not a pilot. It is adoption by inertia.

When to Use It

After the Constraint First Pass has been completed and a specific tool has been selected for trial. Not before. The Two-Week Proof assumes a bounded problem, a metric, a data category, and a reviewer are already in place. Without those, the proof has nothing to measure.

Also use it when expanding an existing tool to a new use case. The tool may be proven for one problem and unproven for the next. Each new application gets its own proof.

How to Apply It

Set the start and end dates before the trial begins. Write them down.
Record the baseline metric on day one. If you do not know the current number, measure it for one day before starting.
Run the tool on the named task only. Do not expand scope during the proof.
On day fourteen, compare the metric to baseline. Report the number, not a feeling.
If the metric improved, document the result and continue. If it did not, stop the tool and close the account.

Interactive modelTwo-Week Proof escalationladder · 4 elements

Constraint First Pass complete

Problem, metric, data category, and reviewer are documented.

Each rung is reached only if the previous condition holds.

Constraint First Pass complete: Problem, metric, data category, and reviewer are documented.
Baseline recorded: The current-state number is measured before the tool starts.
Fourteen-day window runs: The tool operates on the named task only, reviewed daily.
Decision gate: Metric compared to baseline; continue or stop, no extensions.

Worked example 1 of 3

Jo Halvorsen at OmniCorp Studio ran a Two-Week Proof on an internal meeting summariser. Baseline: 45 minutes per summary. Sam Oduya reviewed every draft. On day fourteen, the average was 18 minutes per summary, including review time. The metric moved. Jo continued the tool and documented the result. No client confidential data entered the system at any point because the Constraint First Pass had excluded it before the trial began.

Jo Halvorsen: The average is down to eighteen minutes including Sam's review. That is the number.
Sam Oduya: I rejected two summaries in the fortnight because they hallucinated a deadline we never discussed. Both caught before filing.
Jo Halvorsen: So the failure mode is visible and contained. We continue, same rules, same reviewer.

Why This Works

Two weeks removes the two forces that keep failed tools running: sunk cost and optimism. A fortnight is not enough time to build emotional attachment to the tool or financial attachment to the subscription. The fixed end date makes stopping a scheduled event rather than an admission of failure.

For a small business, the cost of a failed three-month pilot is not the subscription. It is the hours the owner spent configuring, troubleshooting, and defending a tool that never moved the number. Two weeks caps that cost at fourteen days of attention.

Worked example 2 of 3Optional depth

Hana Adeyemi at OmniCorp Provisions trialled an AI tool to draft product descriptions for the wholesale catalogue. Baseline: Miguel Sarto spent three hours per week writing twenty descriptions. After two weeks, Miguel spent two hours per week, but four descriptions required rewriting because the tool invented nutritional claims not on the supplier data sheet. The metric moved in the right direction, but the failure mode — invented claims on food products — was a regulatory concern. Hana continued the tool with an added constraint: Miguel verifies every nutritional statement against the supplier sheet before publishing.

Worked example 3 of 3Optional depth

Dr. Ilse Bergmann at OmniCorp Clinic trialled an AI tool to draft appointment reminder messages. Baseline: Tomas Petrik spent 90 minutes per day on reminders. After two weeks, 70 minutes. The metric moved, but barely. Tomas reported that the tool generated clinically appropriate language only 60 percent of the time, and the remaining 40 percent required full rewrites. Dr. Bergmann stopped the tool. Twenty minutes saved did not justify the cognitive load of verifying every message, and the risk of a clinical term reaching a patient unchecked was not proportionate to the gain.

Edge Cases and NuancesOptional depth

Some metrics cannot produce meaningful data in fourteen days because the volume is too low. A task performed once a month cannot be measured in a fortnight. In that case, extend to the minimum period that produces three instances of the task, but never beyond sixty days without a decision gate. The principle is the same: fix the window, measure the metric, decide.

A tool that moves the metric but introduces a new failure mode, as at OmniCorp Provisions, is not a simple pass. The owner must decide whether the failure mode is governable. If it is, add the constraint and continue. If it is not, stop. Do not redefine the metric to exclude the failures.

Knowledge check

After fourteen days, a tool has reduced task time by five minutes but has introduced incorrect data into two outputs that reached a client. Is this a pass or a fail?

Answer first, then check.

Interactive modelTool Tourism versus governed adoptioncontrast · 2 elements

Tool Tourism

Tool chosen first; problem discovered retrospectively; no metric; no fixed end date.

The difference is whether the problem or the tool comes first.

Tool Tourism: Tool chosen first; problem discovered retrospectively; no metric; no fixed end date.
Governed adoption: Problem named first; metric set before trial; fixed window; decision made on evidence.

Decision point

A team member at OmniCorp Studio asks Jo to extend a Two-Week Proof to four weeks because the tool seems to be improving and two weeks is not enough data. The metric after fourteen days shows no improvement over baseline. What should Jo do?

Write your answer before you continue

Confidence before seeing the analysis

What evidence or assumption could change your decision?

Commit, calibrate, and name contrary evidence first.

Decision point

Ruth Ainsworth at OmniCorp Ledger completed a Constraint First Pass for AI-assisted tax research summaries. The data category is confidential. A vendor offers a free trial that requires uploading sample client documents to configure the model. Should Ruth proceed with the trial?

Write your answer before you continue

Confidence before seeing the analysis

What evidence or assumption could change your decision?

Commit, calibrate, and name contrary evidence first.

Next: Common Failure Modes

Section 5 of 7

Common Failure Modes

Failure modeThe wandering pilot. What it looks like in the moment: the tool is being used for a different task than the one named in the Constraint First Pass, because someone discovered a feature during the trial and redirected it. The cost when this happens: the original metric is never measured, the new use has no baseline, and the business cannot say whether the tool solved anything. The correction: one pass, one tool, one metric. New uses get their own pass.

Failure modeThe indefinite trial. What it looks like in the moment: the free trial expired, the business is now paying, and nobody scheduled the day-fourteen decision. The subscription renews monthly because cancellation requires someone to declare failure. The cost when this happens: twelve months of subscription fees, which in a small business is the equivalent of a junior hire's training budget, spent on a tool that never proved value. The correction: put the decision date in the calendar before the trial starts and treat it as a meeting, not a reminder.

Failure modeThe missing baseline. What it looks like in the moment: the team starts the trial without measuring the current state, so on day fourteen the only comparison is a feeling that things are faster. The cost when this happens: the decision to continue or stop is made on impression rather than evidence, which means it is made on enthusiasm, and enthusiasm decays differently from value. The correction: measure the baseline on day one. If you cannot measure it in a day, spend one day measuring before you start the tool.

Failure modeThe scope leak. What it looks like in the moment: the tool was approved for internal summaries and is now being used for client-facing proposals, because it works well and the team trusts it. The data category has shifted from internal to confidential without anyone updating the constraint. The cost when this happens: a data governance incident discovered after the fact, when client material is already in a vendor system without contractual cover. The correction: any expansion to a new task triggers a new Constraint First Pass. Trust in the tool is not permission to widen its scope.

Failure modeThe redefined metric. What it looks like in the moment: the named metric did not move, so the team reports a different benefit that was never in the pass. The cost when this happens: the business adopts a tool that did not solve the stated problem, justified by a benefit that was never measured against a baseline. Future decisions inherit this standard of evidence. The correction: if the metric did not move, the tool did not work for this problem. A new benefit is a new problem and requires its own pass.

Next: The pass end to end

Section 6 of 7

The pass end to end

Jo Halvorsen at OmniCorp Studio heard from three different account managers that meeting summaries took too long. She did not open a vendor page. She completed the Constraint First Pass: problem, internal meeting summaries take 45 minutes each. Metric, minutes per summary. Data category, internal only, no client confidential data. Reviewer, Sam Oduya.

The pass immediately excluded any tool requiring access to client project files or email threads. Jo evaluated two summarisation tools that operated on meeting transcripts alone. She selected one and set a Two-Week Proof: start date Monday, end date fourteen days later, same metric, same reviewer.

During the proof, Sam reviewed every summary before filing. He caught two hallucinated deadlines, corrected them, and recorded the errors. On day fourteen, the metric was 18 minutes per summary, down from 45. The tool passed. Jo documented the result, the failure mode observed, and the constraint that remained in place: no client confidential data enters the system, and Sam reviews every output.

Three weeks later, an account manager asked whether the tool could draft client proposals. Jo did not expand the existing approval. She ran a new Constraint First Pass. Problem: proposals take four hours. Metric: hours per proposal. Data category: confidential, because proposals reference pricing, strategy, and client objectives. Reviewer: Jo herself. The data category was different. The reviewer was different. The constraints were different. The tool might be the same, but the approval was not.

Mark the level that describes you today. Nothing is submitted.

Behaviour	Ready	Developing	Not yet
Completing the Constraint First Pass	Given OmniCorp Studio's meeting-summary problem, writes all four constraints before evaluating any tool and uses them to exclude vendors that require confidential data.	Writes the problem and metric but evaluates tools before naming the data category or reviewer.	Opens vendor pages and signs up for trials before writing any constraint.
Running the Two-Week Proof	Sets the start and end dates in advance, measures the baseline on day one, and stops the tool on day fourteen if the metric has not moved.	Runs the proof but extends the window when results are unclear rather than making a decision at the agreed date.	Starts using the tool with no fixed end date and no baseline measurement.
Containing scope	When a new use case arises during or after the proof, runs a separate Constraint First Pass for it rather than extending the existing approval.	Recognises the scope expansion but permits it temporarily while planning to formalise it later.	Expands the tool to new tasks because it performed well on the original one, without updating constraints or data categories.

Next: Commit

Section 7 of 7

Commit

Commit Statement

Complete every line in your own words, then sign and date it. Attach your completed Constraint First Pass for the problem you will address first.

I commit to

I will stop

I will start

I will know I succeeded when

Signed Date

Window	Field application
Days 1 to 7	Complete the Constraint First Pass for one AI problem you are currently considering. Write all four lines before evaluating any tool.
Days 8 to 21	Run a Two-Week Proof on the tool you selected. Measure baseline on day one and record the metric daily.
Days 22 to 30	On the decision date, compare the metric to baseline and make the continue-or-stop decision in writing. If a new use case has emerged, run a separate pass for it.

Knowing which problem to solve first and proving that your solution works are the entry points. The next stage of the program develops the capability to set a data boundary that your whole team can follow without interpretation: one page, one rule, no ambiguity.

DisclaimerGeneral guidance only. All organisations and people named in this lesson are fictional. Regulated organisations should confirm requirements with a qualified professional before relying on this material.

Required practice must be complete.

Learner feedback

Did this change what you can do?

What will you use at work?