Skip to content

openEPD Principles

The openEPD standard format is Open, Standardized, Interoperable, Agile, and Secure.

Open

  • Free to read and to use. Participant(s) must disclose any IP rights (e.g. patents) required to implement the standard, and to license any such right(s) at no cost to other participant(s).
  • Posted and Documented on GitHub
  • BuildingTransparency.org provides key helper functions (e.g. unique ID code generation/check, checksum generation) as open-source reference code.

Standardized

  • Compatible with ISO 14025, EN 15804, and major North American PCRs.
  • Compliant to OpenAPI 3.0 standard
  • Compatible with ILCD+EPD
  • Compatible with MasterFormat and OmniClass

Interoperable

  • Should follow software best practice regarding separation of concerns, platform independence, and error handling.
  • Mandatory fields
  • Must be present in every valid openEPD
  • Have precise definitions
  • Must be understood and processed by an openEPD compliant system.
  • Optional fields
  • May be present or not present in a valid openEPD
  • Have precise definitions
  • Must not be required by an openEPD compliant system.
  • Should be stored (but not necessarily interpreted or used) by an openEPD compliant system.
  • Standard testing interface(s) and examples to help organizations build interoperable solutions.
  • Compatible with a wide variety of operating systems and database systems.
  • Versioned, so future releases can be backwards-compatible.

Agile

Every sector is different, and the sophistication of LCA is always increasing. openEPD will need to grow and develop in ways we can’t always foresee, but do so in a way that doesn’t break compatibility.

  • Standard extensions
  • Defined by sector-specific groups (e.g. concrete, steel, carpet …) based on sector PCRs.- Properties can be Mandatory or Optional for that sector extension.
  • Should be stored (but not necessarily interpreted or used) by openEPD compliant systems.
  • Extensions can be sub-extended as desired (e.g. concrete.masonry.property_name)
  • Custom extensions
  • Useful for experimentation and for proprietary extensions,- Can be defined by anyone with any format.
  • Should be transparently stored as JSON (but not necessarily interpreted or used) by openEPD compliant systems.

Secure

  • oAuth 2.0 and API key authentication.
  • Robust to code-injection and other standard vulnerabilities
  • Optional Digital Signature
  • Optional Data Integrity Field.