Release Notes & Changelog

Anomaly Upload Validator: Release Notes & Changelog

Internal Tool · v3.1.4 · September 2026

Document Overview

This document provides a versioned history of the Anomaly Upload Validator, a browser-based tool that ingests raw inspection data exports from Input Source, validates them against Platform A upload specification, converts field values across three nomenclature systems (Input Source, then Platform A, then Platform B), enables human-in-the-loop resolution of unmatched values, and exports a formatted multi-tab XLSX working document.

Version Summary

On the v2.2 to v2.7 dates. These were reconstructed in September 2026, not recorded at the time. v2.3 through v2.7 each anchor to a dated artefact the tool itself produced — converted files carrying an export date in their name, and input files named by working date — which come from the machine clock and are dependable.

v2.2 was dated separately, and later. It produced no such artefact, and was first recorded here as inference from the releases either side of it. It has since been bracketed against the retained working files instead: bulk resolution is present in the build immediately preceding the column-matcher work and absent from the one before that, and those two builds are dated 1 May and 23 May 2026. That places v2.2 inside May on file evidence rather than on position in the sequence. The bracketing is sound in both directions; the residual weakness is that it rests on file modification times, which can record a later re-save. A Drive or chat timestamp from when bulk resolution shipped would still be the stronger record.

The June to September gap is real, not a lost record. No release occupies the span between v2.7 and v2.7.1, and no artefact has been found in it. Whether the work paused or simply went unreleased is not something this document can settle, but nothing is missing from the sequence.

v1.0: Core Validator

Release Date: May 2026 · Status: Released

Background

Wind farm asset owners use Input Source to conduct blade inspections. Datasets exported from Input Source as CSV or XLSX must be imported into Platform A before onward submission to Platform B. Prior to this tool, data coordinators manually checked each upload file, a time-consuming, error-prone process with no standardized output.

What Was Built

A self-contained HTML file deployable via shared Google Drive with no installation required. Accepts CSV and XLSX uploads, parses them client-side, and validates every row and column against Platform A upload specification.

Changes

Known Issues at Release

• Serial Number treated as required, demoted to conditional in v1.2.
• Blade Side validation limited to two-character codes only.
• No conversion logic; field values validated as-is.

v1.1: Three-Tier Status System

Release Date: May 2026 · Status: Released

Background

During initial testing it became clear that empty Asset and Coordinates fields may exist in internal historical records and simply weren't included in the Input Source export. Flagging these as hard errors created false positives and undermined trust in the compliance score.

Changes

v1.2: Field Spec Refinements

Release Date: May 2026 · Status: Released

Background

Real Input Source exports revealed Blade Side uses full descriptive names, and Serial Number is not consistently available and should not block uploads.

Changes

v2.0: Conversion Engine & XLSX Export

Release Date: May 2026 · Status: Released

Background

Data coordinators still needed to manually convert field values across three nomenclature systems using a separate Excel spreadsheet. This release embedded the conversion logic directly and produced a properly formatted output XLSX, eliminating the manual conversion step.

Conversion Flow

Input Source, then Platform A, then Platform B

Changes

Known Issues at Release

• VLOOKUP row ranges hardcoded in exported XLSX. Engineering adding rows beyond existing ranges requires manual formula updates.
• ISBLANK() formula limitation, fixed in v2.1.
• Single dataset format supported at release (Format A structure). Multi-format added in v2.1.

v2.1: Multi-Format Support & Formula Fix

Release Date: May 2026 · Status: Released

Background

Testing with the Format B dataset revealed: (1) Format B exports use Component + Element rather than Component + Material, and Anomaly Type + Subtype rather than Type + Subtype. (2) Excel's ISBLANK() returns FALSE for empty string cells, causing a trailing ' - ' on the derived value instead of the base value alone when Subtype is empty.

Changes

Datasets Validated

• Format A, Input Source export (Component + Material, Type + Subtype structure)
• Format B, Input Source export (Component + Element, Anomaly Type + Subtype structure)

v2.2: Bulk Manual Review Resolution

Release Date: May 2026 · Status: Released

Background

Manual Review flags were cleared one row at a time. On a dataset carrying many unmapped values that is slow and repetitive, and it does not match how a data coordinator actually works: they recognise an unmapped value once, then want that decision applied everywhere it appears in the batch.

Changes

Documentation note

The sanitized SDLC document set was built at v2.1, not v2.2. This release was therefore the first one those documents never covered, which put the undocumented range at six versions rather than five.

That range was closed on 2026-09-18. The data dictionary, this document, the PRD, the user stories and the test cases were all brought current to v3.1.4. The note is kept because the six-version gap explains why several of those documents needed substantial revision rather than a version bump, and why the dates above had to be reconstructed rather than read off a record.

v2.3: Content-Based Column Matcher

Release Date: May 2026 · Status: Released

Background

Real files vary in column order, in column names, and in sheet structure. The fixed-layout assumption held only for files matching the canonical structure exactly, and broke on everything else. Three specific failures drove this release: the header row is not always row 1, because some files carry a work-order preamble block above it; two columns in the same file can share a name while meaning different things at different levels of the record; and the blade letter appears in at least four different shapes across sources.

Changes

Provenance note

Bugs 2 and 3 were found in a file later confirmed to be a reconstructed illustrative example rather than a genuine export. The disambiguation logic is sound regardless, but whether duplicate column names occur in real delivered files is not established. Treat this behaviour as defensive until a genuine file exercises it.

v2.4: Pass-Through Field Signatures, Sheet Order, Conversion Key

Release Date: June 2026 · Status: Released

Background

Several output columns were writing a header with nothing beneath it. The cause was not the export and not the specification: the matcher held no field signature for those fields, so it never bound the input column to the canonical name, and the export lookup returned nothing. The field definitions had been correct since v2.1. This is the same failure pattern as an earlier Links and Source Images issue, and it is worth naming as a class: an unmapped field loses its values silently, with no error and no flag, because nothing in the pipeline knows the value was supposed to be there.

Changes

Decisions

• Formulas reference the output slots, never the raw input columns. The output Material slot carries the effective suffix, Material for Format A and Element for Format B. The output Type slot carries the damage base, Type for Format A and Anomaly Type for Format B. One formula path therefore serves both input formats.
• Any raw input value the export needs is read from the untouched input row, never from the working row. Row processing mutates the working row during derivation, so reading a value back from it after processing returns the transformed value. This is the general rule behind bug 5 and it applies to every future export field.

v2.5: Output Schema Change, Asset and the Two Serial Numbers

Release Date: June 2026 · Status: Released

Background

The output Asset column had been carrying turbine identifiers while the tool's own blade-validation logic assumed Asset meant the blade. The two had disagreed since the conversion engine shipped, without surfacing as an error, because nothing in the pipeline compared them. This release separates the three concepts that had been sharing two columns.

Changes

Verification: 73 of 73 rows on the test file matched the amended target exactly across all three columns.

Known Issues at Release

• A column was inserted, so every output column to the right of F has shifted by one position. Formula column references and any downstream consumer matching on column position are affected. See the data dictionary's open verification items.
• Semantic mismatch on the input side, accepted deliberately. The matcher's canonical Asset field still binds by name to the input Asset column, which now carries turbine numbers. The field is therefore named Asset and means turbine number on the way in, while meaning blade letter on the way out. Renaming it was judged a larger change than this release warranted.

v2.6: Clickable Image Links

Release Date: June 2026 · Status: Released

Background

The exported report carried image URLs as plain text. Opening one meant selecting the cell, copying the string and pasting it into a browser, for every image a reviewer wanted to see.

Changes

v2.7: URL Entity Double-Encoding Fix

Release Date: June 2026 · Status: Released

Background

The hyperlinks shipped in v2.6 opened a browser and then failed. The storage provider returned a not-found error for URLs that were, to the eye, correct.

Changes

Verification: the output hyperlink is byte-for-byte identical to the input URL. 1355 characters, 6 ampersands, exact match at both ends.

Known Issues at Release

• Image links expire, and the tool does not warn about it. The signed URLs are time-limited by the source system, typically around a 30 day window, after which the storage provider returns the same not-found error this release fixed. That is an upstream constraint rather than a tool defect, and the two failures are indistinguishable to a user clicking a dead link. A file exported and then left unprocessed past the window will produce a report whose links fail silently. An expiry warning at ingest is a candidate for a future release.

v2.7.1: Output Header Name Corrections

Release Date: September 2026 · Status: Released

Background

Four of the eight derived output columns carried a wrong rendering of a company name: two lower-cased a name mid-word, two transposed a pair of letters in another. Neither error was applied consistently, and one name appeared correct in one column and wrong in another within the same sheet. The v2.1 limitation log had recorded one of the two as preserved intentionally, which implied something downstream matched on the misrendered string.

Changes

On the "preserved intentionally" note. Before the change the tool was searched for every occurrence of all four strings. All were on the output side. The input-side column matcher — both its alias map and its field signatures — contained neither spelling, so no ingestion path had ever depended on a misrendered form. The intended asymmetry, correct on the way out and tolerant on the way in, turned out to be unnecessary: nothing needed tolerating. Files exported before this release ingest exactly as they did before.

Verification: the header row was read from the raw exported file rather than from a summary, because transcription normalises spelling silently, which is how the defect survived an earlier review. All four corrected, the four already-correct headers unchanged, column count and order identical.

LIM-07 is closed by this release, as copy error rather than convention. The casing error was never tracked and needed no entry of its own, having been found and fixed in the same change.

Known Issues at Release

• Exports produced before this release still carry the old headers. A consumer matching those files by header string still has to match two spellings of one name to catch all three of its columns.

v3.0: Date Handling Correction

Release Date: September 2026 · Status: Released

Background

Two faults in one line of the ingestion path, which preferred the library's display-formatted value over the underlying one for every cell.

Changes

A detail worth recording. The serial-to-date conversion carries a sub-minute per-zone skew, because the library builds its epoch from a pre-1900 date and zones then sat on odd historical offsets. In one zone a 2026-04-12 cell lands on 23:59:50 the day before. Reading the components naively would have lost a whole day to ten seconds, so the value is rounded to the nearest minute first.

Verification: seven timezones spanning UTC-10 to UTC+14, against both CSV and XLSX inputs, with date-related errors going from four per four-row file to zero in all fourteen combinations.

Scope note

The original report of this defect over-generalised: it described the shift as affecting all exports. It affects CSV inputs only. Date cells in real XLSX exports were never shifted, because their display value is formatted from the stored serial rather than from a timestamp. The format fault, by contrast, affected both input kinds in every timezone.

v3.1: Two Output Columns Written Empty

Release Date: September 2026 · Status: Released

Background

Blade Chamber and Chord (%) appeared in every export with correct headers and no values beneath them, for any dataset that supplied them.

Changes

Why it went unnoticed. There was no signal of any kind: no error, no warning, no Manual Review flag. Validation reads the value under its canonical name, where it is present and correct, so the field passes. Only the write missed. In the export the result is indistinguishable from a dataset that never supplied the column. This is the failure class already named at v2.4 — an unmapped field loses its values silently — but one link further down the chain: there the field signature was missing, here the signature works and the output lookup key is wrong.

Audit. All 39 output columns were checked for the same mismatch. Three other headers are not canonical field names: Date, which has a working bridge, and Action and Rule, which have no input field at all and are intentionally blank. These two were the whole set.

Known Issues at Release

• Exports produced before this release cannot be repaired from the converted copy. The values are not in it. Any file needing those two columns has to be re-run from the original Input Source export.

v3.1.1: Export Column Width Realignment

Release Date: September 2026 · Status: Released

Background

The exported Damages Report set 38 column widths for 39 columns.

Changes

Verification: the two candidate readings were scored against the widest value each column can actually hold. The shipped alignment mis-sized 24 of 39 columns; the shifted reading, 14. Every implausible width resolves under the shift, which is what identified it.

v3.1.2 to v3.1.4: Column Width Fitting

Release Date: September 2026 · Status: Released

Background

With the alignment corrected, the widths themselves were still those authored for an earlier schema.

Changes

Verification: every conversion-driven column now seats its widest possible value with no clipping. Across all three releases the exported cell data is byte-identical; only the width declarations change.

Bug Index, v2.2 to v3.1.4

Thirteen defects were found and fixed across this range. Seven carry numbers in the internal change log; the rest were recorded without one and are numbered here for completeness.

The pattern worth noting across them. Four of the first eight (1, 2, 3, 8) are the same class of failure: the tool assumed input data was more uniform than it is. Two more (4, 5) come from the derivation pipeline transforming a value and then reading it back as though untouched. Only bug 7 originates outside the tool's own logic. 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.

The later five sharpen a different point: silence. Bugs 9, 12 and 13 all 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-looking spreadsheet, and none raises an error. Bug 12 is the starkest — the value is read, matched and validated correctly, and only the write misses, so the export is indistinguishable from a dataset that never supplied the column. Bug 11 is the opposite and was louder than it looked: it raised a hard error on every dated row in every timezone, which is the kind of noise that gets worked around rather than investigated. Three of the five (12, 13, and the shift in 11) trace to a positional or naming assumption left behind when a schema changed underneath it, which is the argument for checking the fixed-layout artefacts — output column lists, width arrays, lookup keys — whenever a column is inserted.

Archive note: v3.0 to v3.1.3 working files are reconstructions

Recorded 2026-09-18.

The working files for v3.0, v3.1, v3.1.1, v3.1.2 and v3.1.3 were not retained when those releases were made. Each release was produced by renaming the previous working file rather than copying it, so at any moment only the newest build existed on disk. The gap was noticed when the intermediate builds were called for.

They have been reconstructed and archived. The method was to replay each change forward from the retained v2.7.1 working file, in the order the changes were originally made, rather than to unpick them backward from v3.1.4 — a backward reconstruction produces files that cannot be checked against anything.

What validates them. Replaying every step lands on a v3.1.4 working file that is byte-for-byte identical to the real one, SHA-256 c37973f8…. Since the endpoint reproduces exactly, each intermediate state on the path to it is also correct. Independently, every reconstructed build was run through the export path and shows exactly the defect profile its release entry describes and no other: v3.0 still writes two columns empty, the width count first reaches one-per-column at v3.1.1, and the Input Source Component width moves 26 → 32 → 45 → 51 across the releases that changed it. Each build differs from its predecessor by that release's change alone.

What is not identical. These are faithful reconstructions of the file contents, not the original files. Their filesystem timestamps are the reconstruction date, not the original build dates. Anything relying on file modification time to date a build should treat v3.0 to v3.1.3 as undated and use this document instead.

Practice change. Releases are now produced by copying the working file rather than renaming it, so each version persists on its own.

Deployment

Anomaly Upload Validator · Internal Use Only · v3.1.4 · September 2026