Every tool you run has a picture of the world. The good ones also have a picture of themselves. Almost none have a picture of you. That third one is why things get missed.
That's the close for October. Three weeks ago I asked a simple question about the systems we trust: how would you know if one stopped working? Here's what the month turned up.
#19. A quiet monitor and a dead one look exactly the same. Three checks tell them apart: a heartbeat, a fire drill, and a volume floor.
#20. Roughly forty-seven errors in thirty minutes, after eighteen days at zero. Every dashboard green. I found them by scrolling my inbox.
#21. Checking what an assistant says is easy. Checking what it doesn't say needs an answer key. My Friday question never got answered. The replacement refused to grade eight days of data, but it did turn up a channel the assistant had never watched. Then the weekly check I built to collect the real numbers died in August, and nothing told me.
Three Models
Every tool carries some picture of the world it's working in. I think of it as three models, and each issue this month was about a different one.
1. The world. What's happening: orders, records, errors, email. This is the part vendors demo, and most tools have a solid one. The integration in #20 knew exactly what failed. It logged every error.
2. Itself. Whether the tool is working. This is what #19 was about. A monitor with no heartbeat has no picture of itself, so it can't tell you it stopped. #20 was the same gap from the other side: the system was up, so the dashboards said it was healthy, even while the work it existed to do was failing. And #21's weekly check, the one I built to count misses, died in August without a sound. I knew the lesson. I'd just written it down. I still built a check with no picture of itself.
3. You. What the person it serves already knows, what they've already handled, and what they'd miss without help. This is the one almost nothing has. It's why #21 was hard. An assistant with no picture of me can't tell the difference between telling me something I already know (noise) and staying quiet about something I don't (a miss). From its side, both look fine.
The Borrowed Method
Education research worked on this problem thirty years ago.
In 1994, Albert Corbett and John Anderson at Carnegie Mellon published a method called knowledge tracing. It came out of a tutoring program that taught students to write short programs. While a student worked, the tutor kept a running estimate, skill by skill, of how likely it was that the student had learned it. Every answer updated the estimate. Then the tutor used those estimates to decide what to show the student next, and kept going until each skill was mastered.
The point that matters for us: the tutor didn't just know the subject. It kept a model of what this particular student already knew, and it updated that model with every piece of evidence.
That's the missing third model. An assistant built this way wouldn't ask "what's in the data?" It would ask "what's in the data that you don't already have?" Then it would check whether you acted on it, and update.
Here's what that looks like on my own assistant, using this month's misses.
The Friday question. For about six weeks it asked me the same thing every Friday, and every Friday I didn't answer. A tutor that tracked me would have read that as evidence. Six blanks in a row is a fact about how I work, and it says the question is the wrong instrument. Mine kept asking anyway, because nothing in it was keeping score on me.
The error emails. It counted my unread mail. It never asked the follow-up a tutor would ask: has he seen what's in there? Roughly forty-seven messages from one system, after eighteen days of nothing, is exactly where my picture of what I know is thinnest. That's where it should have spoken up. It stayed quiet, and every report it sent was still accurate.
The mail I handle myself. The flip side matters just as much. If I've dealt with the same kind of message every time it shows up, the tool should get quieter about it. A tool with no picture of you is the smoke detector that goes off every time you make toast. Eventually you pull the battery.
One caution on my own version: a single observation doesn't settle anything. A message I skip might mean I already know, or it might mean I missed it. A right answer can be a lucky guess, and a wrong one can be a careless slip. So the estimate moves a little with each thing I do, not all at once. That's the difference between a model of me and a rule that says "ignore anything he skips once."
Where this comes from: those three examples are my reading of how the idea would apply. The 1994 paper was about students learning to write programs. The jump to assistants is mine, and I haven't seen an assistant built this way. That's the part I'm borrowing, not reporting.
The Test Before You Trust One
Before you trust an assistant, or any system that's supposed to tell you when something needs attention, ask it three questions. One per model.
Does it know what's happening? What was it told to watch, and does that match what you assume it watches? (#21.)
Does it know when it's broken? What tells me it stopped working? Not "it'll send an error." What fires? (#19, #20, and my dead weekly check in #21.)
Does it know what I already know? Does it learn from what I act on and ignore? And how would anyone measure what it missed? (#21.)
Most tools pass the first. A few pass the second. If one passes the third, I want to hear about it.
Try This Monday
The test above is for a vendor. This one is for something you already run. Thirty minutes, one tool.
Pick something that's supposed to tell you when something needs attention: a monitor, a dashboard, a weekly report, an AI assistant's morning briefing. Then run all three models on it.
The world. Write down what it was told to watch, then compare that to what you assume it watches. If you can't get the list, that's your first finding.
Itself. Find the last time it fired, and ask what would tell you if it stopped. (That's #19.)
You. Take its last week of output, every alert, line, or item. Next to each one, write either already knew or needed it. Then write down anything you would have wanted to hear about that never showed up.
That third step is knowledge tracing with a pencil. If most of the list says already knew, the tool is mostly handing you things you have. That's noise, and noise is how batteries get pulled. If you can name even one missing item in under a minute, you've found a gap in what it was told to watch.
Good places to start: the weekly pipeline report nobody opens, the integration error digest, the morning briefing from an assistant.
When you're done you'll have two numbers: how many items you already knew, and how many things it missed. Say it gave you 20 items, you already knew 14, and you can name 2 it never mentioned. Your answer is "14 of 20 already known, 2 missed." The closer the first number gets to "20 of 20," the more the tool is just repeating what you already know. The second number is a floor, since you can only name the misses you know about.
How Would You Know?
That's where I'd leave October. The question isn't whether your systems work. Most of them do, most of the time. The question is whether anything would tell you when they stop. For most of what we run, the honest answer is still "someone would probably notice."
Probably is a hope, not an instrument.
ACTION ITEM: Which of the three models is weakest in your shop? Run the Monday test and send me your two numbers: what you already knew and what it missed.
Reply, I read every one.
November turns from the tools to the people asked to use them. Everything this month assumed someone would change how they work once the better system showed up. Next month: what to do when they don't.
Go hug your ERP. Then check its pulse.
Plant Floor to Cloud: The Newsletter goes out every Tuesday. The podcast runs monthly. Same charter, more room to think out loud. Watch or listen on the website, or wherever you get podcasts: Apple Podcasts, Spotify, YouTube, iHeart, and more.
