Until Dr John Snow demonstrated in 1854 that cholera was transmitted in drinking water, frequent and commonly fatal outbreaks had been attributed to the bad air of ‘miasma’. Yet in 2026 it’s proving impossible for Snow’s successors to stop cyclosporiasis, thankfully a far milder condition despite its explosive diarrhoea, from ripping its way through well over 10,000 cases across almost every state in the USA. The difference appears to be in attribution, the demonstration of a causal link between exposure and occurrence.

Causation is just as important when dealing with Mac problems, but even tougher than with infectious diseases. If you’ve just installed an update to XProtect when you notice the Finder acting strangely, can you assume that’s cause and effect?

The two biggest barriers to discovering causation in macOS are its complexity and almost complete opacity. These were neatly demonstrated last week in testing whether an SSD Trims. I might have an older external SSD that has recently become slow when writing large files. When asking around, someone wisely suggests I should question whether this might have occurred because the drive needs a good Trim. So all I want to do is discover whether my SSD has Trim support.

I first open the Tips app, and type in my question how to tell whether an SSD trims? Its response is that Content is Unavailable, and it recommends that I try opening the Tips app later, when it repeats exactly the same message. Searching in Tips for the word trim is equally unrewarding, as every hit refers to editing audio or video tracks, as macOS seems unable to understand the context. So much for intelligence.

Google’s AI Overview directs me to entries in System Information, which seems more promising. But when I look there, my SSD only appears in the USB section, where there’s no mention of its Trim status, although Google assured me there would be.

Even when I know that I can check through log entries made by the APFS Spaceman during mounting of the drive, I’m no closer to the answer. Trying to get the Console app to show those doesn’t seem possible, as it can only display a livestream of log entries, rather than letting me browse back to those from a few seconds ago, unless I create a logarchive and open that. Although that’s described in Tips, I think, it seems too complicated to attempt, and I still don’t understand what I’m looking for.

The solution isn’t really that difficult when using a free third-party utility and a few step-by-step instructions. Without that prior knowledge, though, you have little chance of ever discovering that for yourself, particularly with the bundled utilities provided.

Last week’s questions on causation were inevitably results of the recent macOS updates to 26.6.1, 15.7.9 and 14.8.9, as if in anticipation of next week’s round of updates. One was almost certainly a kernel panic that occurred at the end of the update, and resolved in a further attempt, while the other was more puzzling, as it involved the disappearance of two apps without trace.

In the absence of a detailed explanation, you might reasonably assume that updating macOS provides an ideal opportunity for the system to clean up third-party apps it has taken a dislike to, in this case because the lost apps are both Intel-only, so won’t be able to run on an Apple silicon Mac once Rosetta 2 is removed “in a future version of macOS”. It’s only when you can peer through the opacity that you discover that the macOS updater has least access to the Data volume containing the user’s files and third-party apps, making a causal link extremely unlikely in any version of macOS since Big Sur.

What Apple also doesn’t reveal is the amount of telemetry performed during macOS updates, so it can detect potential problems early. I described this in my account of a deep dive into the log from updating macOS Tahoe 26.2 to 26.3. These are anonymised, their only identifier being a UUID allocated locally to that update, and enable Apple to track progress from the start of scanning for updates through to the Mac booting into its updated macOS.

With that level of live telemetry, Apple should be able to detect problems as they’re occurring, and take necessary action, rather than having to wait for support requests to pile up. If something has gone horribly wrong, this should minimise the numbers exposed before it takes corrective action.

Nevertheless, if you do experience any severe problems that don’t resolve promptly, you should obtain a sysdiagnose at that point and contact Apple Support, as I advised a couple of days ago. The detail contained in that report should be ample to allow Apple’s engineers to determine exactly what went wrong, and what caused it.

That’s not going to prevent cholera, but at least it should stop updates from having similar effects to cyclosporiasis.