Digital Electronic Facility Record
The RBTP Knowledge Base is evolving weekly as part of our pilot programs with RBA members. We’d love your input — submit feedback or help shape the protocol in real time by joining a pilot.
Digital Electronic Facility Record (DEFR): Implementation Guide
If you're looking for an Overview, go to Digital Electronic Facility Record Overview
The Digital Electronic Facility Record (DEFR) is a commodity-specific extension of the UNTP Digital Facility Record. It is designed to meet the unique compliance needs of electrical and electronic goods producing facilities.
Before implementing a EFR, implementers should become familiar with the core UNTP DPP specification, which defines the base structure, vocabulary, and requirements shared by all passport types in the RBTP ecosystem
📦 DEFR Profile Information
| Name | Current Version | Status | Release Date | UNTP dependency |
|---|---|---|---|---|
| Digital Electronic Facility Record | 0.1.0 | Draft | 10-04-2025 | UNTP DFR v0.5.0 |
🔧 What Makes the DEFR Unique?
While a DEFR reuses the full UNTP DFR model, it introduces an additional specification layer with structures and rules tailored to electrical and electronic goods producing facilities. These include:
- A new
ElectronicFacilityRequirementsextension block (for facility producing and conformity details, etc.) - Stricter field requirements for product IDs, classification schemes, and traceability references
- Encouragement to use linked certificates wherever applicable
The DEFR is modular—not every facility product requires every field—but validators and CABs may enforce stricter conformance depending on your pilot or compliance target.
📐 Logical Model
A visual overview of the DEFR profile and extensions is available here:
📎 Logical Model: Digital Electronic Facility Record
Core structure: identical to the UNTP DFR with these additions:
ElectronicFacilityRequirements(new object block)
📏 Profile Rules
Note: This section outlines constraints and required patterns that make a valid DEFR
TBD
Note: This section defines strict dependencies and requirements for product information. For instance, the ID field may be required to originate from a designated register, ElectronicFacilityRequirements.safetyStandards must conform to recognized international standards, Claim.assessmentCriteria must be selected from predefined controlled vocabularies, etc.
| Field | Requirements |
|---|---|
id | Must be a globally resolvable URI (preferably did:web or GS1 identifier) |
locationInformation | Must show the map coordinates or polygon where the facility is located |
safetyStandards | Must refer to safety standards implemented on producing facility |
environmentalImpact | Must conform to environmental safety standards |
complianceRequirements | Must show the relevant compliance certificates |
A JSON Schema validator will be made available in a future stable release.
🛠 Technical Artifacts
These artifacts are in development. Once published, they will include:
- JSON-LD
@contextfor DEFR extension fields - JSON Schema validator for DEFR conformance
- Sample DEFR instances (e.g., car generator production facility, xEV battery production facility, etc.)
📝 Status: Draft format available internally via Notion; will be moved to RBTP GitHub once stable.
📄 Working Sample
| Clickable Link | Scan the QR | Comments |
|---|---|---|
| Digital Electronic Facility Record |  | This is a sample DEFR, work in progress. Click on the JSON tab to see the underlying RBTP data. Download the signed credential to test verification in your own system |