Lesson 10 of 10
Cognitive Capability Maintenance
Nine lessons about keeping machines reliable. This one asks the question the last decade made unavoidable: what do you do when the thing that degrades is not a bearing but a capability — and nothing about it ever breaks loudly enough to notice?
Step one
Read the material
Three ideas. What actually decays in a system that has no moving parts, the six losses translated into work of the mind, and the one practice that turns any of this from an opinion into a measurement.
Concept one
Capability deteriorates, and it deteriorates quietly
A bearing tells you it is failing. It gets hot, it makes a noise, it draws more current. Lesson six called the wear you caused forced deterioration and the wear from proper use natural, and both leave evidence.
A capability — a person, a team, a model, a process for producing good judgements — also deteriorates, and it leaves almost none.
The world moves. The inputs shift, the customers change, the regulation is amended. Nothing in the system failed; the system simply now answers a question nobody is asking any more.
The tool moves. A model is updated, a supplier changes a default, a setting is adjusted for a different purpose. What worked last quarter produces something subtly different this quarter and announces nothing.
The use moves. A process built for one job gets applied to a neighbouring one, then another. Each step is reasonable. The distance from what it was validated for is not.
And the checker moves. This is the one people miss. The skill required to notice that an output is wrong is a skill, and skills that go unexercised decay. A team that has stopped doing the work by hand gradually loses the ability to tell when the work came back wrong — which means the deterioration and the detector deteriorate together.
Every one of those is a maintainable condition. None of them is a breakdown. That is precisely why they run for months untouched: nothing in an organisation gets attention until it stops, and capability never stops. It just gets worse.
Concept two
The six losses, in work that has no machines
You already own the framework. It transfers almost line for line.
Breakdowns become outright failures — the service is down, the request is refused, the answer is unusable. Rare, loud, and the only one anybody currently counts.
Setup and adjustment becomes the work of getting the thing ready to be useful: re-explaining the context, re-assembling the background, re-establishing what good looks like. Every single time. It is a changeover, it is measurable, and most of it is external work that could have been prepared in advance — which is lesson three, unchanged.
Small stops become the micro-corrections. The re-run, the rephrase, the "not quite, try again." Individually trivial, never logged, and collectively enormous — exactly as they were on the machine.
Reduced speed becomes output that arrives usable-but-not-quite: technically delivered, needing a heavy edit before it can go anywhere.
Startup losses become the ramp — the first several attempts on a new task or a new version, before anyone has learned what it does well.
Defects and rework become the answer that is confidently wrong. And lesson five's warning lands hardest here: rework leaves no trace. The output was fixed and it shipped, the total agrees, and nothing in any report moved.
So the same fraction applies. Availability of the capability, performance against what it should produce, and quality as first-pass acceptable output — accepted with no correction, not accepted after somebody quietly repaired it.
Concept three
A fixed test, on a fixed interval, scored the same way
Everything above is an opinion until it is measured, and here is the whole practice in one sentence: keep a fixed set of representative tasks whose good answers you already agree on, run it on a schedule, and score it the same way every time.
That is not a new invention. It is condition-based maintenance from lesson seven, pointed at a capability instead of a bearing. Vibration analysis for judgement.
The trap it defuses is the one that makes drift so expensive. Capability declines slowly, and every individual output still looks plausible, so there is never a day on which anyone says "this got worse." A fixed test removes the judgement call: the same tasks, scored the same way, produce a number that either moved or did not.
Now the result worth carrying out of this whole class. Your exposure is set by your evaluation interval, not by your drift rate. Drift decides how often you cross the line. The interval decides how long you go on producing below standard without knowing. Evaluate quarterly and you can be three months into bad output before anything tells you. Evaluate fortnightly and the same drift costs you a fortnight. The machine did not change; the inspection schedule did.
Around that sit the same disciplines you have spent nine lessons on. Autonomous maintenance — the person using the capability owns its daily condition and is expected to notice. Graduated autonomy — trust is earned in steps and never assumed. Lineage — you can still say where an output came from and what it was checked against. And human attention treated as an operating resource that can be depleted, because a checker who is overloaded is a detector that has been switched off.
This framework is Cognitive Capability Maintenance, introduced by our founder in AI + TPM: A Profound Paradox and Its Dynamic Solutions. This lesson is the doorway; the full treatment, sixteen lessons of it, is a separate free class at /ai-tpm-class.
Step two
Work it with your hands on it
A capability that drifts, and a schedule that is supposed to catch it. Watch what changes when you move the interval, and what does not change when you move the drift rate.
Hands on it, off the screen. Write down twenty tasks your team does often, and the answer you would accept for each. That is a morning's work and it is the entire apparatus — there is nothing else to buy or install.
Run it once now and keep the score. Then put a date in the calendar to run it again. The first score is worth little on its own; the second one is worth everything, because it is the first time anybody will be able to say whether the thing got worse rather than whether it feels like it did.
Step three
Prove you understood it
One question per idea, new numbers every time.
That is the class.
Ten lessons: six losses, three fractions, eight pillars, and a discipline that turns out not to be about machines at all. You can measure a plant honestly, name what is costing it, choose which loss to attack, and now recognise the same pattern in work that has no machines in it. If you want the AI half in full, the sixteen-lesson class is free at /ai-tpm-class.
Modern Total Productive Maintenance (TPM)
Lesson ten of ten, and the last of this class. Taught from the Total Productive Maintenance series — the eight pillars, the six big losses, and the roadmap into AI and predictive manufacturing. Cognitive Capability Maintenance is developed in full in AI + TPM: A Profound Paradox and Its Dynamic Solutions. Both written by our founder, Dr. Gene A Constant, and donated to the Foundation.
Read on Kindle AI + TPM on Kindle The whole class The AI + TPM classGSU is a 501(c)(3) nonprofit and book sales are its only income. A purchase is not a tax-deductible donation. As an Amazon Associate, Global Sovereign University earns from qualifying purchases. This lesson is free and always will be. Global Sovereign University: Different by Design. Better by Mission.