chwr_LCA for grant reviewers and non-technical stakeholders¶
Drafted from the project's own published documentation at chwr-lca.pages.dev. Where the site does not state something, that is said plainly rather than filled in.
Part 1 — The project, plainly¶
What the tool does and why it matters¶
chwr_LCA is an open-source software tool that measures the environmental impact of buildings, with a specific focus on buildings made from earth (adobe, CEB and CSEB — defined below) in Sub-Saharan Africa, and comparing them against conventional alternatives (concrete hollow block and reinforced-concrete frame). The reference case used throughout the code is a real building in Senegal ("Keur Songho"), with a second project ("Kalan Deme So", in Mali) used to check the numbers.
The kind of measurement it performs is called a Life Cycle Assessment (LCA) — a structured accounting of the environmental burdens of a product or building across its whole life, from digging up raw materials, through manufacture, transport, construction and use, to demolition and disposal. The single most-quoted output is the building's contribution to climate change (its "carbon footprint"), but an LCA covers many impact categories.
Why it matters: earth building is widely assumed to be greener than concrete, but that claim is only credible if it is measured honestly and to a recognised standard — including the parts of a building's life (like maintenance and replacement) where earth can perform worse. The tool's stated purpose is to make that comparison defensible rather than assumed. It is released under the AGPL-3.0-or-later licence (a "copyleft" open-source licence: anyone may use, inspect and modify the software, but changes offered as a network service must also be shared as open source), so the method and the code are fully inspectable.
Plain-English glossary of the building blocks: - Adobe — sun-dried mud brick; earth shaped in a mould and dried in the air, not fired. - CEB (Compressed Earth Block) — earth mechanically pressed into a dense, uniform block; stronger and more moisture-resistant than adobe. - CSEB (Compressed Stabilised Earth Block) — a CEB with a small amount of binder (typically cement or lime) added to increase strength and water resistance.
What makes an LCA credible¶
The project's "Differentiators" page sets out four properties it treats as the basis of credibility. In plain terms:
- No silent numbers. Every value that feeds a result must carry a label saying where it came from. The project uses three labels:
SOURCED(traceable to a standard, an official environmental declaration, or a named peer-reviewed paper),EXPERT-JUDGEMENT(a named practitioner's estimate, with their name, the date and the reasoning — allowed only for project-specific geometry, never for impact factors), andBLOCKED(no source at all). ABLOCKEDvalue does not quietly default to a guess — the software stops and raises an error, so the gap is impossible to hide. - The spreadsheet is a starting point, not the truth. Many tools copy an Excel workbook's numbers and treat "matches the spreadsheet" as success. This project independently audits each spreadsheet formula against the relevant standard; where a formula is wrong, the code deliberately produces the corrected value and a test records the difference. Five such corrections (labelled C1–C5) are documented for one module.
- No borrowed classification tables it cannot control. Earth materials have no code in mainstream construction classification systems, so the project maintains its own material categories in its own code rather than depending on an outside table it is not licensed to adapt.
- Maintenance and replacement are counted, not ignored. Earth renders in wet-dry climates need re-doing; leaving that out would unfairly flatter earth against concrete. The tool treats the "how long a material lasts before replacement" figure as a first-class, sourced input — and if no source exists, it is marked
BLOCKEDrather than assumed.
Underlying all of this is a chain of recognised standards, each defined here on first use: - ISO 14040 / 14044 — the two international standards that define how any LCA must be done (its four phases: goal & scope, inventory, impact assessment, interpretation) and the extra rules that apply when you publicly claim one product is better than another. - EN 15804+A2 — the European rule-set for a product-level EPD. In full, EN 15804:2012+A2:2019, "Sustainability of construction works. Environmental product declarations. Core rules for the product category of construction products" (BSI/CEN); its A2 revision aligned its methodology with the European Commission's Environmental Footprint (EF 3.1) method. An EPD (Environmental Product Declaration) is a standardised, independently checked "nutrition label" for a building product's environmental impacts. - EN 15978 — the European standard for assessing a whole building: EN 15978:2011, published by CEN (Technical Committee CEN/TC 350, secretariat AFNOR), full title "Sustainability of construction works — Assessment of environmental performance of buildings — Calculation method". It organises a building's life into labelled stages: product (A1–A3), transport to site (A4), construction (A5), use and maintenance/replacement (B1–B7, with B4 = replacement), end of life (C1–C4), and benefits beyond the boundary (D). - ISO 21931-1 — ISO 21931-1:2010, "Sustainability in building construction — Framework for methods of assessment of the environmental performance of construction works — Part 1: Buildings", prepared by ISO/TC 59/SC 17; it provides a general framework for improving the quality and comparability of methods for assessing the environmental performance of buildings. Referenced by the project for scope. - EF 3.1 (Environmental Footprint 3.1) — the specific European Commission method for turning emissions and resource flows into impact scores, published by the European Commission Joint Research Centre in "Updated characterisation and normalisation factors for the Environmental Footprint 3.1 method" (EUR 31414 EN, Publications Office of the EU, 2023, doi:10.2760/798894, JRC130796), aligned with IPCC 2021 (AR6) climate-change characterisation factors. Characterisation is the step that converts, say, a kilogram of methane into its equivalent climate-change score. EF 3.1 is the only impact-assessment method the tool allows. - cradle-to-gate — an LCA boundary covering raw materials through to the factory gate (life stages A1–A3), i.e. before transport to site. - system boundary — the explicit definition of what is and is not counted in the assessment. - functional unit — the defined basis of comparison (e.g. "one square metre of wall lasting a set number of years"), so two options are compared like-for-like. - ISO 14071 critical review — ISO 14071:2024, "Environmental management — Life cycle assessment — Critical review processes and reviewer competencies", by ISO/TC 207/SC 5, which specifies requirements and gives guidance for conducting a critical review of any type of LCA study and the competencies required for the review (it cancelled and replaced ISO/TS 14071:2014). This is the independent expert review required before a public comparative claim is credible; an external review to this standard is the project's stated goal, planned for after v1.0 is released.
What stage the project is at, and what is still incomplete¶
The home page states the status plainly: pre-alpha, targeting version 1.0 in about four months. Version 1.0 means a complete, released tool — backend, frontend, public docs site, seed-EPD library and the v1.0.0 tag. The external ISO 14071 critical review is a separate, subsequent validation step: it examines the tool and methodology once released, and the release is not held for it.
The most important honesty point — stated by the project's own status page — is this: the calculation code is largely built and tested, but it cannot yet produce a single citable environmental result, because it is waiting for source-backed numbers. In the project's words, the calculation modules "are implemented and parity-tested, and still return None, purely for want of a factor with a citation." The status page is therefore "overwhelmingly a sourcing-and-attribution backlog, not an implementation backlog": of 49 open items, only 5 are software-development tasks.
Concretely, still incomplete per the action register (last reviewed 25 July 2026): - No emission factor has yet been sourced and committed for the core stages. Transport (A4) and the product stage (A1–A3) both await cited factors before they can return a number. - The earth material's own carbon factor is not yet sourced. Earth is the largest material in the reference building, and its figure is currently traced only to an unpublished thesis; the project explicitly forbids substituting a European database value for earth and is waiting on primary field data. - Several workbook numbers are flagged as probably wrong and are held open pending investigation (e.g. a crude-oil figure roughly 44× the expected value; floor-tile and steel figures far outside published ranges). - The methodology landing page is an empty placeholder ("TODO — populated in Phase 0"), even though many detailed methodology sub-pages exist. - The project is still private and pre-release. The code repository is private; public release is gated behind a set of legal clearances (see Part 2) and behind naming/governance decisions, including a trademark search for the provisional working name "Sankofa LCA".
The bottom line for a reviewer: this is an early-stage, unusually transparent project whose engineering scaffolding exists and whose honesty mechanisms are real and enforced in code, but which has not yet reached the point of producing any published, source-backed result.
Part 2 — Simplified third-party & data-source summary¶
This is not a licence register. A full legal licence register already exists on the site at
/third-party/and is not reproduced or replaced here. This section is two short, plain lists: (a) what the tool is built on, and (b) where its environmental data comes from geographically.
(a) Software and services the project is built on¶
Names and one-line roles only. Drawn from the Architecture overview and the third-party register.
- FastAPI — the web-application framework that runs the tool and exposes its calculations over the internet.
- Uvicorn — the server that runs the FastAPI application.
- Pydantic (v2) — checks and validates all data going in and out.
- SQLAlchemy (v2) — connects the application to its database.
- Alembic — manages changes to the database structure over time.
- PostgreSQL 16 — the database where data is stored.
- openEPD — the open data format (and matching Python library) used internally to represent EPD data.
- httpx — fetches data from external sources at runtime.
- pycountry — supplies standard country codes.
- psycopg — the driver that lets the application talk to PostgreSQL.
- pytest, pytest-cov, pytest-asyncio, ruff, mypy, pre-commit, openpyxl, hatchling — development and testing tools (used to build and check the code, not by end users).
- MkDocs + Material for MkDocs + PyMdown Extensions — build this documentation website.
- Cloudflare Pages — hosts the documentation website.
- GitHub (+ a CLA-assistant GitHub Action) — hosts the code, runs automated checks, and manages contributor agreements.
(b) External emission-factor / EPD data sources¶
Important status caveat, stated by the project itself: as of the action register, no external factor has yet been ingested as a usable, committed value — every impact total currently returns empty (None) for want of a cited factor. The list below therefore describes the sources the project names as the origins it draws from (or is permitted to draw from), and the geographic-proxy issue a reviewer should watch, rather than a set of results already in production.
The project's locked data policy (its "decision #25/#26") is important context: the public version is allowed to build and run from ÖKOBAUDAT data alone; other databases may be consulted and cited but not bundled into the public release; and European data is explicitly forbidden for earth materials and for energy-linked stages, because a European figure is not representative there.
Each source is stated in the form "sourced from X, applied to Y" so the geographic proxy is visible rather than hidden.
- ÖKOBAUDAT — the standardised construction-materials LCA database maintained by the Federal Institute for Research on Building, Urban Affairs and Spatial Development (BBSR) on behalf of the German Federal Ministry for Housing, Urban Development and Building (BMWSB), containing 1,400+ EN 15804-compliant datasets. Used for product-stage (A1–A3) impact factors for manufactured/conventional materials (e.g. aggregates); it is the only database whose values may be included in the public release. Sourced from Germany / European context, applied to Senegal.
- IPCC EFDB (Emission Factor Database) — the IPCC's open library of emission factors. Intended source for transport factors (road and sea freight, A4) and for the Senegal electricity-grid factor (B6). Sourced from international / country-level IPCC data (a Senegal-specific grid figure is being sought), applied to Senegal.
- INIES — the French national EPD database. Consulted and cited at runtime (e.g. for an anti-rust paint), but not bundled into the public release. Sourced from France, applied to Senegal.
- EPD Norge — the Norwegian EPD programme. Citable/runtime only; where the same product appears in ÖKOBAUDAT, that copy is used instead. Sourced from Norway, applied to Senegal.
- IBU — the German EPD programme operator (Institut Bauen und Umwelt). Used chiefly via its entries mirrored inside ÖKOBAUDAT. Sourced from Germany, applied to Senegal.
- NASA POWER — NASA's free global climate and solar dataset, used for the weather inputs to the operational-energy (B6) calculation: sunlight, air temperature, humidity and wind. It is US-government data with no copyright restriction, so it can be included in the public open-source release outright. ERA5 (European Copernicus programme) and PVGIS (European Commission Joint Research Centre) are usable alternatives, free and redistributable provided they are credited. Sourced from a global dataset sampled at the project's own coordinates, applied to Senegal — see the note below on why that distinction matters.
- ASHRAE Handbook of Fundamentals (cooling-load tables) — no longer used; decided against on 29 August 2026. These US engineering tables were the original plan for the cooling calculation. A licence investigation found they cannot lawfully be included in an open-source release of this kind: ASHRAE permits reuse only by the specific purchaser, whereas this project's licence requires that everyone who receives the software receives the same rights to it. Rather than negotiate for a permission that does not exist, the project changed method — see below.
- Earth-material and reference literature — CRAterre publications, RILEM TC 274-TCE, Ben-Alon et al., a doctoral thesis (Pedrazzi), the French pre-standard XP P13-901, and a Danish technical report (DTU 26.1). Used for the physical properties and impacts of earth materials specifically. Sourced from international earth-construction research (a citable earth carbon factor is still being sought, ideally from local field measurement), applied to Senegal.
- Programme operators named but not usable for bundled data: EPD International (per-declaration clearance required) and EPD Australasia / EPDASA (redistribution terms unknown; treated as blocked).
(c) How the building's cooling energy is worked out — and why the method changed¶
Added 29 August 2026. This replaces the ASHRAE table-lookup method previously described.
Working out how much energy a building needs to stay cool requires two things: what the local climate does, and how the building responds to it.
The old approach — look it up in a table. The team's existing spreadsheet used published American engineering tables (ASHRAE) that give a cooling figure for a handful of fixed latitudes — 0°, 8°, 16°, 24° and so on. A project that does not sit on one of those lines has to be interpolated between the two nearest ones. Two problems emerged. The legal one: those tables are copyrighted and cannot be included in an open-source release that gives everyone the same rights, which is what this project's licence requires. The technical one: an audit of the spreadsheet found it never actually interpolated. Its cooling chain reads a block of numbers hard-copied from the 12°N table, for a building at 14.7°N — not the interpolated value, and not even the nearest line. The error that introduces is typically 0.75 °C and at worst 1.7 °C on a quantity that runs 5–20 °C, so between roughly 8 % and 30 % on that part of the cooling load.
The new approach — use real data for the real location, and calculate from physics. The tool now takes its climate inputs from NASA POWER, a dataset that covers the whole globe on a continuous grid rather than at a handful of latitudes, and computes the cooling load from first principles using the European standard method for annual building energy (EN ISO 52016-1, run hour by hour across the whole year) implemented in the project's own code. The ASHRAE method was considered and set aside for a specific reason: it is designed to size air-conditioning equipment for the worst day of the year, whereas this tool needs the energy used across all 8 760 hours of it. Physical laws cannot be copyrighted, so nothing needs licensing; and because the data is gridded rather than banded, the "which latitude line is closest" question disappears.
What that looks like for the reference building. Keur Songho sits at about 14.7°N. NASA POWER's weather grid is spaced half a degree apart in latitude, so the building falls between the grid lines at 14.5°N and 15.0°N — 40 % of the way from the first to the second. The tool takes the four grid points surrounding the site and blends them in proportion to how close each one is, then records in the audit trail which points it used, what weights it applied, and what came out. Under the old method the same building was assigned, wholesale, to a line 2.7 degrees away.
No climate figures are quoted here, because none has been retrieved yet: the climate service is designed, not built. Stating the method and leaving the numbers out is the honest version — the same discipline applied to the emission factors above.
Full reasoning, including the verdict on every climate data source considered, is on the site at
/methodology/climate-data-licence-clearance/. The decision is tracked as items AR-31, AR-60,
AR-61 and AR-62 in the action register.
Discrepancies and open questions for the maintainer¶
Points where the pages disagree, are incomplete, or could mislead a reader. Flagged rather than smoothed over.
- Two names for the tool. The site title and home page call it "chwr_LCA"; the Architecture and Differentiators pages call it "Sankofa LCA". The action register confirms "Sankofa LCA" is a provisional working title pending a trademark search. Recommend a single displayed name or an explicit note that the two are the same tool.
- The methodology landing page is empty.
/methodology/reads only "TODO — populated in Phase 0", yet the home page describes Methodology as "the living methodological specification (target of external ISO 14071 critical review)", and detailed methodology sub-pages exist. A reader clicking the main Methodology link lands on a blank page. - Navigation inconsistency for "Status". The home page's top navigation links Status directly to the Action register and shows no Roadmap link; the Methodology, Architecture and Third-party pages instead show a "Roadmap" item first under Status. The two navigation menus are out of sync.
- A data source used in the reference workbook is missing from the register. The action register (item AR-34) notes that ICE (University of Bath) is the source behind a "BuildX Database" tab, is not a permitted source, and is not yet listed in the third-party register. So at least one real data source is named in one place but absent from the register that is meant to be complete.
- "Number of data sources" is effectively zero in practice. The third-party register lists many EPD programme operators, but the status page shows the first ten seed values (ÖKOBAUDAT-only) are not yet ingested and all totals return empty. A reader could mistake the register's list for data already in use. This document's Part 2 flags that, but the site itself does not state it in one place.
- Study-period conflict. The maintenance/replacement calculation depends on the building's assumed lifetime, and the register records an unresolved conflict: 30 years (a locked decision) versus 50 years (the reference workbook). This affects any B4 (replacement) result.
- The live site may not equal the reviewed source. The action register (AR-45) records that the public URL
chwr-lca.pages.devat one point served an unmerged branch, including a page not present in the main code branch. This means content read from the live site may not correspond to the reviewed/merged source — directly relevant to any document (including this one) grounded in the live pages. - The linked code repository is not publicly accessible. The home page links to
github.com/marcoNEEV/chwr_LCA, but the register states the repository is currently private and will be made public only at a later phase. External readers cannot yet follow that link. - Standards labelling. The home page lists "ISO 21931"; the register lists the specific part "ISO 21931-1:2010". Minor, but worth aligning.
Notes for the implementation session¶
- Source pages actually read in full: the home page (
/), the methodology landing page (/methodology/— a stub), the differentiators page (/methodology/differentiators/), the architecture overview (/architecture/), the third-party register (/third-party/), and the status action register (/status/action-register/). Part 1 draws mainly on the home, differentiators and action-register pages; Part 2(a) on the architecture overview and third-party register §7–8; Part 2(b) on third-party register §2–4 plus the action register's sourcing rows and decisions #25/#26. - Could not be verified / not read: the
/methodology/data-sources/page and the/status/seed-epd-scoreboard/and/status/seed-epd-value-resolution/pages could not be retrieved (the site is not search-indexed and the fetch tool would not open them; this was confirmed by a dedicated retrieval attempt). These are the pages most likely to state, authoritatively and in one place, exactly which seed EPDs have been ingested and their per-material geographic origin. Part 2(b) should be re-checked against/methodology/data-sources/and the seed-EPD scoreboard before publication, and any source or geographic detail there added or corrected. - External-standard descriptions: publisher/identifier details for EN 15804+A2, EN 15978, ISO 21931-1, ISO 14071:2024, EF 3.1 (JRC130796) and ÖKOBAUDAT were confirmed against the standards bodies' and issuers' own pages (ISO, CEN/BSI, EC Joint Research Centre, oekobaudat.de) to make the glossary precise; the project's own site names these standards but does not give their full titles or identifiers.
- Placeholders left: none invented. Where a figure or status is not stated on the pages read, the document says so rather than guessing (e.g. the exact count of ingested seed EPDs is described qualitatively as "not yet ingested / returns empty" from the action register, pending confirmation from the seed-EPD scoreboard).
- Front-matter convention: the site is built with MkDocs + Material for MkDocs; source pages live as
docs/*.md. Rendered pages expose YAML-style metadata (title,canonical,meta-description,meta-generator). No distinctive custom per-page front-matter block (tags, authors, etc.) was observed, so none is added here; match whatever front-matter the neighbouringdocs/*.mdfiles use when adding this page. - Date stamps observed: third-party register "Last updated: Session 5.2 (2026-07-15), maintained by Chiwara S.r.l."; action register "Last swept: Session 8 (2026-07-25)".