Limitations and product boundary

What this fictional demo may and may not claim

This is a fictional demo

All companies, suppliers, mills, PO numbers, receipt numbers, heat numbers, lot numbers, material grades, dimensions, certificate numbers, dates and values in this demo are fictional. The certificate layouts are fictional and do not reproduce any real supplier's document.

What this demo may claim

It reconciles fictional material-certificate documents against fictional receipt/lot data.
It detects configured identity/coverage inconsistencies.
It preserves document/page provenance for every conclusion.
It refuses ambiguous associations rather than guessing.
It reduces a fictional batch to a smaller human-review set.

What this demo may NOT claim

Validation on real supplier certificates.
Compliance, material acceptance, regulatory conformity or production readiness.
Universal certificate-layout support (it is bounded to the fictional layouts in this demo).
Proven time savings or proven Nordic SME ROI.
That the synthetic exception frequencies in the fixture reflect real industry prevalence.
Whether material is safe, compliant, authentic or fit for use.
Whether a certificate is authentic or whether a deviation is acceptable.

The four result states

State	Means
EVIDENCED	Required identity and coverage evidence resolves and every configured check passes. This is an evidence-coverage verdict, not a material-acceptance verdict.
MISSING	No certificate carries sufficient transaction or identity evidence to be a candidate at all.
CONFLICTING	An anchored certificate exists but an explicit checked requirement conflicts: wrong heat or lot, a certificate type other than the one the order expects, or a duplicated certificate reference.
AMBIGUOUS	Certificate evidence is present, but the association cannot be established deterministically. Either more than one plausible candidate remains, or the only relevant candidate does not carry enough identity evidence to establish coverage. The system refuses to choose.

MISSING, CONFLICTING and AMBIGUOUS all belong to the QA review set: the review count is the total minus EVIDENCED.

What the engine will not infer

Supplier identity alone never creates a candidate association, and a difference in supplier naming format never outranks heat, lot or transaction evidence.
A certificate that names only a transaction reference is never enough to establish coverage, whether or not another received record could also claim it. Transaction-only evidence makes a document relevant, not identifying.
Being the only candidate is not evidence. A lone certificate that satisfies no sufficiency rule stays unresolved rather than being promoted because nothing else turned up.
Extraction is bounded to the six fictional layouts in this demo. It is not a general certificate parser.

Product boundary: identity/traceability, not engineering-spec compliance

The core product boundary for this build is identity/traceability/coverage reconciliation: "does the certificate belong to the received lot/heat, and is the required certificate coverage present and consistent?"

The demo may include a configured optional rule that compares a supplied certificate type (or other configured value) against an expected value and reports whether that configured rule matched or did not match. That is reported as a deterministic rule outcome, not as a decision that material is acceptable or unacceptable.

See the summary and the implementation plan in plans/.

Human-action wording is deliberately bounded

The demo suggests bounded actions such as: locate missing supplier certificate; confirm which receipt this certificate belongs to; verify conflicting heat reference; request corrected certificate; review certificate-type mismatch.

It does not suggest: accept material, reject material, quarantine automatically, approve deviation, or certify compliance.

Research basis and disagreements

The real-world workflow claims in this demo are constrained by the reference research. The research is strongest on the existence of a manual identity/traceability/coverage reconciliation workflow and on the one-order-line-to-multiple-certificates case. It does not establish Nordic SME certificate volume, nor does it establish that Nordic SME staff routinely compare numeric chemistry/mechanical values against ERP-held specification limits.

The build brief is authoritative for what this fictional demo must contain; the reference research is authoritative for what may be represented as a real-world workflow claim. Where the research reports disagree (for example on whether the mechanism should be framed as engineering-specification compliance checking), this demo adopts the more conservative identity/traceability boundary.

Back to summary