Samples
Five real failure modes, as reports
Every package below is fictional, but every problem in it is the kind that actually costs a shop money. They are generated on request from the same code the tests assert on, so what you see is the current behaviour, not a mock-up. Nothing is charged and no signup is needed.
A package that is actually complete
Every required field is present, every value agrees across files, revisions match. The report should say so plainly.
Expected outcome: READY — no findings. A clean package is a real result, not a failure to find something.
One part at three revisions
The same bracket appears at Rev A, Rev B and Rev C across the drawing set, and one of them looks superseded.
Expected outcome: NEEDS REVIEW — a revision mismatch, with each revision cited to its own file and page.
The same number stated two ways
The email says 250 pieces, the BOM spreadsheet says 200. Both are in the package, both are quoted, and neither is picked as correct.
Expected outcome: NEEDS REVIEW — a critical conflict citing the email line and the spreadsheet cell side by side.
Required information that is simply absent
No ship-to, no delivery date, no packaging or inspection requirement — the fields an estimator needs before pricing can start.
Expected outcome: NEEDS REVIEW — each absent field reported as missing, including the freight blocker a delivery date without a ship-to creates.
The package that arrives on a Friday afternoon
All five problem categories in one package, including the same re-released drawing uploaded twice under two different names.
Expected outcome: NEEDS REVIEW — missing, conflicting, revision, attachment and ambiguity findings together.
Prefer your own package? Upload an RFQ — nothing is stored after the report is built.