Traceability on Demand: A Three-Edge Walk Across Data You Already Have

The lot number arrives in a late-night email from a supplier. Quality flags a possible contamination on RM-88432, and the plant manager needs to know: Which finished goods contain this raw material lot? Which customers got them? What trucks are scheduled for tomorrow morning?

IT is already awake. The request is familiar. It sets off a two-day scramble across the ERP, the MES, the supplier portal, and a dozen spreadsheets that marry IDs nobody else can match. Acknowledging the request, the IT analyst says, "We'll get you an answer as soon as the data is reconciled."

The answer is not a data problem. It is a meaning problem.

Most factories approach traceability the same way: they treat it as a master-data cleanup project. The thinking goes—if we build one giant repository where all part numbers, lot numbers, customer IDs, and work orders are normalized into a canonical scheme, then any trace will be a simple SQL join. So they launch an MDM initiative. They hire consultants to map fields, deduplicate vendors, and build ETL pipelines. They promise traceability in eighteen months, after the data lake is filled and the governance council agrees on a common dictionary.

Eighteen months later, the project is still stuck in Phase One. The supplier master alone has 4,000 duplicates. The MES uses a different lot format than the ERP. And even when the data is parked in a massive warehouse, no one trusts it because the refresh is nightly and the floor has already moved on.

Meanwhile, the plant manager still waits for answers. The traceability report that was supposed to be a drag-and-drop export remains a custom query that a seasoned analyst wrote at 2 a.m. The system of record stores a lot number, but it doesn't know that lot number is shared with a work order in another system.

Here is the inversion that flips the approach: traceability is not a property of your data quality. It is a property of the connections between records that already exist. Every lot receipt, every work order release, every material consumption event is already timestamped and stored. The relationships between them are not explicit, but they are inferable if you know the semantics.

A lot is received against a purchase order. The same lot is consumed by a work order. That work order yields finished goods with a different lot number. Traceability is simply walking from one record to the next across these edges. It is reachability. In graph terms, it is a three-edge walk:

```
Supplier Lot -> Receipt Event -> Work Order -> Consumption Event -> Finished Goods Lot
```

Each edge is a business fact. The receipt event says "this lot came from this supplier on this PO." The consumption event says "this work order used this lot." The work order's output says "these finished goods came from this work order."

The data is there. The ERP has the PO and receipt. The MES has the work order and consumption. The issue is that no system speaks the other's language. The ERP calls a lot "BATCH-123"; the MES calls it "Lot#123". The dates are formatted differently. The IDs are not foreign keys.

But these gaps are surmountable—not by moving data into one database, but by building a semantic layer that knows the meaning of each field and how concepts relate. This layer doesn't hold the data. It holds the ontology: "Lot" has an identifier, "arrived via" a receipt, "was consumed by" a work order. Map the ERP's BATCH field to the concept "Lot", the MES's Lot identifier to the same concept, and you have the edge. Now the walk is a query, and it returns the answer in seconds, not days.

We call this the derived context layer. It is not a new system of record. It reads from existing export APIs, database views, or event streams. It does not write back. It does not require a single consistent identifier across all systems. Instead, it defines a set of shared concepts and relationships, then maps each system's fields to those concepts.

For a traceability query, the layer executes the traversal. No ETL into a warehouse. No last-known-good copy. The source systems remain the source of truth. The semantic layer is a pure compute function of the data that already exists.

The mechanics look like this:

1. The ERP exposes a view of inventory transactions, each with a material ID, lot number, receipt reference, and timestamp.
2. The MES exposes a view of work order operations, each with a feed lot list and the output lots produced.
3. The semantic layer contains an ontology model: "RawMaterialLot is linked to PurchaseOrder by Receipt"; "WorkOrder consumes RawMaterialLot via MaterialConsumption"; "FinishedGoodsLot is produced by WorkOrder."

A query for a given raw lot then expands along the edges. The key point is that the expansion is done by following semantic definitions, not by joining tables on shared keys. The mapping might require a small lookup—for example, converting the ERP's lot label format to the MES's—but that is configuration, not data cleanup. It can be done in weeks because it does not require harmonizing all master data across the enterprise. It only requires mapping the fields pertinent to the supply chain context you care about.

And if a field is inconsistent—say, a lot number is blank in an old transaction—the layer can return a partial path with a clear marker, instead of failing the entire query. This is a profound shift: you don't need perfection to get a useful answer.

When traceability arrives on demand, the operational rhythm changes. The quality manager gets her answer before the morning stand-up. She can see that the suspect lot entered two work orders yesterday, producing three finished-goods lots, one of which is on a 6 a.m. truck. She can recall that truck, not by searching through emails, but by executing the same computed walk.

The IT organization also feels the difference. No rip-and-replace of the ERP. No new data warehouse. The semantic layer is a lightweight service that consumes existing APIs and, optionally, returns the audit trail of every query. Because it never writes back, it cannot fork the ERP's truth. It does not create a shadow system—it is more like an operational cortex, interpreting the signals from the systems of record.

And you don't have to wait for a master-data remediation program. That program can proceed on its own timeline; the semantic layer goes live first. This is not a claim that data quality doesn't matter. It does. But it is not the gate to traceability. The gate is semantic mapping, which is a much smaller effort.

We've described the mechanism and the arithmetic. If you want to dig into the actual graph model—how the ontology is defined, how the edge mappings are expressed, and how the traversal is optimized—we've written a deep technical walkthrough with worked examples and a block diagram. It shows exactly how a three-edge walk resolves a traceability question, step by step, against live data.

That walkthrough is not a demo. It's a specification. It's available now.

Your ERP stores a date. It doesn't know that date is a promise. Your senior planners carry the meaning in their heads. That's the single point of failure. The semantic layer encodes the meaning, and traceability is just the first chapter. Once the meaning is computable, you can also compute a promised date from the schedule, or let an AI suggest a replenishment option with a clear rationale. But that's later. The immediate step is to read the walkthrough and see the graph.

Start with the walkthrough.