| Evidence layer | How it is produced | Governance control |
|---|---|---|
| Benchmark ranges | Published as planning assumptions until replaced by uploaded-data evidence. | Shown visibly in public pages and report notes. |
| Diagnostic evidence | Generated from CSV uploads using the PartsCleanse AI engine. | Source file purged after generation; Open Findings and summary metrics retained. |
| False-positive control | Critical discriminator classes reduce unsafe part consolidation. | Methodology page explains size, material, pressure, model, category, UOM, and subtype controls. |
| Review discipline | Findings are decision-support evidence, not automatic ERP instructions. | Reports separate confidence tiers and preserve owner review requirements. |
AI2COE reports should read like board-ready diagnostic evidence, not raw software output.
Public pages use benchmark ranges to educate the market. Diagnostic reports use uploaded catalog data to compute actual SKU count, duplicate groups, duplicate rate, exposure, and confidence-tier interpretation.
That distinction is important because enterprise buyers must defend decisions after the report leaves the portal. A benchmark can justify investigation; a diagnostic finding can justify review; only owner-approved remediation can justify ERP change. AI2COE keeps those boundaries visible across pages, reports, emails, and methodology notes.
Every claim should be traceable to a source layer.
AI2COE content is written so a reviewer can tell whether a number came from a public benchmark, a user-entered estimate, an uploaded catalog field, a calculated report metric, or an admin audit record. This makes the portal safer for CFO review, CIO governance, procurement sign-off, and operational owner validation.