Why We Check Values, Not Fields

On August 5, 2026, we ran the first routine edits through our canonical loop since moving all landing page copy into WordPress: a punctuation cleanup, six em dashes and six curly apostrophes across a handful of entries. A small job. It produced a lesson we are keeping permanently.

Before any import runs, we build an expectation file: exactly which values should change, and a fingerprint of each new value. Then the importer’s dry run tells us what it would write, and the two must agree perfectly. On this run, they appeared not to. One file reported one field changing where our expectation said two values.

We stopped and chased it before anything was imported. The explanation turned out to be a units difference. The report counts fields, and a field can be a group holding several values inside it. Both of our changed values sat inside one group on one page, so the honest count was one field, two values. No error.

The reason this entry exists is what we noticed next: a genuinely broken import would produce the same headline. If a group held two changed values and the tool wrote only one of them, the report would still say one field changed. The benign case and the broken case read identically at the field level. The only thing that separates them is the fingerprint of each individual value, which the dry run prints and we verify. On this run, the stamp the importer computed matched the new value on disk exactly. A skipped value would have stamped the old bytes.

So the rule is now written into how we verify every import: the field headline is never the proof. Every changed value gets its own fingerprint comparison, built before the run and checked against the report. Fields are how the tool summarizes. Values are what readers actually see. We check what readers see.