User Stories & Acceptance Criteria

Anomaly Upload Validator — User Stories & Acceptance Criteria

Platform A · Internal Tool · v3.1.4 · September 2026

Overview

This document contains the user stories and acceptance criteria for the Anomaly Upload Validator. Stories are organized by epic and reflect delivered functionality as of v3.1.4. Each story follows the format: "As a [persona], I want [capability], so that [outcome]." Acceptance criteria are written as testable, unambiguous conditions.

Story Map

EP-01 — File Ingestion

Uploading raw source platform exports into the tool.

US-01 — Upload a dataset file

User Story:

As a Data Coordinator, I want to upload a CSV or XLSX file by dragging it into the tool or browsing for it, so that I can begin validating a dataset without needing any technical setup.

Acceptance Criteria

• AC-01: Tool accepts .csv, .xlsx, and .xls file formats.
• AC-02: User can drag and drop a file onto the designated drop zone.
• AC-03: User can alternatively click the drop zone to open a file browser.
• AC-04: On successful load, the filename and total data row count are displayed.
• AC-05: If the file is empty or cannot be parsed, a clear error message is shown and no validation runs.
• AC-06: No file data is transmitted to any external server at any point.

US-02 — Have column names normalized automatically

User Story:

As a Data Coordinator, I want the tool to automatically handle common column name variations in source platform exports, so that I don't have to manually rename columns before uploading.

Acceptance Criteria

• AC-01: "Date" is treated as "Inspection Date".
• AC-02: "Blade Chamber" is treated as "BladeChamber".
• AC-03: "Chord (%)" is treated as "Chord(%)".
• AC-04: "Turbine Serial Number" is treated as "Serial Number".
• AC-05: "Links" is treated as "Source Images".
• AC-06: Unrecognized column names are passed through unchanged and do not cause errors.
• AC-07: Normalisation is applied silently — no notification shown to the user.

Note: Alias map is defined as a named constant in the tool script. Engineering can extend it without touching validation logic.

US-25 — Upload a file that has a metadata preamble above the header row

User Story:

As a Data Coordinator, I want a file whose header row sits below several rows of metadata to be read correctly, so that I do not have to delete rows by hand before uploading.

Acceptance Criteria

• AC-01: The header row is located automatically within the first 25 rows of the sheet.
• AC-02: The row scoring the most recognised column names is chosen as the header.
• AC-03: Rows above the detected header are ignored and do not become data rows.
• AC-04: The detected header row number is reported back on the upload confirmation.
• AC-05: A file whose header is on row 1 is unaffected.

Note: Before v2.3 the tool assumed row 1 was the header, so any export carrying a preamble failed at ingestion.

EP-02 — Validation

Checking datasets against the Platform A upload specification.

US-03 — See which required columns are missing

User Story:

As a Data Coordinator, I want the tool to tell me which required columns are missing from my dataset, so that I can fix the file before attempting an upload.

Acceptance Criteria

• AC-01: Tool checks for all 18 required column headers after alias normalisation.
• AC-02: Missing required columns are displayed as individual cards showing field name and description.
• AC-03: Missing conditional columns (Serial Number, BladeChamber, Chord(%), Recommendation) are shown as informational — they do not block the export.
• AC-04: Column name matching is case-sensitive.
• AC-05: Missing column cards appear before the row-level issues table.

US-04 — See which rows have field errors

User Story:

As a Data Coordinator, I want to see exactly which rows have missing or incorrectly formatted required fields, so that I know what needs to be fixed before the dataset can be uploaded.

Acceptance Criteria

• AC-01: Every data row is validated against all required field rules after normalisation and conversion.
• AC-02: Each issue is shown with: Row number, Anomaly ID, Field name, Status badge, and detail message.
• AC-03: Severity must be an integer between 1 and 5 inclusive.
• AC-04: Critical must be "Yes" or "No" (case-insensitive).
• AC-05: Inspection Date must match YYYY-MM-DD format exactly.
• AC-06: "Damage Location" must be "Internal" or "External" (case-insensitive).
• AC-07: Distance (m), Length (m), Width (m) must be numeric values.
• AC-08: Coordinates must contain at least three [x,y] bracketed pairs.
• AC-09: Empty required fields raise an Error, except for Asset and Coordinates (see US-06).

US-05 — Validate Blade Side using full descriptive names

User Story:

As a Data Coordinator, I want the tool to accept both abbreviated codes and full descriptive names for Blade Side values, so that datasets using either naming convention pass validation without manual editing.

Acceptance Criteria

• AC-01: "Code 1" and "Value 1" are both accepted.
• AC-02: "Code 2" and "Value 2" are both accepted.
• AC-03: "Code 3" and "Value 3" are both accepted.
• AC-04: "Code 4" and "Value 4" are both accepted.
• AC-05: Matching is case-insensitive.
• AC-06: Any value not in the above list raises an Error.

Note: Expanded in v1.2. Original v1.0 accepted two-character codes only.

US-06 — See conditional field warnings separately from hard errors

User Story:

As a Engineering / Data Lead, I want conditional field format issues to appear as Warnings rather than Errors, so that they don't inflate the error count or block the export.

Acceptance Criteria

• AC-01: Conditional fields are validated for format only when present and populated.
• AC-02: Format violations in conditional fields raise a Warning — not an Error.
• AC-03: Warning rows are included in the issues table but excluded from the Error count.
• AC-04: Serial Number is fully optional — no flag raised whether absent, empty, or populated.
• AC-05: Warnings do not block the Export Converted XLSX button.

Note: Serial Number demoted from Required to Conditional in v1.2.

EP-03 — Status & Compliance

Understanding dataset health at a glance.

US-07 — See an overall compliance score

User Story:

As an Operations Manager, I want to see a single compliance score for the dataset, so that I can quickly understand its overall readiness for upload without reviewing every row.

Acceptance Criteria

• AC-01: Compliance score is displayed as a percentage.
• AC-02: Score = clean rows / (total rows − check-internally rows) × 100.
• AC-03: Check Internally rows are excluded from the denominator.
• AC-04: Score bar is green ≥80%, amber 50–79%, red <50%.
• AC-05: Score updates automatically after each Manual Review resolution.

US-08 — Distinguish between hard errors and check-internally flags

User Story:

As a Data Coordinator, I want empty Asset and Coordinates fields to be flagged differently from hard errors, so that I'm not penalised for information that may already exist in our internal records.

Acceptance Criteria

• AC-01: When Asset field is empty, the row is flagged as "Check Internally" — not as an Error.
• AC-02: When Coordinates field is empty, the row is flagged as "Check Internally" — not as an Error.
• AC-03: Check Internally rows are counted in a dedicated summary card.
• AC-04: Check Internally rows are excluded from the compliance score denominator.
• AC-05: The issues table includes a "Check Internally" filter tab.
• AC-06: Check Internally rows do not block the Export Converted XLSX button.

US-09 — Filter the issues table by status type

User Story:

As a Data Coordinator, I want to filter the issues table by status type, so that I can focus on one category of issue at a time.

Acceptance Criteria

• AC-01: Issues table includes five filter tabs: All, Errors, Manual Review, Check Internally, Warnings.
• AC-02: "All" tab is selected by default on load.
• AC-03: Selecting a tab hides rows that do not match that status.
• AC-04: "Manual Review" filter shows both unresolved and Resolved rows.
• AC-05: Active tab is visually highlighted.
• AC-06: Filter state does not affect the compliance score or export.

EP-04 — Conversion Engine

Transforming Input Source field values across three nomenclature systems.

US-10 — Have Element values derived and converted automatically

User Story:

As a Data Coordinator, I want the tool to automatically build the Input Source Component value from the raw data columns and look up its Platform A and Platform B equivalents, so that I don't have to manually apply conversion formulas.

Acceptance Criteria

• AC-01: If Material column is present and non-empty: Input Source Component = Component + " - " + Material.
• AC-02: If Material is absent/empty but Element column is present: Input Source Component = Component + " - " + Element.
• AC-03: If neither suffix column is present/populated: Input Source Component = Component alone.
• AC-04: Concatenation uses a LEN()=0 guard — not ISBLANK() — to correctly handle empty-string cells.
• AC-05: If found in conversion table, Platform A Element and Platform B Element are populated from columns B and C.
• AC-06: If not found, both columns show "MANUAL REVIEW: [original value]" and the row is flagged.

Note: Multi-format support (Material vs Element fallback) and ISBLANK→LEN fix added in v2.1.

US-11 — Have Anomaly Type values derived and converted automatically

User Story:

As a Data Coordinator, I want the tool to automatically build the Input Source Damage Type value and look up its Platform A and Platform B equivalents, so that damage type conversion happens without any manual steps.

Acceptance Criteria

• AC-01: If Type column is present, it is used as the base value.
• AC-02: If Type is absent but Anomaly Type column is present, it is used as the base value.
• AC-03: If Subtype is present and non-empty: Input Source Damage Type = base + " - " + Subtype.
• AC-04: If Subtype is absent or empty: Input Source Damage Type = base value alone (no trailing " - ").
• AC-05: Concatenation uses a LEN()=0 guard — not ISBLANK().
• AC-06: If found in conversion table, Platform A Anomaly Type and Platform B Anomaly Type are populated.
• AC-07: If not found, both columns show "MANUAL REVIEW: [original value]".

Note: Type vs Anomaly Type column fallback added in v2.1. Fixes the trailing dash bug.

US-12 — Have Blade Side values translated automatically

User Story:

As a Data Coordinator, I want Blade Side values to be translated to Platform A and Platform B equivalents automatically, so that source values are correctly mapped without manual intervention.

Acceptance Criteria

• AC-01: "Value 1" maps to Platform A and Platform B equivalents. [Values withheld.]
• AC-02: "Value 2" maps to Platform A and Platform B equivalents. [Values withheld.]
• AC-03: "Value 3" maps to Platform A and Platform B equivalents. [Values withheld.]
• AC-04: "Value 4" maps to Platform A and Platform B equivalents. [Values withheld.]
• AC-05: Values not found in the Blade Side conversion table are flagged as Manual Review.

US-13 — Process datasets from multiple source platform export formats

User Story:

As a Data Coordinator, I want the tool to correctly process datasets from different clients even when the column structure varies, so that I don't have to manually reformat files before uploading.

Acceptance Criteria

• AC-01: Format A format (Component + Material columns) is processed correctly.
• AC-02: Format B format (Component + Element columns) is processed correctly.
• AC-03: Format A format (Type + Subtype columns) is processed correctly.
• AC-04: Format B format (Anomaly Type + Subtype columns) is processed correctly.
• AC-05: Format B full Blade label (e.g. "Blade A") is normalized to just the letter.
• AC-06: Blade letter is extracted from Asset column when Blade column is empty.
• AC-07: Format detection is automatic — no user configuration required.

Note: Added in v2.1 following Format B dataset testing.

EP-05 — Manual Review Resolution

Human-in-the-loop handling of unmatched conversion values.

US-14 — Resolve unmatched conversion values inline

User Story:

As a Data Coordinator, I want to resolve Manual Review flags directly in the tool using a dropdown, so that I can correct unmatched values without leaving the browser or editing the source file.

Acceptance Criteria

• AC-01: Each Manual Review row displays the original unmatched value.
• AC-02: A dropdown presents all valid Platform A platform values for the affected field.
• AC-03: On selection, the row status immediately updates to "Resolved" with a green badge.
• AC-04: The resolved value is applied to the converted dataset in memory.
• AC-05: A progress counter shows "X / Y manual reviews resolved".
• AC-06: Resolved rows remain visible under the Manual Review filter tab.

US-15 — Be prevented from exporting until all Manual Reviews are resolved

User Story:

As a Data Coordinator, I want the Export Converted XLSX button to be locked until all Manual Review flags are resolved, so that I can't accidentally export a file with unresolved values.

Acceptance Criteria

• AC-01: Export Converted XLSX button is disabled on initial load.
• AC-02: Button remains disabled while any Manual Review rows are unresolved.
• AC-03: Button enables automatically when all Manual Reviews are resolved.
• AC-04: When all resolved, counter shows "All X resolved — ready to export" in green.
• AC-05: If zero Manual Review rows, button is enabled immediately after validation.
• AC-06: Export Validation Report CSV is always available after validation — not blocked by Manual Reviews.

EP-06 — Results Dashboard

Operational visibility into dataset health and content.

US-16 — See a summary of dataset statistics

User Story:

As an Operations Manager, I want to see a summary of the dataset's content alongside validation results, so that I can confirm the scope of data being processed without opening the source file.

Acceptance Criteria

• AC-01: Total anomaly count (data rows excluding header) is displayed.
• AC-02: Unique turbine count is displayed.
• AC-03: Total site count is displayed.
• AC-04: A per-site breakdown table shows: Site name, Anomaly count, Unique turbine count.
• AC-05: Site breakdown table is sorted by anomaly count descending.
• AC-06: Stats are derived from raw source data before conversion.

US-17 — See conversion statistics alongside validation results

User Story:

As a Data Coordinator, I want to see how many fields were auto-converted and how many need manual review at a glance, so that I know immediately how much work is required before I can export.

Acceptance Criteria

• AC-01: A "Fields Auto-Converted" card shows the total count of fields successfully matched.
• AC-02: A "Rows Need Manual Review" card shows count of rows with at least one unresolved flag.
• AC-03: Both cards are displayed immediately after validation completes.
• AC-04: Auto-conversion count reflects only automatic matches — not dropdown resolutions.

EP-07 — Export

Producing outputs for upload and internal records.

US-18 — Export a validation issues report

User Story:

As a Data Coordinator, I want to download a CSV report of all validation issues, so that I can share it with the data team or keep it as a record.

Acceptance Criteria

• AC-01: Export Validation Report button is available after validation has run.
• AC-02: Report is a CSV with columns: Row Number, Anomaly ID, Field, Status, Detail.
• AC-03: Status column uses: Error, Manual Review, Check Internally, Warning.
• AC-04: File is named "validation_report_YYYY-MM-DD.csv".
• AC-05: Report includes all issues regardless of current filter tab.
• AC-06: Rows with no issues are not included.

US-19 — Export a converted XLSX working document

User Story:

As a Data Coordinator, I want to download a formatted XLSX file with all three nomenclature columns populated, so that I have a working document ready for Platform A upload and Platform B submission.

Acceptance Criteria

• AC-01: Exported XLSX contains two tabs: "Damages Report" and "Conversions".
• AC-02: "Damages Report" tab matches the column order of the approved reference file exactly.
• AC-03: Derived columns use live VLOOKUP formulas referencing the Conversions tab.
• AC-04: VLOOKUP formulas use LEN()=0 guards to handle empty-string cells correctly.
• AC-05: Resolved Manual Review values are written as static values in the output.
• AC-06: Output filename incorporates source filename and export date.
• AC-07: Exported file header row is frozen at row 1.

US-20 — Have the Conversions tab be editable and extensible

User Story:

As a Engineering / Data Lead, I want the Conversions tab in the exported XLSX to be structured and editable, so that I can add new mapping rows when new damage types or component combinations appear.

Acceptance Criteria

• AC-01: Conversions tab contains three clearly labeled sections: Element / Component, Anomaly Type, Blade Side.
• AC-02: Each section has column headers: Input Source, Platform A, Platform B.
• AC-03: A note instructs Engineering how to add new rows.
• AC-04: VLOOKUP formulas reference defined row ranges in the Conversions tab.
• AC-05: Adding a row within the existing range causes VLOOKUPs to pick it up automatically.
• AC-06: Known limitation: adding rows beyond the current range requires manual formula range updates.

US-26 — Open image links directly from the exported report

User Story:

As a Data Coordinator, I want the image links in the exported report to be clickable, so that I can open a referenced image without copying a URL out of a cell.

Acceptance Criteria

• AC-01: Cells in the Links and Source Images columns holding an http or https value carry a real hyperlink.
• AC-02: The URL remains visible as the cell's display text.
• AC-03: Source Image Reference is left as plain text, being an identifier rather than a URL.
• AC-04: The exported URL is byte-for-byte identical to the URL in the source file.
• AC-05: Where the source cell shows a friendly label but carries a hyperlink, the underlying URL is used rather than the label.

Note: AC-04 is the v2.7 fix. Reading a hyperlink returns its XML entities still encoded, and writing it back encodes them a second time; the resulting URL failed signature matching at the storage provider. Entities are now decoded on ingestion. Links are time-limited by the source system, roughly a 30 day window, which the tool does not yet warn about.

US-27 — Distinguish the blade from the two serial numbers in the output

User Story:

As an Engineering / Data Lead, I want the blade identifier and the two serial numbers to occupy separate output columns, so that the Asset field means one thing and the upload is not carrying a turbine number where a blade letter belongs.

Acceptance Criteria

• AC-01: Asset (D) carries the blade letter, A to C, and nothing else.
• AC-02: Turbine Serial Number (E) carries the value the input supplies in its Asset column.
• AC-03: Asset Serial Number (F) carries the value the input supplies as a serial number.
• AC-04: The blade letter resolves from a dedicated Blade column, a Blade Position column, a full label such as "Blade A: (No Serial Number)", or a bare letter.
• AC-05: Blade no longer exists as a separate output column; Asset represents it.

Note: Before v2.5 the output Asset column carried turbine numbers rather than blade letters. The v2.5 insertion shifted every column after D by one position, which is the root of the width misalignment later fixed at v3.1.1.

EP-08 — Output Fidelity

Four stories covering defects where the tool produced output that looked correct and was not. Each was found after v2.1 and fixed between v2.7.1 and v3.1.4.

US-21 — Read output headers that spell both company names correctly

User Story:

As an Engineering / Data Lead, I want the derived output column headers to render both company names as those companies write them, so that a downstream consumer matching on header text does not have to match two spellings of the same name.

Acceptance Criteria

• AC-01: All four previously misrendered headers (columns P, Q, U, Y) render their company name correctly.
• AC-02: The four headers that were already correct (R, V, W, Z) are unchanged.
• AC-03: Output column count and order are identical to the previous release.
• AC-04: The export formulas still resolve to the correct column letters, since the corrected strings are also the keys the formula builder reads.
• AC-05: Files exported before this release still ingest unchanged; no input alias was added or removed.
• AC-06: Verification reads the header row from the raw exported file, not from a summary or a description of it.

Note: The misrendered strings were a single namespace inside the tool — output header, row key, conversion-field label, Manual Review dropdown key and formula lookup key at once. Correcting only the header text would have broken the formulas. LIM-07 is closed by this story.

US-22 — Have dates arrive intact regardless of my timezone

User Story:

As a Data Coordinator, I want an inspection date to reach the export as the date the file actually contains, so that I am neither shipping the wrong day nor clearing a validation error on every dated row.

Acceptance Criteria

• AC-01: A date read from a CSV produces the same calendar date in every timezone.
• AC-02: A date read from an XLSX date cell produces the same calendar date in every timezone.
• AC-03: An ingested date is normalised to YYYY-MM-DD, so it satisfies the date rule the validator applies to it.
• AC-04: No row raises a date-format error solely because of how the date was parsed.
• AC-05: A cell carrying a real time of day retains it rather than being truncated to a bare date.
• AC-06: Verified across seven timezones spanning UTC-10 to UTC+14, against both CSV and XLSX inputs.

Note: Two faults with one cause: the ingestion path preferred the parser's display formatting over the underlying value. The timezone shift affected CSV inputs only; the format fault affected both input kinds everywhere, including UTC.

US-23 — Have every column I supply reach the export

User Story:

As a Data Coordinator, I want a column I supplied to carry its values into the export, so that a blank column means the data was absent rather than lost.

Acceptance Criteria

• AC-01: Blade Chamber carries its values into the export when the input supplies them.
• AC-02: Chord (%) carries its values into the export when the input supplies them.
• AC-03: Chord (%) is written as a number, consistent with the other numeric measurement columns.
• AC-04: Output header text is unchanged, so anything downstream matching on it is unaffected.
• AC-05: Every other output column is unaffected; only the two previously empty columns change.

Note: The alias map normalises Blade Chamber to BladeChamber and Chord (%) to Chord(%) on ingestion; the export then looked them up by header text, which retains the space, and both lookups missed. All 39 output columns were audited for the same mismatch — these two were the whole set.

US-24 — Read the exported report without resizing columns

User Story:

As a Data Coordinator, I want each column in the exported report to be wide enough for what it holds, so that I can read a delivered file without resizing columns by hand.

Acceptance Criteria

• AC-01: The width list holds exactly one entry per output column.
• AC-02: Each width applies to the column it was written for, not to its neighbour.
• AC-03: Every conversion-driven column seats its widest possible value without clipping.
• AC-04: Columns whose content the tool never sees keep their existing widths rather than being guessed at.
• AC-05: Cell values and formulas are byte-identical to the previous release; only the width declarations change.

Note: The width list had been one entry short since the v2.5 column insertion, so every column from E onward wore its right-hand neighbour's width. Input Source Component carries a deliberate exception to the general width ceiling, because it is the lookup key the Platform A and Platform B formulas read.

Anomaly Upload Validator · Platform A · Internal Use Only · v3.1.4 · September 2026 · 27 Stories across 8 Epics