The why behind the how.

Because at quotation time the mistakes are free to fix — you adjust a line in a spreadsheet. The same gap discovered at PPAP costs tooling changes, re-validation and credibility. The first credible quote usually wins the platform; a quote with a documented coverage matrix is more credible than a lower price with silent guesses. That is why the compliance matrix is generated with the BOM, not after it.

We refuse to make it a checkbox. Each requirement is linked to the specific BOM lines that satisfy it and carries one of three states: covered (demonstrably satisfied, evidence attached), assumed (satisfied under a documented assumption — the state most tools hide, and the one that wins negotiations because the customer sees exactly what needs their confirmation), or gap (not addressed, visible immediately). An assumption without written evidence is rejected by design.

No retyping. Import ReqIF (what DOORS, Polarion and 3DEXPERIENCE export — the Lastenheft format of German automotive), Excel or CSV matrices (what you actually receive by email), or a system-model JSON if your customer works model-based. Requirements are automatically linked to BOM lines mentioned in their text, and model traces (satisfy/verify semantics, aligned with SysML v2) are honored.

It is a small, versioned, machine-readable format (JSON with a public schema) describing exactly how your BOM covers the requirements: per-requirement status, evidence, linked part numbers, coverage summary. It is open on purpose: your customer’s PLM, their CI pipeline or their own scripts can consume it without buying anything from us. Openness is what makes the answer trustworthy — a compliance claim in a proprietary format is just a promise with extra steps.

The opposite: Excel runs through the whole chain. Requirement matrices come in as .xlsx or .csv; the live BOM is edited in a spreadsheet view (with an AI copilot); the compliance matrix exports as a styled Excel workbook next to the JSON contract. We industrialize the Excel workflow instead of fighting it — adoption is a feature.

Standards in, standards out. We consume what your tools already export (ReqIF, STEP AP203/AP214/AP242) and produce an open contract they can ingest. On the enterprise tier we push validated BOMs and coverage into your PLM through its APIs. We deliberately sit at the supplier edge of the digital thread — where the OEM’s PLM does not reach — and hand the data back clean.

From the RFQ package. The engine extracts the assembly tree, quantities, dimensions and mass estimates straight from the STEP geometry — try it in the interactive demo, no account needed. On assisted pilots, AI reads the 2D drawings too: materials, surface treatments, tolerances and PMI land on the right BOM line. JT and native formats are handled on the on-premise enterprise tier.

That is up to your workflow — but the defaults are opinionated: a safety-critical requirement with status gap fails any consuming CI gate by contract rule, and the project’s kickoff gate shows coverage next to BOM completeness. The goal is not to slow quotes down; it is that nobody signs one blind.

Files are processed in the EU (Paris), demo uploads and derived artifacts are deleted automatically after 24 hours, and nothing is ever used to train models. Pilots run on a dedicated instance that shares nothing with anyone; enterprise pilots can run fully on-premise. Details on the Security page.

Bring one real RFQ package to a 30-minute call — you leave with the BOM and a first coverage matrix. Pilots run on a dedicated managed EU instance from €990/month, cancellable monthly during the pilot phase, setup with your templates included.