Copy of the original EPIC text. Images and buttons remain in the original; embedded databases and subpages are linked rather than duplicated. EPIC database properties are not copied.

📌 Scope update — July 2026
This EPIC covers the backend pipeline only: delivering a functional, end-to-end automated flow for the creation of Supplier Emission Factors (SEFs) from carbon reports. The client-facing surface — SEF card, validation status badges, AI provenance indicators, empty states, and version history display in the platform — is tracked in a dedicated EPIC: Supplier Carbon Data Researcher — Platform display & SEF card.
Goal: Develop a feature to auto create SEFs with data from a carbon report found online (if found)

The following elements were merged from the duplicate EPIC to keep a single source of truth. When overlapping, this EPIC remains the reference.

Develop a process to automatically and reliably create supplier emission factors (SEFs), by extracting emissions data from GHG/carbon reports found online and (when relevant) structured supplier-provided inputs, then running quality checks before creating/updating SEFs.

https://excalidraw.com/#json=muKLMgVPEWkVzDe2w8bAB, XW6t6DD-Kv5jp60XkzwsTg
​Open linked document

Archive (will be removed)

1 - Problem statement: Summarize the main problem in 2-3 concise sentences that clearly articulate the issue you aim to address.

Example

“Clients struggle to upload their IT inventory data due to a lengthy and overly complex process, leading to frustration, wasted time, and frequent errors. This creates delays in project timelines and reduces overall user satisfaction with the platform.”

2 - Detailed problem description and back it with data:

Summarize the main problem in 2-3 concise sentences that clearly articulate the issue you aim to address.
Supplier sustainability teams and Greenly's delivery partners spend dozens of hours per supplier manually extracting carbon data from PDF reports to fill in questionnaires — a process that is tedious, error-prone, and doesn't scale. The data needed exists in structured carbon reports (SEFs, sustainability reports, GHG annexes), but today there is no automated way to map it to the right questionnaire fields. The goal of this EPIC is to validate, end to end, an automated carbon data research pipeline that goes from a supplier's carbon report to a validated, ready-to-submit questionnaire answer.

Who is affected by this problem? (e.g. multi-entity client, CE, OM…)

Provide sample feedback (Intercom Messages,, Requests…)
Three personas are directly impacted:

Do a quick search on how our competitors are addressing this issue.
Fill in the competition database: and link the relevant entries
The space is moving — this is not greenfield.
​ Normative is the most advanced reference: they have shipped a product-grade feature for automated supplier carbon data collection, with a designed UX that covers structured extraction from supplier reports. The level of polish is notable and sets a clear bar. Key questions to dig into: what data types do they cover, how do they handle uncertain/missing data in the UX, what does their extraction pipeline look like under the hood?
Other players to monitor:

Format: As a [persona], I want to [action] so that [benefit].
* User Story 1
* User Story 2
* User Story 3

Create first a high-level (user / technical) flowchart describing the current situation and the one you aim for.
Duplicate this Miro: https://miro.com/app/board/uXjVLp_MFAo=/
For more technical data flow, here is a sample doc: https://excalidraw.com/#json=MUaNUrGiLX-wjtoEUGXSQ, w2nPaeN1MTUOXJdt85sX_Q
The end-to-end research flow is documented in the Excalidraw diagram linked at the top of the EPIC: SEF Researcher Pipeline
High-level steps of the target flow:

1 - Use bullet points to detail what needs to be done to tackle the different user stories and user flow you’re suggesting above.
2 - Provide rough estimations to assess complexity.
3 - Will you need a product designer to work with you on this feature? Explain it in your breakdown.

2 — Will the SEF auto-update when the supplier publishes a new GHG report? — Product — Blocker

No auto-update of existing SEFs. The system does not auto-fetch if data already exists for the current or most recent year. If a new research run discovers more recent data, it is stored as a new versioned entry in carbon_pipeline_sef_computation. The SEF displayed in Supplier Details is always the most recent version that passes quality checks.

3 — Is the SEF owned per-client or shared at the supplier level? — Product — Blocker

Supplier level (shared). One SEF exists per supplier — all clients of that supplier see the same emission factor. SEFs are versioned: multiple versions can exist per supplier. Supplier Details shows the most recent version passing quality checks. Giving clients access to the version history is desirable but out of scope for this EPIC — V1 focuses on the SEF card and displaying SEF information.

4 — When a SEF is auto-created, is it auto-applied to the client's questionnaire? — Product — Blocker

The SEF is never automatically applied. It is made available for use, and an email is sent to the client to share this availability, but applying the SEF is always a choice of the user.

5 — Does V1 cover monetary SEFs only, or also activity-based (LCA, freight)? — Product — Blocker

Monetary SEFs only (scope 1/2/3 + revenue) in V1. Activity-based SEFs are out of scope.

7 — Can a client edit an auto-created SEF, or only accept/ignore it? — Product — High impact

No client edit — accept or ignore. The client can choose to use the SEF or not, but cannot modify the values produced by the researcher. A "flag inconsistent data" button could be added (or the existing one repurposed) to let clients report issues with auto-created SEFs.

8 — Who validates SEFs: full manual review by R& M, or a tiered model? — Product — High impact

Tiered model: high-confidence SEFs are auto-validated; low-confidence SEFs go through manual review. The reviewers would likely be climate experts responsible for the relevant profiles rather than R& M — to be clarified with the teams involved.

10 — What does the client see before the researcher has run for a given supplier? — Product — Design-informing

Empty state with a validation status badge (one of: No research conducted / No data found / Inconsistent Data / SEF validated). Consider adding a CTA ("Contact your AM") to encourage clients to request a research run — tied to the business model discussion.

11 — Who triggers the researcher: client self-serve or ops-driven? — Product — Design-informing

In V1: ops-driven, while the team figures out the right business model. Self-serve may come later.

12 — How is the AI provenance of a SEF shown to the client? — Product — Design-informing

Badge indicating AI origin + extraction details (source document, extracted fields, confidence).

13 — Does the extraction pipeline support multi-language reports? — Product — Design-informing

Yes — multi-language is in scope for V1.

14 — What status is assigned when extracted data is internally inconsistent? — Product — Design-informing

Status ='Inconsistent Data'. The SEF is created but flagged for review.

21 — Does the SEF feed into GHG, LCA, and ESG modules? — Product — Design-informing

Today the emission factor created by the researcher is already available in the GHG module — so it is connected. However, running the researcher is done through the supplier experience. ESG and LCA are not directly concerned since this V1 focuses on Monetary SEFs.

1 — Where are scope 1/2/3 and revenue values stored that allow the EF to be built? — Technical — Blocker

In carbon_pipeline_sef_computation database. Future discussion needed on how to manage different data sources (questionnaire responses, scraped data, imported data) and their coexistence in the pipeline.

6 — Is historical SEF data versioned at the Supplier Details page level? — Product — High impact

Supplier data is not currently versioned at the Supplier Details page level, but EFs are stored per year in the database. This makes it possible to offer historical version visualization in Supplier Details in a future iteration.

9 — Pricing model: is the researcher included in the base Supplier package or an upsell? — Product — High impact

To be defined with Sales and Finance.

15 — Does the researcher auto-rerun when new data appears for a supplier? — Technical — High impact

No auto-rerun in V1 — all research runs are manually triggered.

16 — How does the pipeline handle conflicting data from multiple reports for the same supplier? — Technical — Blocker

All extracted data is stored and versioned. The SEF displayed to clients is the most recent version that passes quality checks. No conflict resolution needed — each extraction creates a new version.

17 — If a source report is retracted or found to be erroneous, what happens to the SEF that was built from it? — Technical — Blocker

18 — At 100+ entities with suppliers in common, how does batch processing scale? — Technical — High impact

Research runs are queued as async jobs. Parallelism level to be validated with engineering team.

19 — Does the pipeline write SEFs for past years (historical backfill), or only for the current year? — Technical — High impact

Add a SEF all years with data in the sustainability report (if validated)

20 — Can delivery partners trigger the researcher on behalf of their clients? — Technical — Design-informing

Not planned for V1. To be reconsidered based on usage patterns.

Answer the following questions 👇

See definitions here:. Use the same level for your final task on GitHub that will trigger the overall release.

Only keep the relevant part, remove the unused bullet points

We usually want ALL our customers to know about all the feature we handle. But that doesn’t mean they will ALL have access to it. Good example is the trajectory builder. Only accessible by NZC customers, but tab is visible by all packages (with paywall)
No

Archive (will be removed)

Questions to answer:

Is this a minor / major project?

Will this project be deployed to existing customers? If yes, all or only part? On which criteria? (only specific packages…)

Will this project be deployed only to new customers?

Does this project requires to review the existing pricing grid / packages / SLA?

Do you need to deploy a paywall/upsell logic?

Does this project requires specific internal training? If yes, please take it into account in your release process

Who should be notified for this PR:

Does this project requires a specific marketing campaign? (ex: new product offer - CBAM,…)

When you reach this stage, update the EPIC status to Ready Review (Yoann/Matthieu)

SEF researcher pipeline

Don’t forget to keep the Target QA Date property up to date

The QA should be done first internally within the team, then shared on #quality-assurance-product-team as explained in this doc:

Results
​Open linked document
​Open linked document
​Open linked document
​Open linked document
​Open linked document
​Open linked document
​Open linked document

Veolia (SBTi) Top 50 error rate:

10 min check per supplier
​ Check for non validated and not found but with url
→ 90% de SEFs validés

Database Top error rate:

*10 min check per supplier* *Check for non validated* → 10% de SEFs validés et 6% d’erreur

empty state avec validation status
si pas tourner, combien

Feed back

Doc
​

Follow the defined previously
Don’t forget to create the Release note (see ) in advance to give to the Product Marketing Manager some time to review it.
Link the release note in the property at the top of this doc.

To do when the epic is in prod / live + its UXUI is somewhat complex.
Fill the information and click the button below so our CRM manager (Solène Labonne) can recruit 2-3 customers, and then designer in charge of this epic will run these user tests.
​
​ Please specify👇
Designer in this epic:
Product (e.g. GHG, CSRD, etc.):
Page / feature to test (e.g. Building module, dashboard...:
KPI Board link:

Then create the task for Solène:

Company1 is doing…