Carbon: Squeezing Three Manufacturing Layers Into One Product

Your first day at a large metal fabrication shop. The operations manager takes you to the shop floor.

“Tell me the status of these machines,” they say.

You start checking. Machine PLC says “Makina-5 is running Job #2847, 65% complete, estimated finish 14:32.” But the ERP shows Job #2847 as “Pending,” logged as started 2 hours ago. The MES says “Running on Makina-4, 50% done.”

The manager asks: “Which one is true?”

Your answer: “I don’t know which has the latest data.”

This problem stems from software architecture. ERP is one application, MES is another, QMS is a third. Each keeps data in its own database. There is messaging between them—APIs, file transfers, MQTT connections—but these carriers are slow, fragile, and sometimes reverse data.

Open-source Carbon takes a different approach to this layering problem: Don’t keep three layers separate. Unite them in a single data model.

Why ERP, MES, and QMS Are Separate

Historical reason: In the 1980s–1990s, ERP systems were about planning. Purchasing, accounting, production scheduling. What actually happened on the shop floor was unknown or known very slowly. PLCs kept machine logs, but there was no software link.

Then in the 2000s, MES software appeared. Real-time data: Is the machine running? Which job? Product quality? MES was designed to capture all live factory information.

QMS (Quality Management System) was a separate concern: measurements of each part, test results, why did a defect occur? QMS recorded this.

Result: Three systems, three databases, three interfaces.

Problem: integration cost, data duplication (written in ERP and in MES), synchronization lag.

Carbon’s Approach: One Data Model

Carbon (GitHub: carbondatalabs/carbon) is open-source and makes an argument: why keep them separate? Manufacturing work flows from planning through real-time execution—it is one process. Write data once, let everyone read it.

Sample scenario:

Monday 06:00 — Production Planner

Orders arrived. 10 units of Product X, 12 units of Product Y. In Carbon, the planner writes the plan:

• Job #3001: 10 × Product X, Machine-1, 2 hours, start 08:00
• Job #3002: 12 × Product Y, Machine-2, 1.5 hours, start 08:30

This information is scheduled by the MRP engine based on resource constraints (machine availability, labor, material stock—all checked in the same data model). If material is short, Carbon auto-opens a purchase workflow.

Monday 08:00 — Shop Floor

Operator opens the Carbon interface (or kiosk). Job #3001 starts on Machine-1. Carbon:

• Fetches the BOM (Bill of Materials): Product X needs Material A 2 kg, Material B 1 kg
• Deducts 2 kg of Material A from stock
• Logs “Job started, Monday 08:00” from the PLC or operator input

Monday 08:15 — Quality Control

A sample is drawn from Machine-1. QMS module (inside Carbon) measures it: dimensions OK, color OK, weight OK. Carbon writes “sample passed test” to Job #3001.

Monday 10:00 — Completion

Job #3001 is done. Operator hits “Complete.” Carbon:

• Stops the Machine-1 timer
• Adds 10 units to stock
• Calculates job cost (Material A + B cost, machine hours, labor)
• If the job is linked to a customer order, notifies “Job complete, delivery in 2 days”

All this workflow happens in one database. ERP doesn’t wait for an MES message saying “Job done.” MES doesn’t see an outdated plan in ERP. Everyone reads from the same source of truth.

Open API and AI Agents

Another Carbon feature: open API. The data model and business logic are documented. External software (for example, a customer portal, a product design platform) can connect directly to Carbon.

Even AI agents can be plugged in. Example: A scheduling agent watches shop load and suggests “If Job #3003 starts 1 hour earlier, total throughput gains 30 minutes.” Or a procurement agent monitors stock levels and auto-opens purchase orders. Because Carbon’s data model and API are open, such agents can be written.

Built on Supabase

Carbon is built on Supabase, an open-source Postgres backend. What does that mean? The database is yours. You run it on your own server or in the cloud. You write your own queries, build custom reports. SAP doesn’t offer this.

What Changes in Practice?

1. Integration Cost Drops: You don’t write message passing between three systems. One system.

2. Data Duplication Ends: No same information existing in two databases with different values, old versions, or deletions.

3. Decision-Making Speeds Up: When the manager asks “Can we move this job 2 hours earlier?”, the answer comes in seconds because all information (planned jobs, machine availability, test status) lives in one system.

4. Custom Rules Are Codeable: Open source and open API mean you write code for your special rules. Example: “Defective part requires operator review, then retry”—you write this as a Carbon workflow, and the system enforces it.

Software like Carbon, unified in this way, is essential in Industry 4.0 factories where data-driven decisions happen hourly. If you manage hundreds of data points across different systems, you never see the full picture.

Being open-source is an extra bonus: you can modify the software to fit your own needs. It is not a locked system.