Features
The complete rule list
Most tools in this space describe themselves as intelligent. This is the whole list of what gets checked, published rather than hidden — you should be able to read the rules before you trust a report.
1 · Missing information
Required RFQ fields that nobody wrote down, and required per-part fields.
- RFQ number, customer, contact, response deadline, requested delivery date, ship-to, part list, quantities, material, revision, tolerances, surface finish, packaging, inspection, certification and any customer-specified terms.
- Per part: a part must have an identifiable part number, a quantity and a revision before the rest of the fields mean anything.
- Cross-checks, which is where this earns its keep: a delivery date with no ship-to is reported as a freight blocker rather than an empty field. A quantity with no unit. A tolerance that is a general note rather than a callout. A certification required for a material nobody specified.
2 · Conflicting information
The same field stated two ways in two files.
- Nothing is merged and no winner is chosen. Both statements are shown, each against its own source line, and the contradiction is left for you.
- Restatements that mean the same thing are clustered rather than reported — "5052-H32 ALUMINUM" and "ALUMINUM 5052-H32" are one material, not a conflict.
- Conflicts are scoped to the part they affect, so one bracket disagreeing with the email does not mark the whole package as contradictory.
3 · Revision mismatch
A part at several revisions across the package, and documents that look superseded.
- The revision on a drawing title block is compared against the revision named in the email body and in the BOM.
- A part appearing at Rev A, Rev B and Rev C is reported once, with every file listed.
- A later revision of a part does not quietly supersede an earlier one. Both are reported; which one you quote is your call.
4 · Attachment problems
Nothing anyone else in this category treats as a first-class finding: whether the files themselves are fit to quote from.
- Unreadable, empty, and zero-byte files.
- Scanned PDFs and photographs that carry no text layer.
- Byte-identical duplicates, and the same content uploaded twice under two different names.
- Unsupported file types.
- Drawings with no material block and no revision block — a drawing you cannot identify the material of is not a drawing you can price.
- Part numbers that cannot be attributed to any file.
- Files containing instruction-like text, which is treated as data and never as a command.
5 · Ambiguity
Requirements that can honestly be read two ways.
- "As per previous", "standard finish", "as discussed", "TBD", "refer to attached" with nothing attached.
- A stated total that cannot be allocated to any part in the package.
- A tolerance given as a general note with no callout to tie it to a dimension.
- These are flagged for manual confirmation. They are never resolved, guessed, or picked apart for you.
The rule that outranks all of them
Every value in a report is evidence-gated before it is shown.
- The cited source segment has to exist in the parsed file.
- The quote has to appear verbatim in that segment.
- The value has to actually be supported by that quote.
- Fails any of the three and the value is dropped. The report shows a dash, which means "not established" — never "this field is absent" and never a guess.
What comes out the other end
- A per-field report where every value carries a source link opening the exact line, page, sheet or cell.
- Findings grouped by severity: critical for contradictions inside the package, missing for things nobody wrote down, warnings for file-level problems.
- A document inventory with a per-file status, so you can see at a glance which attachment is the problem.
- Processing notes — including a visible notice if the run was degraded because no model provider was reachable.
- Exports to PDF, Excel and CSV, so a report can be attached to a clarification email without being rebuilt.
See the sample reports for what these look like in practice.