Anomaly Upload Validator

Three vocabularies for the same damage

Every mismatch between the three surfaced late, after the data had already reached customer success or engineering, and someone had to work out which column meant what before anything could proceed.

Wind turbine blade inspection findings arrived from an inspection vendor in the vendor's own damage taxonomy, which did not reliably match the way the platform classified the same damage. The manufacturer receiving the report required a third nomenclature again, because manufacturers do not categorize the same physical damage the same way.

Validation before anyone sees the data

The validator moves that check to the front.

An inspection dataset is validated against the spec before it reaches anyone, and the damage taxonomy conversion runs automatically rather than waiting on engineering review.

It is in production use internally. It was built with Claude.

Conversion is a decision with exceptions

The mapping is not a lookup.

It runs in two hops, [vendor category A] → [platform category 2] → [manufacturer code X], and it is uneven in both directions: several vendor categories collapse onto a single platform category, and one platform category can open into more than one manufacturer code depending on the component involved. Severity is an ordinal scale and does not convert one for one. Some source categories have no clean target at all, and those are held for manual review rather than guessed, which is why conversion is a decision with exceptions rather than a table. The bracketed placeholders are invented. The real category names, codes and severity values are client and manufacturer property and are withheld here on purpose.

Where the specification did not hold

The documents record where the specification did not hold, and where a build shipped output that looked right.

Defects that came from real data

Thirteen defects were found and fixed between v2.2 and v3.1.4, each indexed in the release notes against its root cause. Four of the first eight are one failure repeated: the tool assumed input data was more uniform than it is. Every one of the first eight surfaced through contact with real data rather than through review, which is the argument for validating against genuine delivered files rather than reconstructed examples.

Defects that looked right

The later five sharpen a different point, which is silence. Three of them produced output that looked plausible: a misrendered header, an empty cell under a correct header, and a column sized for its neighbour all render as a normal spreadsheet, and none raises an error. In the starkest, the value is read, matched and validated correctly and only the write misses, so the export cannot be told apart from a dataset that never supplied that column.

That is the case for publishing the documents.

Designed for the handoff

The validator has one user today: me.

I run every dataset through it, and I am handing it to an operations project support team after the next one or two iterations. These design artifacts are built for that handoff: who takes the tool over, where they will need help, and how their first session will be tested. Anything resting on assumption carries an (A) label until that test replaces it. They were built from the published documents below; the running tool was not opened, so no value from it appears here.

How it was specified

The tool is internal, so the build itself is not something I can show. The documentation is, and it is the more useful half anyway.

This document set describes v3.1.4, September 2026. It is current with the build.

What is redacted, and why

The conversion tables are redacted. That crosswalk belongs to the client and the manufacturer rather than to me, so it is marked where it was removed rather than quietly dropped. The shape of the conversion problem is publishable and the values are not, which is the line this page holds. Everything else is the document as written.

The five documents