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), and BLOCKED (no source at all). A BLOCKED value 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 BLOCKED rather 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 3½ months (end of Phase 3, week 14). 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 held in reserve: 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. Two reasons rule them out. They cannot be licensed for this project: ASHRAE offers no licence for these tables, and any permission it gave would come with restrictions that this project's open-source licence forbids passing on to users. They answer a different question: the tables size air-conditioning equipment for a single hot design day, whereas the European building-LCA standard (EN 15978) asks for the energy used across the whole study period. The project therefore 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. Revised 27 September 2026 after Chiwara challenged our account of the ASHRAE method — see the note at the end of this section.

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 American engineering tables (ASHRAE's cooling-load temperature difference method). The spreadsheet adjusts those tables for latitude and month using its own correction table, which gives values 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. An audit of the spreadsheet found it never did. Its cooling chain reads a block of numbers copied from the 12°N row, 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. (Whether the spreadsheet's latitude rows match ASHRAE's own published correction table exactly has not been checked against an original ASHRAE copy.)

Three further problems ruled the method out:

It answers a different question. The ASHRAE method sizes air-conditioning equipment for a single hot design day. The European standard for building life-cycle assessment (EN 15978) defines operational energy (module B6) as the energy the building uses across the whole study period, in kilowatt-hours. The spreadsheet gets from one to the other by counting one design day 19 to 22 times for each month. ASHRAE's own guidance keeps annual energy for hour-by-hour methods.
It is the least accurate of the established methods, and it runs high in hot climates. A 2019 comparison ranked it last of five cooling-load methods, and studies in Hong Kong and Malaysia found it over-predicting by roughly 20 % and 38–79 % respectively.
It cannot be licensed. The tables are copyrighted, ASHRAE offers no licence for them, and any permission it granted would carry restrictions that this project's open-source licence forbids passing on to users.

The method was superseded by ASHRAE in 2001 but never formally withdrawn, and many engineers still use it. The objections above are about this project's needs, not a claim that the method is obsolete. At the project's latitude it is also outside ASHRAE's own stated range: the printed tables are meant for roughly 20–50°N, and 14.7°N is below that.

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. It computes the building's energy use from first principles using the European standard method for annual building energy (EN ISO 52016-1, run hour by hour across all 8 760 hours of the year), implemented in the project's own code. That produces the quantity the standard asks for: energy used over the year, not a peak load on one day. 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.

How this account was corrected. Chiwara raised four objections to how the project had described the ASHRAE method, some on this page and some in correspondence. Checking them changed the account. Two claims made in correspondence were wrong or overstated: that the tables could not represent an earth wall (ASHRAE documents a procedure for any wall build-up) and that they applied only to May–September (that describes a different, older factor). On this page, the latitude rows had been presented as ASHRAE's published tables; they are in fact the spreadsheet's own correction table. And the method had been described elsewhere on the site as "deprecated" when "superseded" is accurate. The licence problem, and the fact that the tables measure a different quantity, both stand. The full record is §9 of the climate data licence clearance.

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. (Resolved 2026-09-28: the Architecture and Differentiators pages, licence headers and API contact now all say "chwr LCA"; "Sankofa LCA" survives only as the working title under trademark search, AR-40.)
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.dev at 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 neighbouring docs/*.md files 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)".