The shift from collecting supplier data to making it trustworthy.

TrusTrace was already helping global fashion brands manage supplier compliance — audits, assessments, traceability, sustainability reporting. The data existed. The problem was that it lived inside each module independently. The same certificate uploaded three times. The same supplier asked for the same document from three different contexts. No shared layer connecting any of it.

When a brand needed to file a due diligence statement with customs, they couldn't confidently say a certificate was valid, current, and applicable — because the same document might exist in four different states across four different modules.

SDM was built to fix that at the infrastructure level — a governed data layer sitting beneath every compliance module, with lifecycle states, explicit reuse confirmation, and AI-assisted extraction with human accountability gates. The most meaningful outcome wasn't speed. It was confidence in the data brands were making compliance decisions on.

Fashion brands operating under EUDR, UFLPA, and multi-jurisdictional regulatory frameworks file Due Diligence Statements with customs before market entry. Those filings reference supplier certificates, facility records, and compliance declarations. If the data behind those filings is fragmented, duplicated, or inconsistent — the filing fails. Shipments get detained. Brands get flagged.

That was the real risk. Not a usability problem. Not a workflow inefficiency. A structural gap that sat underneath every compliance decision the platform was supposed to support.

The platform already supported mapping, traceability, sustainability, and risk workflows. Each was well-designed in isolation. But supplier compliance data lived inside each module rather than being governed centrally.

As regulatory scope expanded and more brands onboarded, the fragmentation compounded:

Without a shared supplier data layer, the platform would generate operational noise at scale instead of compliance confidence.

Treating Supplier Data as Persistent Assets, Not Request-Based Uploads

The existing model was straightforward: a module needs data, it sends a request, the supplier uploads, and the data lives inside that module. It was simple and fast to build, but completely wrong at scale.

The alternative was to model supplier compliance data as long-lived assets — entities with their own lifecycle, ownership, validity period, and regulatory scope — that any module could reference rather than independently collect. This required more upfront data modeling and lifecycle logic before anything could ship.

But the cost of not doing it was higher. Every new regulation, every new module, every new brand would multiply the duplication. The platform would eventually collapse under the weight of its own fragmented data.

Lifecycle states replaced the binary upload-and-done model. Draft → Submitted → Approved → Expired. Each state had clear ownership, visible transitions, and audit-ready history. Compliance readiness became something you could see, not something you had to assume.

Making Reuse Explicit, Not Automatic

Once data was modeled as shared assets, the obvious next move was automatic reuse. A certificate approved in one module gets silently populated wherever it's needed — faster processing, less friction, fewer supplier requests.

The problem is that a certificate valid for one regulatory context isn't automatically valid for another. A GOTS certification covering a supplier's scope under EUDR traceability doesn't automatically satisfy a UFLPA chain-of-custody requirement. Silent reuse would mean a compliance officer approving a filing that references a certificate outside its applicable scope, without knowing it happened.

I kept reuse explicit. Before any data point is pulled into a new workflow, the brand reviewer sees what's being reused, where it came from, what regulation it was originally collected for, and whether it applies here. One extra confirmation step. Intentional friction.

Reuse became deliberate and traceable. Every cross-module data reference has a clear decision point behind it — a human who confirmed the scope applies. That's the accountability chain a customs filing needs.

One Regulation-Agnostic System With Overlays, Not Separate Flows Per Regulation

The simpler build was separate SDM flows per regulation. EUDR gets its own data collection experience, UFLPA gets its own, and the German Supply Chain Act gets its own — each optimised for its specific requirements and easier to scope and ship incrementally.

The cost appears later. Every new regulation requires a new flow. Every supplier interacts with a different experience depending on which regulation triggered the request. The same underlying data gets modeled differently three times. Maintenance compounds with every regulatory change.

I designed a single SDM system with regulation overlays — one unified supplier experience, one data model, one request framework — with regulatory configuration applied at the brand level. When one regulation's requirements shift, one system absorbs the change.

AI-Assisted Certificate Extraction With Governance Boundaries

As supplier volumes grew, certificate handling became the highest-friction point in the system. Suppliers uploaded PDFs and brand reviewers manually read them, identified the standard, extracted the certificate number, issuer, expiry date, and applicable scope. For a single supplier with four active certifications across three regulations, that's a significant manual effort per compliance cycle.

Full automation was the obvious call — certificate uploaded, system extracts, data populated, no human required. But certificate data feeds directly into regulatory filings. A misread expiry date or a wrongly identified certification standard doesn't just create a data error; it creates a false compliance assertion filed with customs authorities.

The extraction panel surfaces certificate name, number, issuer, expiry, and applicable certification standards with source highlighting so the reviewer can see exactly what the AI read and why. Low-confidence fields are flagged explicitly. Nothing is populated until the reviewer confirms.

Data collected once now flows into mapping, traceability, sustainability reporting, and risk workflows — without duplication, without conflicting states, without repeated supplier requests. Lifecycle visibility means teams know exactly what's valid, what's expiring, and what needs attention before a filing deadline hits.

The reduction in repeated supplier requests wasn't a usability win. It was a trust signal. Suppliers stopped receiving duplicate requests because the platform finally knew what it already had. That's what governance looks like at the data layer.