A manufacturer with fifty products does not necessarily need fifty unrelated life cycle assessment (LCA) projects. It also cannot assume that one EPD will cover the entire catalog.

The right starting point is a coverage plan. Map how the products differ, how they are made and what the applicable Product Category Rule allows before deciding which model structures and declarations are needed.

This distinction matters for data-center suppliers because catalogs are rarely simple. A valve series may change by size, body material and trim. Cable and conduit vary by gauge, material and rating. Cooling equipment combines different capacities, components and manufacturing routes. The environmental result changes across those configurations, but not every change requires rebuilding the whole model.

Model Reuse and EPD Coverage Are Different Decisions

A reusable LCA model and a multi-product EPD solve related problems, but they are not the same thing.

Model reuse is about how the calculation is built. Related products can share common process structure, datasets, manufacturing steps and documentation while using different inputs for material, mass, energy, yield or transport.

EPD coverage is about what a verified declaration is allowed to represent. The applicable PCR and program-operator rules determine how products may be grouped, what variation must be disclosed and when a configuration needs separate treatment.

One shared model can support many product calculations. That does not automatically mean one declaration can represent every calculated product.

Keeping those decisions separate avoids two common mistakes. The first is commissioning disconnected studies for products that share most of their manufacturing logic. The second is stretching one declaration across products whose impacts or product definitions differ too much.

Start With the Commercial Catalog

The first map is the catalog as customers see it.

List the product families that appear in data-center bids, specifications and customer requests. For each family, capture the attributes that change what is sold:

• Size, capacity or performance rating

• Material and component options

• Product geometry and mass

• Manufacturing facility or route

• Supplier or recycled-content choices

• Installation or use-stage configurations when the PCR includes them

This step is not yet an LCA. It is a coverage inventory. Its purpose is to expose how many meaningful configurations exist and which ones matter commercially.

A long catalog may collapse into a manageable set of patterns. Twenty sizes may follow the same manufacturing route and differ mainly in component mass. A material option may introduce a different upstream dataset. One product may be made at a separate facility with a different energy profile.

Those patterns become the inputs to the modeling and declaration plan.

Map What the Products Share

The second map is manufacturing logic.

Products in one family often share:

• The same bill-of-material structure

• Common upstream materials and suppliers

• The same casting, forming, machining or assembly steps

• Facility energy and waste data

• Packaging and transport assumptions

• The same evidence sources and documentation

Build the common structure once, then connect the values that vary by configuration. A change in size might update component weights. A material option might select a different dataset. A facility choice might change the energy mix and process losses.

A parameterized model can preserve shared structure while changing inputs that distinguish one configuration from another. Keep configuration choices separate from revisions over time, so the evidence behind each calculated result remains clear.

That structure reduces duplication and makes differences visible. It also gives a verifier one organized evidence trail to review rather than a stack of models that have drifted apart.

Apply the PCR Before Grouping Products

The third map is the declaration rule set.

A PCR defines how an LCA for a product category must be conducted and reported. It sets requirements such as the declared or functional unit, system boundary, data rules, allocation approach and required indicators.

Before grouping products under a declaration, confirm:

1. The products fall under the same applicable PCR and product definition.

2. The declared unit works consistently across the group.

3. The modeled variation can be represented and disclosed under the program operator’s rules.

4. Any representative-product, averaging or scaling approach is permitted and documented.

5. Configurations with materially different impacts or production routes are identified rather than hidden in the group.

For example, the International EPD System’s guidance on multiple products distinguishes average, representative and worst-case approaches, with restrictions tied to the applicable PCR and claimed standards. These are program-specific rules, not permission to apply any approach to every product category.

The answer may be one declaration, several declaration groups or separate declarations for outliers. That is a governance decision based on the PCR and verification approach, not a marketing preference.

Can One EPD Cover Multiple Products?

A representative product should be chosen because it supports the required disclosure method, not because it is the easiest SKU to model.

Depending on the rules, the program may need:

• A typical configuration

• A conservative or highest-impact configuration

• An average calculated from a defined product group

• Separate declared results for selected variants

• Scaling factors tied to mass, size or another permitted parameter

Document why the representative product or grouping was selected and which catalog configurations it covers. If a buyer requests a product outside that boundary, the team should be able to see the gap immediately.

Create a Product-Family EPD Coverage Plan Before Collecting Everything

A product-family EPD coverage plan prevents the program from collecting data without a decision structure.

For each commercially important configuration, record:

• Product family and configuration

• Manufacturing facility

• Material and supplier differences

• Shared model components

• Variable inputs

• Applicable PCR

• Proposed declaration group

• Evidence gaps

• Reviewer or program-operator question

This matrix becomes the working plan for data collection and verification. It also reveals where the company can start with a focused first wave while preserving a path across the rest of the catalog.

Plan for Change After Publication

Product families do not stand still. Suppliers change, facilities update equipment, recycled content shifts and new sizes enter the catalog.

A maintainable EPD program keeps the published result connected to:

• The exact model and calculation version

• The data period and facilities represented

• The supporting source documents

• The configurations covered by the declaration

• The assumptions that would trigger recalculation or verifier review

That makes change reviewable. The team can distinguish a routine parameter update from a change that alters the declaration boundary.

Cover the Catalog With Evidence, Not Optimism

The goal is not to force the whole product line into one EPD. The goal is to build the smallest defensible set of models and declarations that covers what customers actually buy.

Start with the catalog, map shared manufacturing logic, apply the PCR and document the declaration groups. A reusable model then becomes the technical foundation for repeatable calculations, while verification determines what can be represented together publicly.

CarbonGraph helps manufacturers build reusable, traceable LCA models across product families and organize the evidence behind each configuration.

Related: Why data-center suppliers need evidence across the product line.

Have a product family with many sizes, materials or facilities? Book a walkthrough.