Skip to main content

Verification Workflow

This page describes how third-party verifiers review and certify EPDs, LCAs, and tools on the Smart EPD platform. Verification operates at two levels: package-level (what's being reviewed and by whom) and section-level (how each item is reviewed in detail).

Overview​

Step 1: Manufacturer submits a package​

The manufacturer creates a submittal package within their project, adds the items to be reviewed (LCA documentation, standard EPDs, reference EPDs, variant EPDs), and submits it. Submitting locks the package; no further edits are allowed until the verifier returns feedback.

Step 2: Verifier is assigned​

A workspace admin assigns a verifier to the submittal package and starts the review. The assigned verifier now sees this package in their verification dashboard (GET /verifier/dashboard/): a consolidated view of all active review assignments across workspaces, grouped by Category. A flat assignment queue (GET /verifier/queue/) is also available for programmatic access.

Step 3: Section-by-section review​

For each item in the package, the verifier works through the EPD's sections one at a time. Smart EPD provides four tools at the section level:

Conformance assessment​

For each section, the verifier sets a conformance status:

StatusMeaning
ConformantSection meets all requirements
OFIOpportunity for improvement: acceptable but could be better
Non-conformantSection does not meet requirements; must be corrected

Verification comments​

The verifier can create threaded discussion comments on any section. Comments are scoped to a specific section and support back-and-forth dialogue — the EPD author can reply to the verifier's comments, and the verifier can respond in turn. This threaded conversation continues until the finding is resolved, without either party leaving the platform.

AI conformance hints​

Smart EPD provides AI-generated suggestions for each section's conformance status. These include:

  • A suggested status (conformant / OFI / non-conformant)
  • A rationale explaining the reasoning
  • A confidence level (high / medium / low)

The AI analysis never runs on its own — submitting an EPD or LCA does not start it. The verifier triggers it on demand from the review surface (and can later re-run it scoped to their still-open findings after a resubmission); manufacturers can run a streamlined version of the same analysis from the Conformance Analysis panel before submitting. AI hints are advisory; the verifier always makes the final determination.

Verifier checklist​

For each requirement defined in the specification, the verifier records a compliance status:

StatusMeaning
Y (Yes)Requirement is met
N (No)Requirement is not met
OFIOpportunity for improvement
N/ANot applicable to this product

The checklist is structured by the specification's requirement hierarchy, so the verifier works through the same requirements that the specification engine validates automatically.

Copying a review between EPDs. EPDs in the same project are verified against the same requirements, so the verifier holding the review (assigned to the EPD, its LCA, or its project) or a SmartEPD admin can copy one EPD's recorded checklist onto a sibling EPD that is still in review (the V1 "Copy Review" action). Each requirement the source verifier reviewed carries its verdict, note, and proposed change across; requirements the source left unreviewed keep whatever the target already has, and evidence citations are never copied. Constraint rows are never copied either: each one judges its own EPD's values, so a copied verdict would certify values nobody looked at. The source list and the copy itself are GET /checklists/{id}/copy-sources/ and POST /checklists/{id}/copy-review/ — see Swagger for the schemas.

Reference EPD constraints​

A reference EPD answers to its template's constraints (see Reference EPDs & Constraints). Its checklist has one constraint row for each of them, spec-level and template alike, plus a variant governance row covering the fields its variants inherit locked. The verifier works through these on the review page's Constraints Review tab, which takes the full width of the page.

The tab's toolbar shows how many constraint rows have a determination ("x of y constraints reviewed") and a one-line summary of how the submitted values fare. It also has the Cross-reference LCA Documents button and Explore input space, which opens the Constraint Explorer on the constraints and values as submitted, so a flagged author's unsubmitted edits never reach it (see Exploring the input space). The toolbar names the constraint version under review, and for a revision the approved version it revises. Below the toolbar, a banner states whether the template enforces its constraints:

  • Enforced: error-level failures block the author's submission unless the author explicitly acknowledges them, and every variant built from this reference must satisfy the constraints.
  • Informational: failures are shown for review but do not block the submission.

If the author submitted over failing constraints, an amber callout gives the date of their acknowledgement.

Each row shows:

  • the constraint's label and field ID;
  • its type and severity;
  • the rule in plain terms (bounds, allowed values, formula, and any applies_if gate);
  • the submitted value, or "Not provided";
  • the evaluation status and the engine's message;
  • a suggested determination worked out from the submitted value;
  • a determination picker and notes. The picker reads C / NC / OFI / N/A, which the checklist stores as Y / N / OFI / N/A.

Rows recorded before evaluations were stored show "Value not recorded" instead of a value.

The suggestion is only a starting point. A value that passes shows "Suggested: C", not a verdict, and each row needs its own click from the verifier. That is why the page-level Bulk determination and Accept all AI suggestions actions skip constraint rows on both review tabs, and why POST /checklists/{id}/batch-annotate/ refuses any batch that includes one ("Constraint items must each be reviewed individually."). Batch-annotate is limited to the assigned verifier, like the single-item update.

The rows mirror the EPD's latest submission: its definitions and values are frozen into the submission snapshot, and the EPD's own constraint version is frozen while it is in review. A constraint or value the author changes while the EPD is flagged does not reach the rows until the EPD is resubmitted. Opening the checklist and approving bring the rows in step with that snapshot, and write nothing when they already are. If approving adds a row or clears a determination, it is refused and asks you to reload the review page. The rows stop changing once the EPD is approved.

The tab also has a Submission package card. It shows the EPD tool and version, the PCR spec version and the template definition the EPD was submitted against, taken from its submission snapshot, and whether approval has locked it. See Submission snapshots and the model lock.

Step 4: Item decisions​

After reviewing all sections and completing the checklist for an item, the verifier makes a decision:

  • Approve -The item passes verification
  • Flag -The item needs attention but review can continue. The verifier adds notes explaining the concern.
  • Request revision -The item is returned to the manufacturer for corrections. The manufacturer revises the data and resubmits, at which point the verifier picks up the review again.

A reference EPD's resubmission goes through the same reference-value rules as its first submission (when the template enforces its constraints, missing values block, and failing error-level constraints block unless the author acknowledges them), and its constraint rows are rebuilt from the resubmission. A row whose constraint or submitted value changed loses its determination and says why (constraint_source.verdict_reset); unchanged rows keep theirs, rows for constraints the resubmission no longer has are removed, and a signed-off checklist is reopened. See Submitting a reference EPD.

Step 5: Approval gates​

Items must be approved in dependency order; the platform enforces these gates automatically:

  1. LCA approved first -No EPDs can be approved until the LCA documentation is verified

  2. Reference EPD before variants -Variant EPDs cannot be approved until their reference EPD is approved

  3. Reference EPD constraints reviewed -A reference EPD whose template defines at least one constraint cannot be approved without a checklist. Its constraint rows are brought up to date first (any missing row is created), and every one then needs the verifier's own determination. As with every checklist, approval also requires a determination on every in-scope row and no row marked N (non-conformant).

  4. Variant submitted under the approved constraints -A variant submitted while its reference EPD was on an earlier approved constraint version cannot be approved once a revision of the reference is approved (409 reference_revised). Request changes, so the author resubmits it against the new version.

If the verifier attempts to approve an item before its dependency is cleared, the platform blocks the action and explains which prerequisite is missing.

Approving a reference EPD also approves the constraint version it was submitted with, which its variants are then validated against, and locks its model: the submission snapshot of the EPD tool and version, PCR spec version and constraint version it was approved on. Variants are compared with that lock. A variant whose model has drifted is flagged, and submitting it sends it to a verifier instead of approving it automatically. See Submission snapshots and the model lock.

Revisions of an approved reference EPD​

An approved reference EPD's constraints can change only through a revision, which its author starts from the EPD's page. The EPD goes back to draft on a new constraint version, and when it is submitted it returns to the verifier who approved it, with the same checklist reopened. Rows the revision did not change keep their determinations, and the round diff compares the revision with the document as approved. If that verifier can no longer be assigned (for example, they left their verifier organization), the normal assignment applies. Until the revision is approved, the approved version stays in force for the variants, no new variants can be created and none is approved automatically. The author can discard a revision that is still a draft or was sent back with changes requested, but not one in review. Discarding restores the approval's checklist exactly as it was when the revision started, determinations and sign-off included; a checklist made only for the revision's review is detached from the EPD (kept as history, never shown as its checklist again), and the discarded revision's rounds stay in the round history marked as discarded. A published reference EPD cannot be revised yet: that needs republishing, which V2 does not support yet (SMA-2180). See Revising an approved reference EPD.

Step 6: Package approval​

Once every item in the package is approved, the verifier can approve the package as a whole. This permanently locks the package and signals that all deliverables have been verified.

Alternative outcomes​

If the verifier determines the package needs significant rework:

  • Return for feedback -Unlocks the package so the manufacturer can revise items. The manufacturer can then create a new revision of the package.
  • Reject -Permanently closes the package. This is uncommon; returning for feedback is typically preferred.

When a new revision is created, all items are copied with their review status reset to pending, creating a clean slate for the next review round.

What changed since the last round​

Each verifier decision on an EPD (approve, or request changes) is recorded as an append-only review round, and a changes-requested round also freezes the EPD document exactly as the verifier reviewed it. When the manufacturer resubmits, GET /api/v2/epds/{id}/verification/round-diff/ compares the live document against that snapshot and returns the two documents, the changed section ids, and a field-level changed_fields changelog (display-ready before/after text for scalar fields, a one-line summary for tables). For a revision of an approved reference EPD, the approval round's snapshot counts too, so the first review of a revision compares it with the document as approved. The review page uses it to list the changes and highlight the changed sections. The endpoint answers 404 when no prior changes-requested round captured a snapshot, which is the normal first-review case rather than an error.

State machines​

Submission is the single atomic transition that starts review: calling submit on a package, an EPD, or an LCA moves the target and its items directly into in_review. There is no separate "start review" step — the pending state only reappears when a package is returned for feedback and items are reset for the next round.

Per-item states​

Package states​