From an item record to an answer you can check.
inRecipe reads technical documents, structures the information and keeps the evidence beside each value. Your team reviews the questions the evidence cannot settle.
One record. Several uses.
Enrichment establishes what the item is. The same specifications then support classification, sales descriptions and lifecycle research.
- 1Item data enrichmentOpen →
- 2Customs classificationOpen →
- 3Spare parts and aftermarketOpen →
- 4Successors and lifecycleOpen →
Next, not yet shipped: equivalent parts and alternative suppliers, own design, substances, medical devices, pages as evidence
First, it makes the record.
A code with what it rests on.
Parts your customers can find, your people can quote.
What the maker discontinued, and what it names instead.
Item data enrichment
Resolve the manufacturer and part number. Extract weight, dimensions, material and technical attributes where evidence exists.
Values read from documents cite the page. Values computed from a standard are labelled accordingly.
Explore item data enrichment →Customs classification
Review proposed classifications alongside their reasoning and the information still missing.
Held, proposed and not claimed remain distinct. A proposed code waits for your team to confirm it.
Explore customs classification →Spare parts and aftermarket
Create consistent item names and short sales descriptions from supported specifications.
Missing attributes remain visible, so a polished description does not hide an incomplete record.
Explore spare parts and aftermarket →Successors and lifecycle
Record what the manufacturer says about an item’s lifecycle and the successor it names.
Other replacement candidates are labelled as candidates for review.
Explore successors and lifecycle →Follow a value back to the page.
A source chip shows the document and page behind a value. The supporting quotation is checked against that page; if it cannot be found, the value is not shown as checked.
Computed values and composed descriptions are labelled so their basis stays visible.
An empty cell is a result.
“Missing” can mean different things. inRecipe keeps those differences visible.
- Searched, not found
- The value was not found in the sources checked. The record shows where the search looked.
- Not applicable
- The field does not apply to this item.
- Needs a person
- The evidence leaves a question unresolved.
| Item | Country of origin |
|---|---|
| KC-18-3P-24D | Germany p. 4 |
| 4410-0218 | searched, not foundMaker site, 2 distributors |
| ISO 4017 M12 × 40 | not applicable |
When sources disagree, the disagreement stays visible.
Two different weights do not become one apparently certain answer. Both values and their sources are presented for review.
Your team controls which evidence belongs.
A document is linked to an item through a recorded decision: a person’s decision, or a rule your team sets and checks on a sample.
That decision can be reversed. At the next build, values relying on a removed link are no longer admitted from that document.
See what happens when a document link is removed
Your data stays dedicated to you.
Your items, documents and decisions run in a dedicated space in the EU. Your data is not used to train models, and your item codes do not enter a shared library.
Start with a file. Continue on your cadence.
Start
Review 100 to 200 of your own items in week one. If you continue, inRecipe enriches the agreed scope and delivers the results for import into your systems.
Live
Enrich new and changed items as they are created. Re-read affected values when a source changes, and route unresolved cases to your reviewers.
Your ERP, PDM or PIM stays in place. Results can be delivered through file exports, the review workbench or the inRecipe API.