LCA Submission

Every project requires an approved Life Cycle Assessment (LCA) before its EPDs can be verified. This guide covers the LCA version lifecycle and document management.

LCA version lifecycle

Creating an LCA version

An LCA version is automatically created when you first access the project's LCA panel:

GET /api/v2/projects/{project_id}/lca/

To explicitly create a new version:

POST /api/v2/projects/{project_id}/lca-versions/
Content-Type: application/json
{"version": 1}

Uploading documents

Attach LCA documentation to the version. Supported document types:

Type	Description
lca_report	Main LCA methodology report
supporting_data	Background data, inventory data
data_quality	Data quality assessment
methodology	Methodology description
other	Any other supporting file

Upload stages: lca_submittal (primary) or supporting_documentation.

POST /api/v2/projects/{project_id}/lca/documents/
Content-Type: multipart/form-data

file: @lca-report.pdf
document_type: lca_report
stage: lca_submittal

You can also add documents to a specific LCA version:

POST /api/v2/lca-versions/{lca_version_id}/documents/
Content-Type: multipart/form-data

file: @supporting-data.xlsx
document_type: supporting_data
stage: supporting_documentation

Submitting for review

POST /api/v2/projects/{project_id}/lca/submit/

Or submit a specific version:

POST /api/v2/lca-versions/{lca_version_id}/submit/

Once submitted, documents are locked and cannot be added or removed.

Tracking review progress

While a submission is in review, manufacturers can poll an estimated progress read for the verifier's round:

GET /api/v2/lca-versions/{lca_version_id}/verification-progress/
# EPDs have the same read:
GET /api/v2/epds/{epd_id}/verification-progress/

{
    "has_checklist": true,
    "checklist_status": "in_progress",
    "total_requirements": 172,
    "completed_requirements": 63,
    "percent_complete": 36,
    "is_estimate": true
}

The counts are the verifier's checklist requirements: total_requirements is the actionable pool (informational, post-verification, and system-auto-passed rows are excluded), and completed_requirements is how many already carry a verifier verdict. The response is counts-only — it never exposes checklist content or verdicts — and the read is side-effect-free, so polling is safe.

is_estimate is always true and should be surfaced as such in any UI: requirements vary in effort and verifiers revisit earlier verdicts. percent_complete floors, so 100 only appears once every actionable requirement has a verdict. Before the verifier's checklist exists, has_checklist is false and all counts are 0.

Verifier verdicts carry over across resubmissions, so after you resubmit, open findings you responded to count as not yet completed until the verifier re-reviews them — the bar drops back by exactly the re-review workload instead of misleadingly holding the prior round's percentage.

Review and approval

Standard flow

The verifier reviews the LCA against its checklist, then either approves or rejects.

Approval requires two signed forms: the verification report letter and the ISO 14071 independence declaration. The verifier completes them on their assignment, and signing the declaration is what approves the LCA:

# 1. Sign the verification report letter (checklist must be complete, no non-conformant items)
POST /api/v2/verification/{assignment_id}/attestation/

# 2. Sign the ISO 14071 independence declaration — this approves the LCA
POST /api/v2/verification/{assignment_id}/independence-declaration/

# Reject
POST /api/v2/lca-versions/{lca_version_id}/reject/
{"review_notes": "Missing data quality assessment for upstream processes."}

POST /api/v2/lca-versions/{lca_version_id}/approve/ also exists, but it returns 400 until both forms have been signed for that LCA version. It cannot be used to approve around them.

Non-prod shortcut

In non-production environments, pass force_status to submit to skip the full review workflow:

POST /api/v2/projects/{project_id}/lca/submit/
{"force_status": "approved"}

The force_status parameter bypasses the status precondition — you can approve an LCA version directly from draft status. It is rejected with a 400 in production. The approve endpoint itself does not accept force_status. See Verification Testing for the full list of supported endpoints.

Handling rejection

If an LCA version is rejected, reopen it to make changes:

POST /api/v2/projects/{project_id}/lca/reopen/

Then add/remove documents and re-submit.

Why LCA approval matters

The LCA submission serves a dual purpose:

1. Documentation completeness — EPD verification requires an approved LCA version in the same project. The POST /verification/{assignment_id}/approve/ endpoint checks this before approving an EPD. Without an approved LCA, EPD approval is blocked (unless using force_status in non-prod).

2. Tool/model verification — For tool-based Categories, the LCA review is closely tied to verifying that the tool/model produces valid results within the verified scope. The verifier reviews the LCA methodology and output to confirm the tool is operating correctly for this project's product category.