Skip to content

What makes this tool different

This page documents the four methodological properties that distinguish Sankofa LCA from mainstream commercial LCA tools in the context of earth-based construction in Sub-Saharan Africa. Each claim is tied to a locked decision in PROJECT.md or a normative standard. These are not marketing assertions; they are verifiable properties of the implementation.

1. Provenance-gated numbers — no silent defaults

Every value that enters a reported result carries one of three explicit provenance tags:

Tag Meaning Implementation
SOURCED Normative citation: ISO/CEN standard, EPD programme operator, named peer-reviewed paper Required for all impact factors and material properties
EXPERT-JUDGEMENT Named Chiwara practitioner (name, date, basis, representativeness) Permitted only for project-specific geometric constants; never for impact factors
BLOCKED No normative source, no attributed judgement Module raises ValueError at runtime; no default, no fallback

A BLOCKED parameter makes the data gap audible in the code. Every caller sees it; it cannot be silently worked around. A SOURCED parameter can be traced to its originating document at any time.

Normative basis: ISO 14044 §4.3.2 (data quality requirements); ISO 14071 external critical review requirements for comparative assertions.

Decision reference: PROJECT.md decision #23 (two-axis parity-and-provenance verdict scheme).

2. Excel treated as requirements artifact, not oracle

Commercial and research tools commonly reverse-engineer Excel workbooks and port their outputs directly, treating numerical agreement with the spreadsheet as the quality gate. Sankofa LCA does not do this.

The reference Excel workbooks (reference/excel/) are requirements artifacts: they document what the project team intended to calculate. A separate reconciliation pass — applied by an independent sub-chat before any code is written — audits each formula against its normative basis. Formulas that are structurally wrong (wrong-row references, missing parentheses, incorrect geometry, missing formulas) receive a CORRECTED verdict. The Python implementation produces the corrected value, not the Excel value.

For every CORRECTED formula, a divergence test asserts the expected numerical difference between the buggy Excel output and the corrected Python output, and cites the normative basis for the correction. A blanket parity test against the buggy Excel output would silently ship demonstrated errors into reported results.

Normative basis: EN 15978 §6 (calculation requirements); ISO 14044 §4.3 (data quality); ISO 14071 (critical review — a reviewer auditing the formulas must find the code defensible against the standard, not merely consistent with the spreadsheet).

Decision reference: PROJECT.md decision #23. Five corrections (C1–C5) are documented for the quantities module in docs/methodology/quantities-formula-reconciliation.md.

3. Project-owned classification spine — no vendored tables, no continuity risk

Earth-based materials (adobe, CEB, CSEB, earth render) do not have established codes in any widely used construction classification system, including Uniclass 2015. Vendoring a third-party classification table also creates a licence constraint (Uniclass carries a CC BY-ND 4.0 NoDerivatives licence that prohibits adapted derivatives) and a continuity risk (table updates outside the project's control can break domain logic).

Sankofa LCA's domain logic reads only MaterialCategory — a project-owned Python StrEnum in backend/app/schemas/enums.py. External classification codes (Uniclass 2015, IFC entity codes, UN CPC v2.1) may be attached to records as user-supplied metadata and are validated for format only (regex patterns). No external classification table is committed to the repository; no membership check against an external table is ever performed.

Earth materials appear in MaterialCategory with first-class codes (RAW_EARTH, AGGREGATE_FINE, AGGREGATE_COARSE, etc.) from the first implementation. They are never a residual category.

Normative basis: No external standard mandates a specific classification system for LCA calculations. The choice is governed by ISO 14040 §4.3.3 (system boundary definition must be traceable) and ISO 14044 §4.3.2 (data quality must be documented).

Decision references: PROJECT.md decisions #19 (project-owned classification spine), #22 (no-vendored-NoDerivatives-data policy). See also THIRD_PARTY.md §5.

4. First-class, provenance-gated RSL for earth materials — correcting the systematic omission

The most common error in LCA comparisons between earth-based and conventional construction is omitting or underestimating maintenance and replacement (EN 15978 Module B4). Earth renders in Sub-Saharan Africa wet-dry climates have short Reference Service Lives (RSL); omitting B4 systematically flatters earth versus concrete and does not reflect in-use costs or impacts. An external ISO 14071 reviewer auditing a comparative assertion would flag this omission.

Sankofa LCA treats RSL as a first-class parameter, not a hardcoded multiplier:

  • RSL is stored per material and assembly alongside the installed quantity.
  • RSL is provenance-gated under the same three-tag scheme as impact factors: SOURCED / EXPERT-JUDGEMENT (attributed) / BLOCKED (raises).
  • There is no "never-replaced" default. If no RSL can be sourced or attributed, the module raises ValueError, making the gap explicit.
  • lca.b4 computes: replacements = ⌈ study period ÷ RSL ⌉ − 1 (EN 15978 §6.2.5 + ISO 15686-1 and -8).

Published earth-render RSL data for Sub-Saharan Africa climates is scarce. A dedicated Phase-2 RSL sourcing sub-chat is required before lca.b4 can be implemented (see ROADMAP.md Phase 2). The data gap is recorded as BLOCKED in the implementation, not silently filled with an assumption.

Normative basis: EN 15978 §6.2.5 (B4 replacement module); ISO 15686-1 (service life planning); ISO 15686-8 (reference service life data); ISO 14044 §6.2 (comparative assertions require equivalent functional equivalence including maintenance scenarios).

Decision reference: PROJECT.md decision #24. See also GitHub issue #11 and docs/architecture/data-flow.md (quantities → B4 data-model seam, footnote ❸).