ECLASS 17 EPD Header Data: From PDF Declaration to Structured Metadata

Most catalogs hold EPDs the way they hold datasheets: as PDFs linked to a product, readable one at a time by a person, invisible to any query. You cannot ask “which products have a valid EPD,” “whose declarations expire this quarter,” or “which tender lines are missing one” without someone opening files. ECLASS’s new aspect for EPD metadata, announced for the upcoming Release 17, is the fix at the standard level: it defines where the EPD’s own header information lives as structured attributes on the product.

ECLASS 17 is in development at the time of writing — plan for it, and confirm the exact aspect name and field set against the release documentation before you build, the same caution the ECLASS version migration playbook applies to any new release. Getting the EPD into the record is the same extraction-and-evidence pipeline behind turning any spec sheet into a trusted product record: a PDF becomes fields, each field carries its source, and the result is one attribute set every downstream decision can read.

Header data vs impact data

The two are designed to sit together. Header data is what makes the impact data trustworthy at scale: an impact figure without a current, identified declaration behind it is an unsupported claim, and a declaration whose validity you cannot see is a liability waiting to expire mid-tender.

The workflow

1. 1
   Locate the EPD for each product

   Inventory which SKUs have an EPD and which do not. Sources are manufacturer portals, programme-operator databases, and supplier document packs. The SKUs with no EPD are not failures to hide — they are a gap to record, so a tender or report can see it.

2. 2
   Extract the header metadata

   From each EPD, pull the header fields — the declaration holder or publisher, the programme or programme operator, the document version or registration number, and the valid-from and valid-to dates. Extract them into structured fields rather than leaving them in the PDF.

3. 3
   Resolve the declaration to the exact product or variant

   An EPD often covers a specific product, a variant, or an averaged product group. Confirm which it is, and attach it to the resolved product identity — not to a loosely similar SKU. A declaration bound to the wrong variant is worse than no declaration, because it reads as compliant while being inapplicable.

4. 4
   Populate the ECLASS 17 aspect

   Map the extracted header fields to the Release 17 aspect, keeping the source document, page and revision with each value so a reviewer can trace any attribute back to the declaration it came from. Confirm the aspect’s field set in the release documentation first — do not assume field names.

5. 5
   Monitor validity

   An EPD is valid only until its valid-to date. Track that date so that, on expiry, the attribute moves to a stale state and routes for refresh instead of continuing to look complete. An expired EPD is an evidence gap, not a filled field — the same freshness discipline every provenance-backed attribute needs.

Who asks for this

Three workflows turn structured EPD header data from a nicety into a requirement:

• Construction product tenders. Public and large private construction tenders increasingly require an EPD per product line. A buyer needs to filter a catalog to the lines that have a current declaration — a query against header data, not a manual file hunt.
• Sustainability and ESG reporting. Reporting needs to count, per product, whether a declaration exists and is valid, and to show the programme behind it. That is header metadata, aggregated.
• Digital product passport preparation. The EPD and its validity are part of the evidence a digital product passport will carry. Structuring it now, with provenance, is preparation for the passport rather than a separate project — and the same classification-season work as the ETIM 11.0 migration if you maintain both standards.

Make the EPD a trusted attribute, not an attachment

An EPD is only useful to a workflow once it is identity-resolved, extracted into fields, and watched for expiry. That is the job of turning technical documents into trusted product data: Claro resolves each declaration to the exact product, extracts the header metadata with a source link on every value, and flags validity so an expired EPD surfaces as a gap instead of hiding as a filled field.

Related

FAQ