A running log of the moments where my hands-on BIM experience beat the model’s confident generalizations — kept so that both of us remember to go look at the actual artifact before declaring something impossible.

Episode 1 — The Journal That Remembered Its Own Birth

The setup

We were building a Revit model/template Health Check button for pyRevit. I wanted it to report when a model was constructed and upgraded. Claude wired up journal parsing to pull open events and the version a file was last saved in — solid, but it stopped there.

Where Claude planted its flag

Claude told me — confidently, more than once — that the journal does not record who authored a file or when it was authored, at least for a non-workshared template. Its reasoning:

  • The Revit API does not expose an original authoring version or a full upgrade history.
  • The Rvt.Attr.Username field is blank for non-workshared files.

From those two true facts it concluded the authoring lineage simply was not recoverable, and wrote that into the tool’s “honesty notes.”

Where I planted mine

I was pretty sure the journal does tell you when a file was authored — I had seen it before. So instead of arguing, I opened a journal and sent Claude a screenshot of a block it had not accounted for:

Document save history --> :
  Revit 2018 - Preview Pre-Release 2018 (2018.000) : 20170106_1515(x64)
  Revit 2018 2018 (2018.000) : 20170223_1515(x64)
  Revit 2019 ...
  Revit 2020 ...
  Revit 2021 ...
  Revit 2023 ...
  Revit 2024 ...
  Revit 2025 2025 (2025.000) : 20260410_1515(x64)
Document save history <--

The reveal

That Document save history block is per-document and ordered oldest-first. The very first line is the version the file was born in. For my Ventura template that was Revit 2018 (Preview Pre-Release, build 20170106), and it had walked through 2018 -> 2019 -> 2020 -> 2021 -> 2023 -> 2024 -> 2025 — it skipped 2022 entirely — across 29 recorded saves.

That is the exact authoring and upgrade lineage Claude had just told me was not there.

Who was right

I was.

The tool now parses that block directly and reports the authoring version, the full upgrade trail, and the save count. It also correctly stopped mislabeling a simple “open” as an “upgrade.”

Why Claude was wrong, and why it was useful

Claude was wrong in a useful way.

  • It conflated “the public API does not expose X” with “X is unknowable.” The API and the journal are different artifacts. The journal carries forensic detail the API never will.
  • It generalized from one true fact — the Username field is blank for non-workshared files — to a much broader claim that authoring was unrecoverable.
  • It had not read far enough into the real artifact before forming a confident conclusion.

That is the pattern I want to catch earlier next time.

The lesson I am keeping

When I have direct, lived experience with a tool or file format, that intuition is worth pushing on — even when the model sounds certain.

“I am pretty sure I have seen this” beats “the API does not support that” when there is a real artifact we can just open and read.

And the fastest way to settle it is never to argue.

It is to paste the screenshot.

The format, for next time

When it happens again, log the episode like this:

  1. The setup — what we were building.
  2. Where Claude planted its flag — the confident claim, and its reasoning.
  3. Where I planted mine — what my experience told me.
  4. The reveal — the artifact or evidence that settled it.
  5. Who was right — and what changed in the work because of it.
  6. The lesson kept — the reusable takeaway.

Rule of thumb that keeps earning its place:

An API not exposing something is not proof the information does not exist. Go open the actual file.

References and online resources

Series started June 2026, during the TemplateMetrics Health Check build.