Most of the curriculum depreciates as the models improve. The skill that appreciates is not on it.
David Shillingford posted a list this week that is worth reading closely. Nine waterways, tracked simultaneously. The Danube at historic lows, limiting shipping and making it difficult for power plants to run cooling systems. The Rhine at seventeen centimeters at a key gauge. The Panama Canal imposing draft limits ahead of expected drought. And on the other side of the world, the Yangtze taking a flood pulse into the Three Gorges reservoir at thirty-eight thousand cubic meters per second.
His conclusion: an AI-enabled, human-informed disruption monitoring system is now table stakes.
The phrase that matters there is human-informed, and I want to take it seriously rather than nod at it — because the monitoring is the part that is already solved.
Any competent system can now track nine rivers, or ninety. The data is public and largely free: the USGS alone publishes real-time readings from more than eleven thousand gauges, and global river discharge is available by coordinate from open flood-forecasting services. What no monitoring system can reliably establish is that the Rhine at seventeen centimeters connects to a decision inside your organization that nobody has ever associated with the Rhine. A capable model may propose the correlation. Whether the relationship is real, and what it costs, still has to be established in the operation.
That connection has to be recognized by a person. And it is not the skill anyone is being trained in.
What AI literacy actually teaches
Look at what is on the curriculum. Prompt construction. Tool selection. Evaluating outputs. Spotting hallucinations. Integrating a model into an existing workflow. Knowing which system to use for which task.
Every one of those is an operating skill — how to work the machine.
And much of that knowledge is depreciating in real time, as the machine increasingly compensates for the limitations of its operator. Prompt construction was a specialty in 2023 and is now substantially absorbed into models better at inferring intent. Tool-selection knowledge declines as systems orchestrate their own tools. Organizations are building multi-year training programs around requirements that change within months.
Not all of it moves that way. Evaluating an output, handling data properly, security, privacy, domain judgment — those hold, and some of them get harder as the systems get more persuasive. The part that erodes is the part whose entire content is compensating for what the tool cannot yet do on its own.
Which produces the uncomfortable arithmetic: the better the models get, the less differentiating it becomes to merely know how to operate them. Not worthless — ubiquitous, which is a different problem. That is not a criticism of the training. It is what happens to any skill whose content is compensating for a tool’s current limitations.
The skill that moves the other way
There is one capability that does the opposite. It becomes more valuable as the systems become more capable, not less.
Recognizing when a system is operating against an incomplete understanding of reality.
Call it being operation-literate — able to read how the work actually happens, as opposed to how it is documented, encoded, or described in a process map. It is the counterpart to being machine-smart, and the two are not the same skill.
That skill appreciates for a structural reason. When a person makes a decision on a wrong assumption, the assumption affects one decision. When an autonomous system makes decisions on the same wrong assumption, it applies it thousands of times at machine speed, consistently, and reports no errors — because from inside the encoded frame nothing has gone wrong.
So the value of catching it rises in direct proportion to the autonomy of the system. The more capable the machine, the more expensive the unexamined assumption becomes.
This is barely present in mainstream AI-literacy curricula. And the reason is that it is not an AI skill at all.
Why it cannot be taught as a machine skill
The relationships that matter are often not represented as relationships in any dataset. The individual facts may all be present. The link between them is what is missing.
At a defense maintenance operation delivering parts on time 51 percent of the time in 1998, the question that changed the outcome was what time of day orders came in. Late afternoon — technicians were batching order releases at the end of the day, because releasing them as they arose interrupted service calls, and they were measured on call volume. A rational response to how they were being measured, one department away from the people being blamed.
Delivery performance reached 97.3 percent in three months. No new system.
So why am I talking about a 1998 situation in 2026? Because the skill was discovery — looking past the way things are said to work to find out how they really work in the real world. Over the past three decades that has held regardless of the technology era. In the AI era it becomes more critical, not less.
The order timestamps were already in the data. Clean, complete, and unremarkable, sitting there for years. Nothing flagged them, because on no org chart, no process map and no dataset are service technician incentives connected to parts delivery performance.
Which is worth separating into three things, because they are usually collapsed into one and only one of them is scarce.
Finding the pattern. Orders cluster at four o’clock. That is in the timestamps, and a capable system will surface it now in seconds.
Getting the cause. Technicians were batching releases because they were measured on call volume. That is in nobody’s data. It came from people under no obligation to explain their process to procurement.
Knowing that order timing was worth interrogating at all. This is the one that matters, and it is the one that gets least attention.
Consider how odd that question is. Delivery performance was the problem, and order timing is one of dozens of attributes that could have been pulled — value, part class, requisitioner, supplier, distance, urgency code, day of week. The question was not impressive. It was consequential, because something indicated that order timing was a strand likely to carry across a boundary no diagram crossed.
In 1998 that came from accumulation. Enough years of watching operations that a short list of likely places surfaced without conscious searching. It felt like a natural progression of thought at the time, which is another way of saying it was not a method anyone could hand to someone else.
And this is where the current machines change the situation, in a way worth being precise about.
Enumeration is not the machine’s consolation prize. It is a genuinely new capability, and I did not have it. A person can now put the problem in directly — here is the delivery performance shortfall, what are the usual places a connection would sit, and what are the unusual ones — and get a candidate list back that is longer and more complete than instinct would produce, including places nobody in the room would have named.
That is levelling, and it should be said plainly. The thing that used to require decades of accumulation is now available to someone who does not have decades, but does have great curiosity and critical thinking abilities. Experience and instinct remain useful. They are no longer the determining factor.
What does not come off the list is the next step. Every candidate carries a cost — walking to a department that is not yours, asking a question that can land as an accusation, spending goodwill on something that may turn out to be nothing. Pull on all forty and you have burned your credibility by the sixth.
A machine can propose forty places to look. It cannot tell you which one is worth the walk.
That judgment is about consequence and expense, not about pattern recognition, and it is learnable. Which is precisely why it should be what training is aimed at.
A person trained to write better prompts will not get there. Not because they are unskilled, but because they are looking at the model rather than at the operation, and the answer exists only in the operation.
What the training would have to look like
If the objective is people who can tell when a system is working from an incomplete picture, three things change.
Trace, don’t map. Mapping starts from a destination or objective and works toward it, based on the technology selection and what is known about the process. What determines success is the unknown processes outside that lens. Tracing starts from what is actually happening and works back to why. Only one of the two can surface something you did not already suspect.
Practice on outcomes, not on tools. Give someone a result — a number that moved, a program that underperformed — and have them find the upstream condition that produced it. Then check the answer against the operation rather than against a rubric. The exercise is not resolvable from a dataset, which is exactly the point.
Reward the question, not the query. Most organizations celebrate the person who built the dashboard. Almost none celebrate the person who asked why a department two floors away is measured in a way that makes the dashboard’s assumption false. The second person is worth considerably more and is usually invisible. And now that a machine will hand anyone a list of forty candidate questions, what deserves recognition is narrower and more teachable: choosing the one worth pursuing, and being right often enough that people keep answering.
None of that requires a model. All of it requires access to the operation, and permission to ask about parts of it that are not yours.
What I will concede
AI literacy is not worthless, and the people building those programs are not wrong to build them. A baseline of operating competence is genuinely necessary — someone who cannot evaluate an output at all is not going to notice when the frame is wrong either. Basic fluency is a floor.
There is a second floor, and almost nobody is talking about it.
Consider how the four o’clock question actually got answered. Somebody had to go to a department that was not theirs, ask service technicians why they were holding order releases until the end of the day, and get a straight answer — without the technicians hearing it as an accusation, because the moment they did, the honest answer stops coming. They were under no obligation to explain their process to procurement. Nothing in any dataset was going to supply what they knew.
Finding the signal in the data is one thing. Understanding an unencoded relationship usually requires somebody to tell you something the system never knew to ask. That is a human collaboration problem before it is an analytical one, and I have yet to see an AI literacy curriculum built to develop it. The major frameworks center on understanding AI, using it responsibly, evaluating its output, and designing with it. Getting a straight answer out of a department that is not yours is a different competence entirely.
Which raises a question worth sitting with. If someone is poor at communicating and collaborating with people, does that predict how they will do with AI agents?
Not directly — and that is the interesting part. The two do not transfer cleanly in either direction, but the gap between them matters enormously. Someone fluent with people can be poor with agents: too deferential, treating output as an opinion to be respected rather than a claim to be checked, unwilling to push back on a machine that sounds certain. Someone fluent with agents can be poor with people: treating a technician like a query, issuing a well-formed question and receiving a defensive non-answer, then concluding the information was not there.
Knowing which of those describes you is itself part of the competence. Neither program teaches it, because each assumes the other has been handled.
The error is treating any of these floors as the destination.
An organization that trains a thousand people to prompt well and none to examine operating reality has bought a workforce that can execute an incorrect model faster than it could before. That is not a failure of the training. It is the training working exactly as designed, applied to the wrong objective.
The distinction, stated plainly
The more capable AI becomes, the less valuable merely knowing how to operate it becomes — and the more valuable it becomes to recognize when it is operating against an incomplete understanding of reality.
Those two curves cross. In most organizations they have crossed already, and the training budget is still sitting on the wrong side of the intersection.
David’s list is the illustration. Nine rivers, monitored continuously, and the monitoring is the cheap part. The expensive part is the person who looks at the Danube line and knows which decision inside their own operation just became wrong — a decision that appears on no diagram connecting it to a river.
That person is not machine-smart. They are operation-literate. And almost nothing being sold as AI training is designed to produce them.
-30-
Truth Is Believing. Accuracy Is Knowing. Outcome Is Proof.™
Related
AI Literacy Is Training People to Be Machine-Smart and Process-Blind
Posted on August 10, 2026
0
Most of the curriculum depreciates as the models improve. The skill that appreciates is not on it.
David Shillingford posted a list this week that is worth reading closely. Nine waterways, tracked simultaneously. The Danube at historic lows, limiting shipping and making it difficult for power plants to run cooling systems. The Rhine at seventeen centimeters at a key gauge. The Panama Canal imposing draft limits ahead of expected drought. And on the other side of the world, the Yangtze taking a flood pulse into the Three Gorges reservoir at thirty-eight thousand cubic meters per second.
His conclusion: an AI-enabled, human-informed disruption monitoring system is now table stakes.
The phrase that matters there is human-informed, and I want to take it seriously rather than nod at it — because the monitoring is the part that is already solved.
Any competent system can now track nine rivers, or ninety. The data is public and largely free: the USGS alone publishes real-time readings from more than eleven thousand gauges, and global river discharge is available by coordinate from open flood-forecasting services. What no monitoring system can reliably establish is that the Rhine at seventeen centimeters connects to a decision inside your organization that nobody has ever associated with the Rhine. A capable model may propose the correlation. Whether the relationship is real, and what it costs, still has to be established in the operation.
That connection has to be recognized by a person. And it is not the skill anyone is being trained in.
What AI literacy actually teaches
Look at what is on the curriculum. Prompt construction. Tool selection. Evaluating outputs. Spotting hallucinations. Integrating a model into an existing workflow. Knowing which system to use for which task.
Every one of those is an operating skill — how to work the machine.
And much of that knowledge is depreciating in real time, as the machine increasingly compensates for the limitations of its operator. Prompt construction was a specialty in 2023 and is now substantially absorbed into models better at inferring intent. Tool-selection knowledge declines as systems orchestrate their own tools. Organizations are building multi-year training programs around requirements that change within months.
Not all of it moves that way. Evaluating an output, handling data properly, security, privacy, domain judgment — those hold, and some of them get harder as the systems get more persuasive. The part that erodes is the part whose entire content is compensating for what the tool cannot yet do on its own.
Which produces the uncomfortable arithmetic: the better the models get, the less differentiating it becomes to merely know how to operate them. Not worthless — ubiquitous, which is a different problem. That is not a criticism of the training. It is what happens to any skill whose content is compensating for a tool’s current limitations.
The skill that moves the other way
There is one capability that does the opposite. It becomes more valuable as the systems become more capable, not less.
Recognizing when a system is operating against an incomplete understanding of reality.
Call it being operation-literate — able to read how the work actually happens, as opposed to how it is documented, encoded, or described in a process map. It is the counterpart to being machine-smart, and the two are not the same skill.
That skill appreciates for a structural reason. When a person makes a decision on a wrong assumption, the assumption affects one decision. When an autonomous system makes decisions on the same wrong assumption, it applies it thousands of times at machine speed, consistently, and reports no errors — because from inside the encoded frame nothing has gone wrong.
So the value of catching it rises in direct proportion to the autonomy of the system. The more capable the machine, the more expensive the unexamined assumption becomes.
This is barely present in mainstream AI-literacy curricula. And the reason is that it is not an AI skill at all.
Why it cannot be taught as a machine skill
The relationships that matter are often not represented as relationships in any dataset. The individual facts may all be present. The link between them is what is missing.
At a defense maintenance operation delivering parts on time 51 percent of the time in 1998, the question that changed the outcome was what time of day orders came in. Late afternoon — technicians were batching order releases at the end of the day, because releasing them as they arose interrupted service calls, and they were measured on call volume. A rational response to how they were being measured, one department away from the people being blamed.
Delivery performance reached 97.3 percent in three months. No new system.
So why am I talking about a 1998 situation in 2026? Because the skill was discovery — looking past the way things are said to work to find out how they really work in the real world. Over the past three decades that has held regardless of the technology era. In the AI era it becomes more critical, not less.
The order timestamps were already in the data. Clean, complete, and unremarkable, sitting there for years. Nothing flagged them, because on no org chart, no process map and no dataset are service technician incentives connected to parts delivery performance.
Which is worth separating into three things, because they are usually collapsed into one and only one of them is scarce.
Finding the pattern. Orders cluster at four o’clock. That is in the timestamps, and a capable system will surface it now in seconds.
Getting the cause. Technicians were batching releases because they were measured on call volume. That is in nobody’s data. It came from people under no obligation to explain their process to procurement.
Knowing that order timing was worth interrogating at all. This is the one that matters, and it is the one that gets least attention.
Consider how odd that question is. Delivery performance was the problem, and order timing is one of dozens of attributes that could have been pulled — value, part class, requisitioner, supplier, distance, urgency code, day of week. The question was not impressive. It was consequential, because something indicated that order timing was a strand likely to carry across a boundary no diagram crossed.
In 1998 that came from accumulation. Enough years of watching operations that a short list of likely places surfaced without conscious searching. It felt like a natural progression of thought at the time, which is another way of saying it was not a method anyone could hand to someone else.
And this is where the current machines change the situation, in a way worth being precise about.
Enumeration is not the machine’s consolation prize. It is a genuinely new capability, and I did not have it. A person can now put the problem in directly — here is the delivery performance shortfall, what are the usual places a connection would sit, and what are the unusual ones — and get a candidate list back that is longer and more complete than instinct would produce, including places nobody in the room would have named.
That is levelling, and it should be said plainly. The thing that used to require decades of accumulation is now available to someone who does not have decades, but does have great curiosity and critical thinking abilities. Experience and instinct remain useful. They are no longer the determining factor.
What does not come off the list is the next step. Every candidate carries a cost — walking to a department that is not yours, asking a question that can land as an accusation, spending goodwill on something that may turn out to be nothing. Pull on all forty and you have burned your credibility by the sixth.
A machine can propose forty places to look. It cannot tell you which one is worth the walk.
That judgment is about consequence and expense, not about pattern recognition, and it is learnable. Which is precisely why it should be what training is aimed at.
A person trained to write better prompts will not get there. Not because they are unskilled, but because they are looking at the model rather than at the operation, and the answer exists only in the operation.
What the training would have to look like
If the objective is people who can tell when a system is working from an incomplete picture, three things change.
Trace, don’t map. Mapping starts from a destination or objective and works toward it, based on the technology selection and what is known about the process. What determines success is the unknown processes outside that lens. Tracing starts from what is actually happening and works back to why. Only one of the two can surface something you did not already suspect.
Practice on outcomes, not on tools. Give someone a result — a number that moved, a program that underperformed — and have them find the upstream condition that produced it. Then check the answer against the operation rather than against a rubric. The exercise is not resolvable from a dataset, which is exactly the point.
Reward the question, not the query. Most organizations celebrate the person who built the dashboard. Almost none celebrate the person who asked why a department two floors away is measured in a way that makes the dashboard’s assumption false. The second person is worth considerably more and is usually invisible. And now that a machine will hand anyone a list of forty candidate questions, what deserves recognition is narrower and more teachable: choosing the one worth pursuing, and being right often enough that people keep answering.
None of that requires a model. All of it requires access to the operation, and permission to ask about parts of it that are not yours.
What I will concede
AI literacy is not worthless, and the people building those programs are not wrong to build them. A baseline of operating competence is genuinely necessary — someone who cannot evaluate an output at all is not going to notice when the frame is wrong either. Basic fluency is a floor.
There is a second floor, and almost nobody is talking about it.
Consider how the four o’clock question actually got answered. Somebody had to go to a department that was not theirs, ask service technicians why they were holding order releases until the end of the day, and get a straight answer — without the technicians hearing it as an accusation, because the moment they did, the honest answer stops coming. They were under no obligation to explain their process to procurement. Nothing in any dataset was going to supply what they knew.
Finding the signal in the data is one thing. Understanding an unencoded relationship usually requires somebody to tell you something the system never knew to ask. That is a human collaboration problem before it is an analytical one, and I have yet to see an AI literacy curriculum built to develop it. The major frameworks center on understanding AI, using it responsibly, evaluating its output, and designing with it. Getting a straight answer out of a department that is not yours is a different competence entirely.
Which raises a question worth sitting with. If someone is poor at communicating and collaborating with people, does that predict how they will do with AI agents?
Not directly — and that is the interesting part. The two do not transfer cleanly in either direction, but the gap between them matters enormously. Someone fluent with people can be poor with agents: too deferential, treating output as an opinion to be respected rather than a claim to be checked, unwilling to push back on a machine that sounds certain. Someone fluent with agents can be poor with people: treating a technician like a query, issuing a well-formed question and receiving a defensive non-answer, then concluding the information was not there.
Knowing which of those describes you is itself part of the competence. Neither program teaches it, because each assumes the other has been handled.
The error is treating any of these floors as the destination.
An organization that trains a thousand people to prompt well and none to examine operating reality has bought a workforce that can execute an incorrect model faster than it could before. That is not a failure of the training. It is the training working exactly as designed, applied to the wrong objective.
The distinction, stated plainly
Those two curves cross. In most organizations they have crossed already, and the training budget is still sitting on the wrong side of the intersection.
David’s list is the illustration. Nine rivers, monitored continuously, and the monitoring is the cheap part. The expensive part is the person who looks at the Danube line and knows which decision inside their own operation just became wrong — a decision that appears on no diagram connecting it to a river.
That person is not machine-smart. They are operation-literate. And almost nothing being sold as AI training is designed to produce them.
-30-
Truth Is Believing. Accuracy Is Knowing. Outcome Is Proof.™
Share this:
Like this:
Related