| 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 planning ranges to educate the market. Diagnostic reports use uploaded catalog data to compute source-backed SKU count, duplicate groups, duplicate-rate signals, exposure, and confidence-tier interpretation.
That distinction is important because enterprise buyers must defend decisions after the report leaves the portal. A planning assumption 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.