Skip to main content
SWStudyWalks Search

Introducing an AI Feature Safely

The narration between entries paraphrases; it never reads an entry aloud before the entry plays. Every entry in this lecture plays exactly as it does on its own page — same file, same speed, nothing laid over it.

What you can do after this

  1. Say where AI drafts and where people decide, and choose between suggesting and automating
  2. Take an AI feature through the book's checklist and its Gold Thing Safety Checklist
  3. Start a new initiative with its AI boundaries set, and spot a feature that is not ready

What it covers

18 entries in 3 topics. Each number links to that entry on its own.

  1. 1. Drafting and deciding

  2. 2. The feature checklist

  3. 3. Starting well, and three features

Check yourself

What early choice does the book's checklist ask of every AI feature?

Whether it suggests to a person who decides, or automates a change directly.

Which sentence about purpose do teams usually leave out?

What the feature is not for.

According to the book, what does it mean if several safety-checklist answers are no?

The team is flying blind.

Why does the AI-boundary step come last when starting an initiative?

It depends on the Gold things, which earlier steps identify.

In the workspace example, what had nobody listed?

That the feature wrote a summary field onto the Workspace.

Lecture transcript

The narration as recorded, in order. Where an entry plays, the transcript links to it rather than reprinting it — the entry plays from its own file, unaltered, and says the same thing on its own page.

This is Unit Three of Leading AI at Work, on introducing an AI feature safely. Unit Two closed on a pilot that leaves a few things defined well. This unit asks what happens when a team wants to add an AI feature on top of those things. Carry one question through this lecture: where does the risk of an AI feature actually live? The answer arrives with a feature that worked and was still not ready. By the end you will be able to say where AI drafts and where people decide. To take a feature through the book's checklists. And to start a new initiative with its AI boundaries set.

Five entries on what the book's case shows about AI's role, and the first choice any feature makes.

Where AI earned its place.

LAI 051 Where AI Helped in the Case

The M-CaReM-AI method, by J. R. Carver, lists where AI helped most in its hospital case: drafting candidate things from policy, suggesting fields and rules, assembling draft Packs, writing training summaries, drafting first matrices, and generating scenarios for workshops. Every one was drafting work a person then checked.

Where AI was kept back.

LAI 052 Where AI Was Not Allowed to Lead

AI was not allowed to lead on defining policy rules without human checks, deciding which incidents are reportable, setting core definitions, or overriding human disagreement with generic best practice. The pattern held throughout: AI drafted, and people decided anything carrying meaning or accountability.

When the tool made things up.

LAI 053 Mistakes That Stood Out

When the case's tool confabulated, the mistakes stood out because the team had a frame to check against: an invented risk-score field, an oversimplified lifecycle, and the over-general reporting rule covered in The M-CaReM-AI Method, lesson two hundred five. Without Packs, cards and validation, each would have looked reasonable.

The first design choice.

LAI 054 Suggest or Automate

The book's checklist asks one early question of any AI feature: does it suggest, or automate? A suggestion goes to a person who decides; automation changes a record or decision directly. Automation needs stronger controls, so this choice shapes everything after it.

The readiness rule.

LAI 055 Not Ready to Ship

The book's Toolbox rule: if you cannot say which things a feature touches, you are not ready to ship it. A summarizing feature that reads incident notes may also write a category field; until someone names both, it waits. Teams usually find the second thing late, in production.

Seven entries take a feature through the book's checklist in three parts, then its safety checklist and risk prompt.

Purpose first.

LAI 056 Introducing a Feature: Purpose and Things

The checklist begins with purpose and things. State in one sentence what the feature is for, such as speed, consistency or insight. State in another what it is not for, such as final legal decisions or overriding policy. Name the things it reads. Name the things it writes or influences, including fields it only pre-fills. Mark which are Gold, because every later step weighs more for them. The sentence teams leave out is the second one, and it gives everyone a line to point to when scope starts to grow.

Anchoring it in the documents.

LAI 057 Introducing a Feature: Packs, Matrices, Contract

Next, make sure every affected thing has at least a Silver Pack and the Gold Packs are current. Open each Gold thing's matrix, see where AI already appears, and add the feature's new touchpoints in data, processes, tests and risk. Design prompts with the definitions as context, write into the prompt contract that the feature may not invent domain rules, and record the suggest-or-automate decision there. A stale Gold Pack is worse than none here, because the prompts will repeat its errors with confidence.

Oversight, before launch.

LAI 058 Introducing a Feature: Oversight

The checklist ends with oversight. Decide who reviews outputs at first, and how many each day. Decide how drift or bias will be detected, and which signals count. Decide how to roll back or adjust, and who may do it. Write the answers into the feature's documentation, linked from its Gold Packs, and set a date to review whether oversight can ease. The rollback answer matters most: a feature nobody can switch off has quietly joined the system's decisions.

A blunt verdict.

LAI 059 Flying Blind

The book's Gold Thing Safety Checklist ends bluntly. If the answer to several of its questions is no, it says, you are flying blind. A single no is a task to close; several are a reason to stop until the gaps are closed.

Six questions for a Gold thing.

LAI 060 The Gold Thing Safety Checklist

Before changing a Gold thing or adding AI around one, the book asks six questions. Is there a current Gold Pack? Is there a matrix, updated for this change? Do you know which fields the AI reads and which it writes or influences? Is the purpose written down? Are review points, rollback, and logging and audit clear? Have you generated test scenarios from the cards that include the AI's behavior? The fifth weighs most, because review, rollback and audit let a team recover when the AI surprises it.

Using AI to assess AI.

LAI 061 Assessing AI Risk Around a Gold Thing

The Toolbox gives a prompt for assessing a feature's risk around a Gold thing. Give the tool the Gold Pack and a few plain sentences describing the feature. Ask which fields it could read or influence, what the main risks are if the AI errs, and which parts of the definition should act as guardrails. Tell it to use only the Pack and the description. The answer is a first draft of the risk picture, and a person checks it before anything is decided.

The prompt's last question.

LAI 062 Questions Before Deploying

The risk prompt ends by asking for three to five questions the team must answer before deploying safely. For a feature drafting Claim Decision letters, one might be: who checks a letter before it reaches a customer? Those questions become the agenda for the next review.

Six entries on starting an initiative well, then three constructed features. The opening question is answered here.

Seven steps for anything new.

LAI 063 Starting a New Initiative

The Toolbox gives seven steps for starting any initiative. Scope the world and who does what. Name the things in a noun storm and mark three to seven as core. Sketch a map of zones. Pick one to three Gold things. Draft Silver Packs for the core things and Gold Packs for the Gold ones. Write two to five key cards per core thing. Last, decide where AI will assist and where it must not decide final outcomes. That boundary comes last because, drawn before the Gold things are known, it has nothing to stand on.

The short version.

LAI 064 If You Do Nothing Else

For a team with little time, the Toolbox names the core: if you do nothing else, do steps two to six for at least one Gold thing. Name the things, map them, pick the Gold thing, and write its Pack and key cards. Skipping the Gold thing removes the point of the shortcut.

The first two weeks.

LAI 065 The First Two Weeks

The Toolbox's first-two-weeks checklist fits beside other work. Run a sixty to ninety minute workshop on things and zones. Build an inventory of ten to thirty things and a map of three to seven zones. Name three to seven core things with a Bronze or Silver Pack each, write one to three cards for each one's critical behaviors, share them for feedback, and choose one or two Gold candidates. Two weeks gives a first version, and the Gold list is expected to change once validation begins.

A notice assistant, through the checklist.

LAI 066 A Drafting Assistant for Notices

A worked example, constructed for this course, follows a benefits agency's assistant that drafts notices after eligibility decisions. Ruth writes its purpose, speed and consistency, and what it is not for: deciding eligibility or rewording legal phrases. It reads the Eligibility Determination and a template and writes a draft Notice; both are Gold. The Notice's Pack is a year old and lacks the newer appeal deadline, so updating it joins the work. The matrix gains a row; the prompts forbid altering legal text; the feature suggests, and a caseworker approves each notice. A senior caseworker checks every draft for a month, the team watches for softened denial reasons, and a switch returns staff to the template. The checklist finds one more gap, missing tests, and Ruth writes three. Neither gap was about the model; both were about the things it touched.

A triage score near a decision.

LAI 067 A Triage Score Near a Gold Thing

A second constructed example puts the risk prompt to work on an insurer's triage model that scores claims for complexity. Dev gives the tool the Claim Decision's Gold Pack and a three-sentence description. The tool notes the score could steer which handler gets a claim and how fast, and names a risk nobody had raised: a low score could be read as a low-value claim. It suggests a guardrail: the decision's outcome and reasons come from policy clauses, never the score. Dev removes one invented risk about fraud and keeps the rest. The team puts the score in a Claim Assessment field that routes work, off the decision screen, matching the book's insurance playbook.

A feature that worked, and was not ready.

LAI 068 A Feature Not Ready to Ship

A third constructed example: a platform team's workspace-summary feature, release date set. At review, Lin asks which things it touches. It reads Tasks and Comments; after a pause, an engineer says it also saves the summary as a field on the Workspace, which sits on the billing matrix. The Pack is not current, the matrix has no row, and nobody has decided who reviews summaries, or what happens if one exposes a private comment. Several noes; the release moves two weeks while the team fixes each. That answers this lecture's question: AI risk lives in the things a feature touches, and the readiness rule caught a write nobody had listed.

Look at what you can now do. You can say where AI drafts and where people decide, and make the suggest-or-automate choice early, knowing it sets the controls. You can take a feature through the book's checklist, from purpose to oversight, and run the six questions of the Gold Thing Safety Checklist, with the risk prompt as a first draft. And you can start an initiative with its AI boundaries drawn last, and recognize a feature that works but is not ready. Unit Four turns to the domain playbooks.

This is free, and stays free. If it helped, here is what keeps it running.