Slowtime in short

Read What the Machine Actually Said

Why verification — not fluency — is the decisive engineering skill of the AI era

By Arne Havgaard 🙏 · slowtime.dk

A dashboard is a story a system tells about itself. Most of the time it is a true story. The danger is in the word most.

I have spent more than two decades moving between the engine room, the shop floor, the control room and the network, and the single habit that has saved the most projects is also the least glamorous: I open the capture file instead of believing the dashboard. I read what the machine actually said on the wire, not what the screen claims it meant. The green tile and the smooth trend line are representations. The packet, the vibration trace, the metallurgical section — those are evidence. When the two disagree, the evidence wins, every time.

That distinction used to be a craftsman's preference. In the AI era it has become the whole game.

Fluency is not truth

What large language models changed is not the supply of intelligence. It is the supply of confidence. We can now generate plausible-looking representations — summaries, reports, code, root-cause narratives, energy figures — faster than we can verify them. The output reads well. It is structured, fluent, and arrives without the hesitation that used to signal "I am not sure." Fluency has become cheap, and because it has become cheap, it has stopped being evidence of correctness.

This is not an argument against AI. I use it daily, and my engagement with its risks is not recent or theoretical: in 2022 I filed public comments on the first draft of NIST's AI Risk Management Framework, on the public record alongside organisations like Google, Microsoft, IBM, OpenAI and MITRE. The point of working with these tools seriously is to hold them to the same standard I hold a SCADA dashboard or a vendor datasheet. A model that summarises a control system is making a claim. A claim is a starting point for verification, never the end of one.

The engineers who will matter over the next decade are not the ones who can prompt the most fluently. They are the ones who can still tell the difference between a confident representation and a verified fact — and who have kept the discipline to check.

Three places the gap bites

IT/OT integration and industrial cybersecurity. The asset inventory says one thing. Profinet and the packet capture say another. NIS2 and ISA/IEC 62443 do not ask whether your documentation is tidy; they ask what your system actually does, what is actually talking to what, and whether you can prove it. A Zero Trust posture is only as good as your willingness to inspect traffic at the lowest layer you can reach. The dashboard shows you the network you designed. The capture shows you the network you have. Security lives entirely in the gap between those two.

Energy and CCECC. Nameplate ratings, vendor efficiency curves and headline carbon figures are the energy world's dashboards — useful, and routinely optimistic. Cradle to Cradle Energy Conceptual Calculations (CCECC), the framework I work in, starts from a different stance: account for energy across the full life of a system from first principles, cradle to cradle, rather than trusting the figure printed at the boundary someone chose for you. The honest number is almost never the convenient one, and you only find it by following the energy where it actually goes, not where the brochure says it stops.

Forensic and materials investigation. Every failed component arrives with a story attached — an incident report, an operator's account, a supplier's explanation. The story is a hypothesis. The hardness test, the optical microscopy, the high-speed video, the vibration spectrum: those are the witnesses under oath. Structured, evidence-first root-cause work means being willing to let the section through the fracture surface contradict the paperwork. It usually does.

Different domains, one pattern. In each, there is a representation that is comfortable to trust, and a measurement that is inconvenient to take. The whole value is in taking the inconvenient measurement.

The discipline, stated plainly

Verification is not a personality trait. It is a method, and it can be written down:

• Verify at the lowest layer you can reach. The wire over the inventory. The trace over the trend. The section over the report. Abstractions are where errors hide because abstractions are designed to hide detail.
• Treat every confident output as a claim, not a conclusion. This now applies to AI output exactly as it applies to a vendor's datasheet. Fluency earns a hearing, not a verdict.
• Solve the right problem, fast — then document it so the client can verify you. Work that cannot be independently checked is not finished work; it is a second story asking to be believed.
• Build what scales, not what demos. A solution that survives only under the demo's conditions is a dashboard wearing a deployment's clothes.
• Do not stop at "we normally do it this way." Convention is the most trusted dashboard of all, and the least examined.

Why this is called Slowtime

There is a reason verification has a reputation for being slow, and a reason I have made slowness part of the name rather than apologising for it. Opening the capture file takes longer than reading the tile. Following energy cradle to cradle takes longer than copying the nameplate figure. Sectioning the fracture takes longer than accepting the report.

That extra time is not friction. It is the part that makes the answer trustworthy. In a market now flooded with output produced at machine speed, the scarce and valuable act is the deliberate one: to slow down at the exact moment everyone else accelerates, and to read what the machine actually said before deciding what it means.

The future is yours. The tools are extraordinary, and they are not going to stop getting more fluent. Make it count by keeping the one habit no model removes the need for — verify what a system actually does, rather than trusting what it is supposed to do.

That is the difference between a system that demos well and one that holds.

Arne Havgaard is a digital marine engineer working across IT/OT integration, industrial cybersecurity, first-principles energy analysis and verified AI use. He is the author of slowtime.dk and originator of the CCECC (Cradle to Cradle Energy Conceptual Calculations) concept. 

Let's connect if you're looking to turn complexity into clarity and sustainable strategy.