From Bale to Data: Building a Digital Record for Every Scan

There's a version of NIR identification that stops at the identification itself. The device gives a reading, the operator makes a routing decision, and that's the end of it. The reading exists in the operator's head for a few seconds, then it's gone.

That's a useful tool. But it's not the same thing as a material data infrastructure. And increasingly, it's the infrastructure, not just the identification, that the industry is being asked to build.

What a scan record actually contains

Every FabriTell scan creates a timestamped record: fibre ID, operator, batch, and location.

When a Matoha device scans a material and that scan is logged to the cloud, it creates more than a fibre identification. It creates a timestamped, located data point that links a specific identification result to a specific moment, operator, and device. Over hundreds or thousands of scans, that adds up to something useful: a documented material flow.

The data structure behind each scan typically includes:

Individually, each of these is a small data point. Collectively, across an operation's scanning activity over weeks and months, they form a picture of what material passed through that operation, when, and what it was identified as.

Why this matters for compliance

The regulatory environment around material traceability is tightening, in multiple directions simultaneously. The EU Digital Product Passport will require textile products to carry verifiable information about material composition. EPR schemes, for textiles in the UK and across Europe, and already operational for plastics, are creating data requirements for downstream sorters and recyclers. Due diligence regulations are asking brands to document material provenance further back in the supply chain.

None of these frameworks specifies exactly how material data should be captured. But they share a common implication: weight estimates and verbal declarations are not going to be sufficient as evidence. What they're pointing toward is documented, auditable, scan-level records, the kind of data that exists as a log you can show an auditor, not a number you calculated from a spreadsheet.

The buyer verification use case

Compliance aside, the immediate commercial value of scan records is in buyer relationships. When you sell a bale with a composition claim and the buyer does their own QC on delivery, there are two possible situations. Either your claim is accurate and their test confirms it, or there's a discrepancy and you need to resolve it.

If you have a cloud record of the scans that underpinned your composition claim, showing identification results, timestamps, device and operator, you're in a much stronger position in a dispute than if the claim was based on visual assessment. The record doesn't guarantee you're right. But it documents your basis for the claim in a way that's defensible and auditable.

Operations that share scan-level data proactively, as part of their delivery documentation, report that buyers who test on arrival gradually reduce their testing frequency on material they trust. Trust built on evidence is more durable than trust built on relationship.

The aggregation opportunity

One of the things that becomes possible when you have a body of scan data, rather than individual identification results, is aggregation. A month of scanning at a sorting operation produces a picture of what the incoming material stream actually looks like: not what the supplier declared, not what the category would suggest, but what the device found when it measured it.

This data is commercially valuable in several ways. It informs purchasing decisions, if you know that a particular supplier's "cotton" bales are running 15–20% blended at intake, you can factor that into your price. It informs operational decisions, if you know your incoming wool stream contains a certain proportion of fine fibres, you can plan your high-value sort accordingly. And it informs investor or sustainability reporting, where documented material flows are increasingly expected rather than optional.

How Matoha Cloud works in practice

Every Matoha device, FabriTell, PlasTell, and CarpeTell, syncs scan data to the cloud automatically when connected. Operators don't need to do anything beyond their normal scanning workflow; the data record is created as a side effect of the identification.

The dashboard gives operations visibility across their scanning activity: identification results by time period, breakdown by fibre type, export to CSV or integration-ready formats for reporting. Batch tagging lets operations link scans to specific jobs, purchase orders, or processing runs for more granular reporting.

For operations with multiple sites or multiple devices, the cloud view aggregates data across the estate, giving operations managers a picture of material flows at portfolio level rather than just facility level.

The infrastructure question

There's a version of this that sounds like a data project, something to think about when the operation has more capacity. But the operations building scan-level records now are doing it the practical way: they're just scanning, logging to cloud automatically, and accumulating a data asset as a side effect of their existing identification workflow.

The infrastructure isn't a separate project. It's what happens when the identification tool logs its results somewhere persistent, rather than leaving them in the air.