Units of Measure Harmonization Intelligence Platform: a KNIME workflow for UOM error detection

The problem: unit of measure errors that survive every other validation layer

Master data validation usually checks that a field is populated and that its value sits in an allowed list. Neither check catches a purchase order line that says 50 KG where the material is sold by the each. The README frames this as a decimal-or-unit problem with downstream consequences: order fulfillment, inventory levels, shipped quantities, billing and regulatory reporting. The stated audience is manufacturing, procurement and supply chain teams, plus data quality groups doing migration work. The examples given include production planning, bill of materials standardisation, multi-vendor integration and healthcare unit standardisation. That is a wide net for one workflow, and the README does not explain how the classification features differ between, say, a pharmaceutical dose and a fastener count. Treat the use case list as a statement of intent rather than evidence that one trained model generalises across all of them.

What the workflow actually does with a row

The README describes five components: data ingestion from CSV or Excel with validation, an ML classification engine with 60+ engineered features and an XGBoost classifier trained with 5-fold cross-validation, a physics validation layer using NIST-compliant conversion rules, a reinforcement learning agent described as Q-learning for autonomy, and an interactive dashboard. The data flow implied by that ordering is: rows enter, features are computed, the classifier assigns an error type and a probability, the conversion engine checks whether the stated unit is physically consistent with the material and quantity, and the Q-learning agent decides whether to auto-correct or route to manual review. The README lists the error categories the system detects: decimal errors, unit mismatches, conversion issues between imperial and metric, formatting problems and missing units. It does not document the feature list, the training corpus, the reward function for the Q-learning agent, or how the physics rules are encoded. The architecture document is linked but its contents are not reproduced in the README, so anyone evaluating the model has to open docs/ML_MODEL.md and docs/ARCHITECTURE.md directly.

Getting it running: clone, import, execute

The Quick Start is four steps. Clone the repository, then in KNIME Analytics Platform 4.5 or newer use File, Import KNIME Workflow and select the workflow folder. Then right-click the workflow and execute it, selecting data-sample/sample_10k.csv when prompted. The README claims results in two to three minutes. There is no pip install, no container image and no compiled binary, because the runtime is KNIME itself. The badge in the README specifies KNIME 4.5 or above, and the technology stack section repeats that. The repository's primary language is listed as PowerShell, which suggests the surrounding tooling (possibly setup or file-handling scripts) is written in PowerShell rather than that the analysis logic is. If your team does not already run KNIME, the real setup cost is installing and learning that platform, not the four commands above. The README also claims zero configuration and works out of the box with sensible defaults, which is plausible for a demo run on the shipped sample and less plausible once your own column names and unit vocabulary differ from the sample.

The numbers in the README and what they do not cover

The README states 88 to 92 percent accuracy in the repository description and gives an example run: 10,000 records processed in 3 minutes, 847 errors found (8.47 percent), 796 auto-corrected (94 percent) and 51 sent to manual review (6 percent). It also states 3,300 records per minute throughput and 94 percent autonomy. None of these figures come with a methodology in the README: no held-out set description, no per-class breakdown, no false positive rate. For a data cleaning tool the false positive rate matters more than raw accuracy, because a wrong auto-correction writes a bad unit into a system that may not flag it again. The README reports a 60 to 80 percent reduction in UOM errors and 50 percent-plus time savings as organisation-reported ROI, without naming the organisations or the measurement method. Treat all of these as vendor claims to reproduce on your own data, not as established properties of the software.

Where it stops being the right tool

The deliverable is a KNIME workflow folder, not a library with a stable API. If your data pipeline is Python, dbt or Spark, you cannot import this as a dependency and call it per batch. You would be running KNIME alongside your stack, exporting corrections, and applying them downstream, which the README acknowledges by listing export corrections to apply to your system as a usage step. The second constraint is the physics validation layer. NIST-compliant conversion rules handle dimensional consistency between units, but a unit that is dimensionally valid can still be commercially wrong: a material legitimately sold by weight in one plant and by count in another will not be resolved by conversion rules, and the README does not describe how the model learns plant-specific conventions. Third, the README does not state how the model is retrained on your data or whether the shipped model can be fine-tuned at all. The self-learning claim is tied to the Q-learning agent and feedback, but no feedback format, config key or retraining command appears in the README. Finally, the licence is inconsistent: the README's feature list says free for commercial use under MIT license, while the repository metadata and the badge both say Apache-2.0. Those licences differ on patent grant and notice requirements, so resolve it before shipping anything commercial.

How this differs from a rules-based master data check

The obvious alternative is a rules engine: a table mapping material number to permitted units, plus validation in your ERP or MDM tool. That approach is deterministic, auditable and cheap to explain to an auditor. Its weakness is coverage. It catches violations of rules you wrote and nothing else, so a unit that is wrong but permitted by a loose rule passes through. This project's bet is that a classifier over 60+ features can catch patterns a rule author would not enumerate, and that the physics layer provides a deterministic backstop for the dimensional cases. The trade-off is the inverse: you gain recall on unenumerated patterns and lose the ability to explain a single decision by pointing at a rule, unless the feature importances and the conversion check are surfaced in the dashboard. The README says the dashboard shows root cause analytics and confidence scores, which would help, but it does not show what a root cause record contains. If auditability is a hard requirement in your environment, a rules engine plus a reviewed exception queue may still be the better fit, and this tool becomes a pre-filter that proposes candidates.

Maintenance, versioning and what to check before you depend on it

The project has one release, v1.0.0, dated 2025-10-21, described as a production release. The last push to the default branch is 2026-05-21, so there is activity after the release. There is no homepage, no published package and no changelog content in the supplied material beyond the link to CHANGELOG.md. Upgrading means re-importing a workflow folder, and KNIME workflows carry version coupling to the KNIME release line, so a move from KNIME 4.5 to a later major version is a migration you should test on the sample before touching production data. Because the licence identifier in the repository metadata is Apache-2.0, you inherit the patent grant and the notice and attribution obligations that come with it, but the README's MIT claim creates ambiguity about which text governs. That is a question for your legal team, not something this review can settle. Concretely, before adopting: open docs/ML_MODEL.md and confirm the training data and evaluation method behind the 88 to 92 percent figure, check whether the Q-learning agent's feedback loop is documented with a file format you can produce, and run data-sample/sample_10k.csv yourself to see whether the reported 847 errors and 94 percent auto-correction rate appear on your machine.

Editorial conclusion

Adopt it if your unit of measure problems already live in flat files and your team has KNIME Analytics Platform 4.5 or newer installed, because the workflow imports and executes without extra infrastructure. Do not adopt it if you need a callable service, a Python or Spark pipeline, or a package you can pin in a dependency manifest, since the deliverable is a KNIME workflow folder rather than a library. Before committing, verify which licence actually applies, because the README states MIT while the repository metadata and badge say Apache-2.0, and confirm whether the sample_10k.csv run reproduces the 847-error figure on your own data rather than the shipped sample.

Official sources

1. Issues
2. JulietMirambo/Units_of_Measure_Harmonization-intelligence-platform on GitHub
3. License: Apache-2.0
4. README
5. Releases