DPP domains change. The supplier evidence workflow should not.
Batteries and textiles have different schemas, evidence categories, and rollout pressure. Redy keeps the operating loop consistent: request evidence, approve claims, preserve provenance, and publish versioned passports.
Map the domain fields
Start with the domain-specific passport fields, then separate what the manufacturer knows from what suppliers must prove.
Request only missing evidence
Create scoped supplier requests for the fields and documents needed to make a claim publishable.
Approve and preserve provenance
Review supplier submissions, attach source context, and keep an audit trail before the DPP version is published.
Publish through the same output layer
Use the approved data in passport views, APIs, exports, webhooks, and resolver-ready patterns.
Start with the urgent domains, keep the system extensible.
Batteries
Active readinessHigh-urgency passport workflows with deep supplier evidence needs.
Battery programs need traceable material, recycled content, carbon, due diligence, and versioned publication workflows.
Textiles
Readiness trackMulti-tier supplier evidence for materials, chemicals, and circularity.
Textile DPP readiness depends on fiber composition, chemical safety, origin, care, repair, and reuse evidence across fragmented supply chains.
Future ESPR domains
ExtensibleThe same operating loop can support the next product categories.
Redy keeps request, evidence, approval, versioning, and output logic separate from any single domain schema.
Domain specificity belongs in field mapping, not in the whole product architecture.
A battery program should not force a separate platform from a textile program. Redy keeps domain logic modular while the supplier evidence workflow remains understandable to teams and auditors.
Map the domain fields
Start with the domain-specific passport fields, then separate what the manufacturer knows from what suppliers must prove.
Request only missing evidence
Create scoped supplier requests for the fields and documents needed to make a claim publishable.
Approve and preserve provenance
Review supplier submissions, attach source context, and keep an audit trail before the DPP version is published.
Publish through the same output layer
Use the approved data in passport views, APIs, exports, webhooks, and resolver-ready patterns.
The reusable unit is evidence, not a one-off page.
A supplier record can support multiple product requests when permissions, provenance, and review state are handled correctly.