Six core capabilities — built specifically for discrete manufacturing. Not a generic integration tool adapted for engineering.
When a BOM is exported from CAD, every line is structurally identical: a part number, a description, a quantity. The manufacturing reality behind each line is far more complex. A bearing housing needs to be machined. A gearbox needs to be purchased. A phantom sub-assembly should never appear in the ERP at all. Getting this wrong means incorrect item types, wrong procurement routes, and purchasing errors that surface weeks into a project.
The classification engine analyses each BOM line against a configurable ruleset that combines naming conventions, material codes, CAD properties, and organisational procurement policies. The output is a definitive item type assignment for every line — before a single record is written to your ERP.
The 14 types span the full range of discrete manufacturing item categories: fabricated weldment, machined component, bought-out item, phantom assembly, raw material (sheet, bar, tube, plate), standard fastener, electrical assembly, hardware kit, documentation placeholder, and four configurable custom types for organisation-specific classifications. The ruleset is defined in a YAML manifest that your engineering team controls — not locked inside a vendor's database.
Classification runs at the normalisation stage of the pipeline, before validation. Items that cannot be confidently classified are flagged for human review at the first approval gate rather than defaulting to an incorrect type silently.
| Stage | Input | Output |
|---|---|---|
| 1. BOM Ingest | Raw BOM lines from CAD (part no., description, qty, material) | Normalised BOM with intake ID assigned to each line |
| 2. Convention Match | Part number against naming convention regex rules | Candidate item type + confidence score |
| 3. Property Analysis | CAD custom properties (Material, Mass, Finish, Process) | Refined candidate type or disambiguation flags |
| 4. Policy Application | Organisational procurement policy ruleset (YAML) | Final assigned item type (1 of 14) |
| 5. Approval Gate | Items below confidence threshold or policy conflict | Human-reviewed classification or override |
| 6. ERP Write | Confirmed item type + all validated metadata | ERP item created with correct type, routing, and attributes |
Engineering revisions are routine. The problem is that once a BOM has been entered into the ERP, knowing exactly what changed between revisions requires either manual comparison or trusting that the CAD system's change management was followed perfectly. Neither is reliable at scale.
BOMDiff is a structural comparison engine that takes any two BOM states — two CAD revisions, a CAD revision and the current ERP state, or two historical ERP snapshots — and produces a deterministic, line-by-line delta. The output identifies: lines present in A but not B (removed), lines present in B but not A (added), and lines present in both with changed attributes (modified). Modified lines carry a field-level breakdown showing exactly which attributes changed and from what value to what value.
The comparison is structure-aware, not text-based. Part number changes that indicate a revision are handled differently from description typo corrections. Quantity changes on sub-assemblies are flagged distinctly from quantity changes on bought-out items, because their downstream procurement implications differ.
BOMDiff runs as a mandatory step before any ERP update is written. The diff output is presented at the approval gate so the reviewing engineer can see precisely what the pipeline intends to change — not a summary, the full change set. The approval is timestamped and recorded in the audit chain.
| Operation | Input | Output |
|---|---|---|
| Source Load | BOM A (CAD file or ERP snapshot) + BOM B (new revision) | Two normalised BOM trees with stable line identifiers |
| Tree Match | Normalised trees; match by part number + level | Matched, unmatched-A, and unmatched-B sets |
| Attribute Diff | Matched line pairs with all attributes | Per-field delta: field name, old value, new value |
| Impact Score | Change type + item classification | Risk flag: Low / Review Required / Procurement Impact |
| Approval Gate | Full diff output presented to reviewing engineer | Signed approval with timestamp + diff hash |
| ERP Delta Write | Approved diff + original ERP record IDs | Targeted ERP updates (not full re-create) |
When something goes wrong in manufacturing — wrong material ordered, incorrect revision built, non-conforming part shipped — the investigation always starts with the same question: what happened and when? In a manual CAD-to-ERP workflow, that question is often unanswerable. Nobody recorded who entered the data, which revision of the drawing they were looking at, or whether anyone checked it.
Every event in the Micro-Connectors pipeline generates a tamper-evident audit record: connector run starts and stops, data extracted, validation outcomes, approval decisions, ERP writes, and error conditions. Each record contains the event payload, a timestamp, the identity of the operator or system actor, and a SHA-256 hash computed over the event data and the hash of the preceding record. This produces a hash chain: any tampering with a historical record invalidates the hash of every subsequent record.
The audit trail is stored separately from the operational database and can be exported in JSON or CSV format for external compliance systems. The chain can be independently verified without access to the Micro-Connectors system itself — only the raw event records and the hashing algorithm are needed.
Audit records are immutable once written. There is no edit operation, only a correction record that references the original and records who made the correction, when, and with what authorisation. This design satisfies ISO 9001 traceability requirements and supports AS 9100 aerospace manufacturing documentation standards.
| Record Type | Captured Data | Chain Role |
|---|---|---|
| Run Start | Intake ID, file hash, operator, connector version, timestamp | Chain anchor for this pipeline run |
| Extraction | Extracted fields, source file hash, extractor used | Links CAD file state to extracted data |
| Validation | Rules evaluated, pass/fail per rule, flagged items | Documents what was checked and what passed |
| Approval Decision | Approver identity, decision (approve/reject/override), diff hash | Human accountability record |
| ERP Write | ERP system, record IDs created/updated, payload hash | Links approval to ERP state change |
| Error / Exception | Exception type, stack reference, remediation taken | Documents failures and how they were resolved |
The cost of an ERP mistake in manufacturing is not a database rollback. It is a wrong purchase order, a build that begins on the wrong revision, or an item that gets created in the ERP with an incorrect unit of measure that propagates through every document that references it. Prevention is the only viable strategy.
Dry-run mode executes the complete pipeline — extraction, normalisation, classification, validation, BOMDiff, and the full ERP write logic — against a read-only connection to your live ERP. No records are created or modified. Every operation that would have been performed is recorded, and the output is a complete simulation report: items that would be created, items that would be updated, items that would be flagged, and items that would fail ERP validation rules.
The simulation report is generated in the same format as the live pipeline output, which means it can be reviewed and approved through the same approval gate workflow. An engineer can approve the dry run, review the simulation report at leisure, and then trigger the live run with confidence that the outcome will match the simulation exactly.
Dry-run mode is available for all pipeline stages and all connector types. It is the recommended first step when onboarding a new product family, introducing a new naming convention, or upgrading to a new ERP schema version.
| Stage | Dry-Run Behaviour | Live Run Behaviour |
|---|---|---|
| Extraction | Full extraction; identical to live | Full extraction; identical |
| Normalisation | Full processing; identical to live | Full processing; identical |
| Validation | All rules evaluated; identical to live | All rules evaluated; identical |
| ERP Lookup | Read-only queries to live ERP | Read-only queries to live ERP |
| ERP Write | Writes captured in simulation report; no ERP changes | Records created/updated in ERP |
| Audit Trail | Dry-run record written; flagged as simulation | Full production audit record written |
Automation in engineering workflows must be bounded. The goal is not to remove engineers from the process — it is to remove the mechanical, error-prone work of data re-entry so that engineers can focus on the decisions that require human judgement. Micro-Connectors enforces this boundary through nine mandatory approval gates, one at each critical transition in the pipeline.
Gates are not optional checkpoints that can be bypassed with a configuration flag. They are structural stops in the pipeline. No BOM proceeds to the next stage until the gate has received an explicit approval from an authorised user. The approving user, their role, the timestamp, and the specific data they approved are all recorded in the audit chain.
Gate configuration controls who can approve at each stage. The extraction approval gate may be appropriate for a CAD engineer. The ERP write gate may require a department head sign-off. Approval roles are mapped to your organisation's existing Active Directory or Azure Entra ID groups — there is no separate user management system to maintain.
Gates can be configured to require dual approval for high-value items — for example, any BOM write that would affect more than 50 ERP records, or any item where the procurement impact exceeds a configurable dollar threshold. These thresholds are defined in the policy manifest alongside the classification rules.
| Gate | Pipeline Position | Typical Approver |
|---|---|---|
| G1: Intake | After file receipt, before extraction | CAD engineer or design lead |
| G2: Extraction | After metadata extraction, before normalisation | CAD engineer |
| G3: BOM Structure | After normalisation, before classification | Design or systems engineer |
| G4: Classification | After item type assignment | Engineering lead |
| G5: Validation | After all validation rules pass | Engineering lead or operations |
| G6: BOMDiff Review | After diff against current ERP state | Engineering lead |
| G7: Procurement Impact | Before any procurement-classified items are written | Procurement manager |
| G8: ERP Pre-Write | Final check before live ERP write | Department head or operations director |
| G9: Post-Write Verify | After ERP write, confirming records as expected | Engineering lead or QA |
Item classification determines what kind of thing a BOM line is. Procurement classification determines what your organisation needs to do to obtain it. These are distinct questions, and conflating them is a common source of errors in ERP data: bought-out items marked as make-in-house, raw materials without a supplier assignment, fasteners created as unique parts rather than catalogue items.
The procurement classification layer runs after item type assignment and applies a second ruleset that maps each item type to a procurement action. The possible outcomes are: fabricate in-house (route to workshop with the appropriate work order type), raise an RFQ (no existing vendor agreement), purchase against an existing vendor PN (supplier catalogue item), or match to an existing ERP catalogue record (do not create a new item).
Vendor PN matching queries a configurable vendor catalogue that can be synchronised from your existing ERP supplier database. When a match is found above the confidence threshold, the existing vendor PN is attached to the BOM line and flagged at the procurement approval gate for human confirmation. When no match is found, the item is flagged as requiring an RFQ before the purchase order can be raised.
The procurement classification output directly populates the ERP item fields required to route items correctly: item type, procurement type, preferred vendor, lead time category, and make/buy flag. These fields are set in the ERP write operation — not left blank for someone to fill in later.
| Item Type | Processing Step | ERP Outcome |
|---|---|---|
| Fabricated / Machined | Classify as make-in-house; assign work order template | Manufactured item with routing; no PO required |
| Bought-Out (vendor match) | Vendor catalogue lookup; match above threshold | Purchased item with vendor PN; PO-ready |
| Bought-Out (no match) | Vendor catalogue lookup; no confident match | Purchased item flagged RFQ Required |
| Phantom Assembly | Identified as simulation-only structure | Suppressed from ERP; not created |
| Raw Material | Material code mapped to stock category | Stock item with UoM and material grade |
| Standard Fastener | Cross-referenced against fastener catalogue | Catalogue item; consolidates with existing records |
Book a 30-minute technical demo. We'll use a real assembly BOM from discrete manufacturing and walk you through each stage of the pipeline.
Book a DemoNo credit card required. No commitment.