Examples and downloads
See the shape of the work before you commit to it.
Six illustrative structures showing how evidence, comparability, tender requirements, product data, reporting processes and method notes are set out, plus the service menu and profile. Each one is readable on this page and available as a one-page PDF.
Illustrative structures, not client documents. The six examples are illustrative structures prepared by Reinventives Construction using synthetic records. They are not redacted client documents, and the method and EPD pages describe structure only, not certification or assurance.
01
Evidence and gap register
One row per figure, with the source and version behind it, what has been checked, whether a gap is open, who owns the data and what happens next. Used on footprint and reporting work so a reviewer can see the state of the evidence at a glance.
Evidence and gap register
Swipe to see all columns
| Reference and item | Source and version | Checked so far | Status | Owner | Next action |
|---|---|---|---|---|---|
| E01 | Purchased electricity | Example meter export v1; reporting-year dates recorded | Site coverage and units checked; factor source and version still required | Gap open | Finance data owner | Confirm factor, method and reviewer before calculation |
| E02 | Insulation product | Example product record P02; supplier document v2 | Declared unit present; technical performance and quantity need checking | Needs review | Product data owner | Confirm performance and comparison basis |
| E03 | Supplier response | Example supplier questionnaire v1; received date recorded | Reporting period absent; cannot assign to the requested period | Clarification needed | Procurement lead | Request period and supporting evidence; record reply |
Same records, one at a time
E01 | Purchased electricity
- Source and version
- Example meter export v1; reporting-year dates recorded
- Checked so far
- Site coverage and units checked; factor source and version still required
- Status
- Gap open
- Owner
- Finance data owner
- Next action
- Confirm factor, method and reviewer before calculation
E02 | Insulation product
- Source and version
- Example product record P02; supplier document v2
- Checked so far
- Declared unit present; technical performance and quantity need checking
- Status
- Needs review
- Owner
- Product data owner
- Next action
- Confirm performance and comparison basis
E03 | Supplier response
- Source and version
- Example supplier questionnaire v1; received date recorded
- Checked so far
- Reporting period absent; cannot assign to the requested period
- Status
- Clarification needed
- Owner
- Procurement lead
- Next action
- Request period and supporting evidence; record reply
Illustrative structure using synthetic example records. Each line carries its source and version, what has been checked, the evidence status, the named owner and the next action.
Download the evidence and gap register (PDF, one page) See sustainability consultancy
02
EPD comparability gate
Function and performance, unit and scope, life cycle and service life, method and indicators, and representativeness. Where figures from different declarations are shown separately, they are labelled with their basis. The comparison purpose, adjustments and remaining limitations are recorded. The diagram is an illustrative review structure, not certification or assurance.
EPD comparability gate
01 Function and performance
Equivalent function, technical performance and required quantity?
02 Unit and scope
Compatible declared or functional unit and assessment scope?
03 Life cycle and service
Consistent modules, reference study period and service-life assumptions?
04 Method and indicators
Compatible rules, PCR versions, indicators and calculation approach?
05 Representativeness
Appropriate geography, age, technology and use or end-of-life scenarios?
All checks satisfied
A scoped comparison is prepared, with the purpose, boundary and assumptions stated alongside the result.
A check fails or is unknown
The limitation is recorded, the data needed is requested, and the figures stay separate until the check can be satisfied.
Illustrative structure. Satisfying every check supports a scoped comparison for the stated purpose. It does not create automatic comparability and it is not a certification.
Download the EPD comparability gate (PDF, one page) See embodied carbon review
03
Tender requirements tracker
Each requirement is recorded in the buyer's own wording, with the evidence it needs, the person responsible, the check to run before submission and the current status. Used to keep a bid response consistent with what has actually been evidenced.
Tender requirements and evidence tracker
Swipe to see all columns
| Ref | Buyer requirement | Evidence needed | Owner | Next action | Status |
|---|---|---|---|---|---|
| T01 | State the reporting period and organisational boundary | Boundary and method note; authorised disclosure | Boundary owner | Confirm entities and reporting year | Awaiting clarification |
| T02 | Provide the carbon evidence specified by the buyer | Calculation summary, factor log and source register | Sustainability lead | Match answer to exact wording and evidence | In preparation |
| T03 | Describe actions, ownership and review arrangements | Action register and management approval | Bid manager | Check commitments with action owners | Review required |
Same records, one at a time
T01
- Buyer requirement
- State the reporting period and organisational boundary
- Evidence needed
- Boundary and method note; authorised disclosure
- Owner
- Boundary owner
- Next action
- Confirm entities and reporting year
- Status
- Awaiting clarification
T02
- Buyer requirement
- Provide the carbon evidence specified by the buyer
- Evidence needed
- Calculation summary, factor log and source register
- Owner
- Sustainability lead
- Next action
- Match answer to exact wording and evidence
- Status
- In preparation
T03
- Buyer requirement
- Describe actions, ownership and review arrangements
- Evidence needed
- Action register and management approval
- Owner
- Bid manager
- Next action
- Check commitments with action owners
- Status
- Review required
Illustrative structure using synthetic example records. The tracker follows the buyer's own wording, so every requirement has evidence, an owner, a next action and a status.
Download the tender requirements tracker (PDF, one page) See carbon reporting and tender support
04
Product dataset schema
Identity, evidence, comparison basis, result record and maintenance. Each layer names the fields to hold, an example record and the reason the layer exists, so product evidence stays linked to its source and its owner rather than sitting in scattered documents.
Product and supplier data schema
Swipe to see all columns
| Group | Fields | Example entry | Why the group exists |
|---|---|---|---|
| 1 Identity | product_id, supplier_id, product_name | P02 | S01 | Example insulation product | Stable IDs keep names and documents linked. |
| 2 Evidence | document_id, programme_operator, source_url, version, valid_to | Example supplier document v2; source link pending | Keep a separate evidence record; do not invent an EPD ID. |
| 3 Comparison basis | declared_unit, modules, function, technical_performance, service_life | Unit recorded; performance evidence pending | Store the basis alongside the value, not in a footnote. |
| 4 Result record | indicator, value, unit, scenario, method_version | No value entered: review incomplete | One result per indicator, module and scenario; never treat missing as zero. |
| 5 Maintenance | status, data_owner, checked_on, next_action, due_date | Needs review | Product data owner | Confirm performance | Make responsibility and currency part of the dataset. |
Same records, one at a time
1 Identity
- Fields
- product_id, supplier_id, product_name
- Example entry
- P02 | S01 | Example insulation product
- Why the group exists
- Stable IDs keep names and documents linked.
2 Evidence
- Fields
- document_id, programme_operator, source_url, version, valid_to
- Example entry
- Example supplier document v2; source link pending
- Why the group exists
- Keep a separate evidence record; do not invent an EPD ID.
3 Comparison basis
- Fields
- declared_unit, modules, function, technical_performance, service_life
- Example entry
- Unit recorded; performance evidence pending
- Why the group exists
- Store the basis alongside the value, not in a footnote.
4 Result record
- Fields
- indicator, value, unit, scenario, method_version
- Example entry
- No value entered: review incomplete
- Why the group exists
- One result per indicator, module and scenario; never treat missing as zero.
5 Maintenance
- Fields
- status, data_owner, checked_on, next_action, due_date
- Example entry
- Needs review | Product data owner | Confirm performance
- Why the group exists
- Make responsibility and currency part of the dataset.
Illustrative structure using synthetic example records. No declaration identifier is invented: evidence is held as its own record, with status and owner beside it.
Download the product dataset schema (PDF, one page) See product and supplier data review
05
Reporting process map
The reporting cycle with its real branches: what happens when validation fails, how corrections are rechecked, who approves, and how the released version is archived so the next cycle starts from a known position.
Reporting process map
- 01Agree the cycleBoundary, fields, owners and deadlines.
- 02Collect and versionEvidence with units, period and source.
- 03ValidateCoverage, units, duplicates, method and gaps.
- 04Resolve issuesCorrect the source or record the limitation.
- 05Review and approveChallenge assumptions and sign off.
- 06Release and archivePublish the approved version and retain evidence.
- A failed or unknown check goes to the named owner, then returns to validation for recheck.
- A reviewer who requests changes sends the record back to the owner for revalidation.
- Only an approved output is released and archived.
- 01Agree the cycleBoundary, fields, owners and deadlines.
- 02Collect and versionEvidence with units, period and source.
- 03ValidateCoverage, units, duplicates, method and gaps.
- 04Resolve issuesCorrect the source or record the limitation.
- 05Review and approveChallenge assumptions and sign off.
- 06Release and archivePublish the approved version and retain evidence.
- A failed or unknown check goes to the named owner, then returns to validation for recheck.
- A reviewer who requests changes sends the record back to the owner for revalidation.
- Only an approved output is released and archived.
Illustrative structure. A reporting cycle with named owners, validation, review, correction and an archived approved version. Nothing reaches release without review and approval.
Download the reporting process map (PDF, one page) See reporting process improvement
06
Method and handover note
The note that travels with an output so somebody else can follow it later: what was in scope, where the inputs came from, which methods and factor versions were used, who reviewed it, and what the output may and may not be used for. It describes structure only, not certification or assurance.
Method and handover note
- Scope
- The decision or reporting requirement, organisation or product boundary, reporting period, exclusions, intended audience and named outputs.
- Inputs and provenance
- Data owners, source files, versions, coverage, units and dates, with missing evidence recorded and its effect on the work.
- Method and judgements
- Method and factor versions, assumptions, calculations, conversion basis and comparability checks, keeping company accounting distinct from product assessment.
- Review and limitations
- Preparer and reviewer named, with checks, corrections, unresolved gaps and the permitted use of the output. Estimates stay distinguishable from measured inputs.
- Handover and next cycle
- Final output and supporting register, access arrangements, owner responsibilities, update triggers and review points.
Illustrative structure. This is the shape of the method note prepared for the agreed outputs of an assignment, so the next reporting cycle can be run by your team.
Handouts
Two pages you can forward
Written for the colleague who was not on the call: what the services cover, and who does the work.
Service menu
The full service list with what each one is for and what you receive, plus the project, deadline and ongoing options. Written to be forwarded to a colleague who was not on the call.
Andy Evans profile
A one-page profile covering Andy’s experience, specialist areas and the work Reinventives Construction can support. Designed to forward to a colleague after an introduction.
Have a requirement, a deadline or a data problem?
Bring the questionnaire, reporting deadline, product list or current process. We will clarify the scope and the most sensible next step.
Scope, deliverables, timing and fee are agreed in writing before work starts.