A standard, not another system

One JSON. One graph. The whole company.

The quote, the engineering BOM, the manufacturing BOM, the work order, and the invoice are five copies of one product. SingleBOM is the JSON graph they should all read and write.

The five copies

Catalog, config BOM, ATP, routing, invoice.

Marketing, Sales, Operations, Manufacturing, and Billing each keep a product. They give it different names. They are still copies.

01
Marketing
The catalog. Name, claim, published offering. What the product is allowed to be called.
02
Sales
The sales / config BOM. Options, price, promise. What CPQ is allowed to quote.
03
Operations
Available-to-promise. Plant, lead, inventory. What can actually ship, and from where.
04
Manufacturing
The routing and the MBOM. How the thing is built — not how it was sold.
05
Billing
The invoice and rev-rec. What gets charged, in what unit, and when it is recognized.

A nightly integration does not fix this. It copies last night’s snapshot from one system into another. It does not decide who owns the product. When an ECO lands, CPQ, PLM, ERP, and MES each store a new revision. The decision that produced it is in none of them. Ownership stays split; the copies stay copies.

What it looks like

One object. Nodes, edges, five writers.

An invented SingleBOM for a configurable industrial window. Not a customer record. The graph is how the thing is built; the function blocks are what each desk is allowed to write.

invented example · Cascade 440 commercial windowsinglebom.json

{
  "$schema": "https://singlebom.com/schema/v0",
  "id": "bom.win.cw-440",
  "sku": "CW-440",
  "name": "Cascade 440 Commercial Window",
  "kind": "configurable",
  "graph": {
    "nodes": [
      { "id": "frame", "item": "thermally-broken aluminum frame", "qty": 1 },
      { "id": "glazing", "item": "insulated glass unit", "qty": 1 },
      { "id": "hardware", "item": "projected-casement hardware set", "qty": 1 }
    ],
    "edges": [
      { "from": "frame", "to": "glazing", "rel": "contains" },
      { "from": "frame", "to": "hardware", "rel": "assembles" }
    ]
  },
  "options": {
    "width_mm": 1400,
    "height_mm": 2100,
    "finish": "anodized-clear",
    "glazing": "low-e-argon-double"
  },
  "functions": {
    "marketing": { "title": "Cascade 440", "segment": "commercial-envelope" },
    "sales": { "list_usd": 1840, "lead_days": 21 },
    "ops": { "atp": 14, "plant": "aurora-il" },
    "manufacturing": { "routing": "cut-assemble-glaze-qc", "minutes": 96 },
    "billing": { "rev_rec": "point-in-time", "uom": "each" }
  }
}

Invented example of a configurable industrial window. Not a customer record.

Why a standard, not another system

The interchange those systems should speak.

CPQ is built for exploration: what can be sold, under which rules. PLM is built for the engineering record. ERP is built for execution — inventory, routing, cost. Each is right about its moment. None of them is a good place for the other two to live.

Vendors already describe graph product models and xBOM: several views projected from one structure. That architecture is correct. SingleBOM’s claim is narrower. The structure should be a JSON standard those systems write, not a competing workspace that asks them for a nightly export.

A 150% / constraint model should change once. The quote, the MBOM, and the invoice should be views of that change, not three edits.

Why this matters for AI

A model quotes the product it is given.

If the company has five products, the model will quote the wrong one.

Who should write

People who already have two systems that disagree.

Discrete manufacturers and quote-to-cash people who already run two or more of: a Salesforce, Oracle, Tacton, or Infor CPQ; a PLM; an ERP. If the quote, the production BOM, and the invoice already disagree on one product, you are the reader.

Reach out

Send the copies that already disagree.

Email sales@singlebom.com three artifacts from one product: the quote (or a CPQ export), the manufacturing BOM, and the invoice or sales order. Redact customer names if you want.

We write back with the drift — where the three already disagree. Not a demo video.

The first look is free, and the next step is a paid pilot — one product on one JSON.

sales@singlebom.com

Catch-all works. Anything @singlebom.com reaches the same inbox.

What the field is saying

The argument is not new. The copies are.

After forty years the field still argues EBOM versus MBOM, and PLM versus ERP ownership. A digital BOM that is a list in a database is still a list. Change is the stress test: systems store the new revision, not the decision.
Oleg Shilovitsky, Beyond PLM, January 2026 · beyondplm.com
Fragmentation and handoffs are still the operating model. Excel survives because it transmits between divisions.
2026 BOMversation / The Future of PLM · youtube.com
When the CPQ-generated BOM does not match the engineering or production BOM, production starts from the wrong spec, procurement orders the wrong components, and service arrives without the parts that shipped.
Aleysian, May 2026 · aleysian.com
An ECO forces the same product knowledge to be updated in CPQ, PLM, ERP, and MES. A constraint model should change once.
Tacton · ECOs · digital thread
CPQ knows the configuration rules. ERP knows BOMs and routings, not the rules that produced the product. Manual transfer of a complex configured BOM is where options get dropped.
Marini · marini.systems