Polymr is one system that runs every workflow we ship. It sits as an overlay on top of the ERP you already use. Below: the six steps every workflow goes through, a closer look at how Polymr decides what to do (rules first, AI only for the gaps), and the screen your team uses to approve anything that touches your ERP.
A supplier quote in an email and a CAD revision pushed from SolidWorks run through the exact same six steps, in order. Each step is built in, not a separate module you pay extra for.
Messy inputs become clean, structured records.
Supplier emails, CAD revisions, EDI documents, vendor portal pulls, and operator clicks all land in one inbox. Polymr reads each one against the rules for that source, turns the contents into a clean record with a confidence score on every field, and keeps a link back to the original document. Nothing further down the line ever sees raw free text.
One live picture of the plant, with the source behind every value.
Six things (Items, BOMs, Routings, Inventory, Suppliers, Open POs) are kept in sync with your ERP and other systems of record at the field level. The engine never reaches into SAP or NetSuite directly. It reads this shared picture, and the picture tells you both the current value and where that value came from.
Rules first. AI only for the gaps.
A hand-written set of rules runs against the structured facts from the previous step. The first rule that matches wins and gets logged on the recommendation. Only the cases the rules cannot cover get handed to an LLM, with the relevant facts already in hand. The LLM never writes free text back into the workflow.
Six kinds of signal funnel into one action.
New emails, ERP updates, scheduled jobs, file drops, portal polls, and operator clicks all funnel into one place. Related signals (the same vendor, the same item) are held briefly so they get acted on together instead of fighting each other. Two checks run before anything fires: are the facts current, and are the rules satisfied. Only the signals that pass both checks become an action.
Every external write waits for a named person.
Approval is built in, not an optional setting. The queue shows one row per pending write to your ERP or to a vendor, scoped to the operator’s role and plant. Each row shows what Polymr wants to do, why it wants to do it, what data it read, and which systems it will touch on approval.
Safe retries. No duplicate records. Every write logged.
Every write back to your ERP or a vendor system carries a key tied to the smallest natural unit the destination understands. If a retry fires, the destination recognises the key and refuses the duplicate. A storm of retries never creates a second PO. Anything that genuinely fails surfaces in the console with the full payload preserved, never silently dropped.
We use both rules and AI on purpose. Plain rules handle the cases your team already has standard answers for. The LLM only gets called for the leftover cases that need judgment, and it never writes free text back into the workflow.
Hand-written rules over typed facts. The first rule that fires wins and gets logged on the proposal.
Narrow prompt with the same typed facts pre-loaded. Output is always a structured proposal, never free text.
The console is the screen your buyer, planner, or engineer actually works in. Anything that writes to your ERP passes through it. The vendor scorecard below is one example: a single supplier broken down into the grades that drive its rolling score, with the last five POs on the same panel. Every number traces back to the document that produced it.
V-218 · Trailing 90 days · 14 POs · 2 RFQs
| PO | Item | Qty | Promised | Landed | Variance |
|---|---|---|---|---|---|
| PO-84211 | PMR-4031 | 280 | 2026-05-22 | 2026-05-22 | on time |
| PO-84179 | PMR-CN-44 | 440 | 2026-05-18 | 2026-05-27 | + 9d |
| PO-84142 | PMR-4031 | 320 | 2026-05-09 | 2026-05-10 | + 1d |
| PO-84094 | PMR-4406 | 180 | 2026-04-28 | 2026-04-28 | on time |
| PO-84028 | PMR-4031 | 240 | 2026-04-17 | 2026-04-16 | - 1d |
