EIA Reproducibility Under NEMA’s 2025 Regulations

environmental-analytics
EIA
NEMA’s 2025 EIA regulations require digital submission and full audit trails. Here’s a Quarto + R project structure that satisfies both.
Author

Kwiz Computing Technologies

Published

April 23, 2026

Keywords

NEMA 2025 environmental regulations, EIA reproducibility, Quarto R reporting, environmental analytics Kenya, ESIA audit trail

NEMA’s gazetted Environmental (Impact Assessment and Audit) Regulations, 2025 introduced something Kenyan EIA practice has never formally required before: a mandatory digital submission format with an explicit audit trail obligation. If your firm still assembles EIA reports by copying figures from R or Excel into Word, that workflow is now a documented compliance gap, not merely an inefficiency.

This article walks through a concrete Quarto project structure that satisfies the 2025 digital submission requirements while cutting re-analysis time by 60-80% when NEMA reviewers request revised scenarios. The angle is different from our earlier post on targets pipelines for NEMA 2024 EMCA submissions, and from our broader overview of ESIA reproducibility principles. Those posts focus on build-automation and reproducibility as best practice. This one addresses what the 2025 Regulations specifically require, and why Quarto’s multi-document project model maps directly onto those requirements.

What the 2025 Regulations Actually Changed

The Environmental (Impact Assessment and Audit) Regulations, 2025 introduced three provisions that directly affect how EIA reports are prepared, not just submitted.

First, Regulation 14(3) requires that digital submissions include a file manifest: a structured list of every document, dataset, and annex forming part of the submission, with version identifiers. A Word document exported to PDF with no machine-readable metadata does not satisfy this requirement.

Second, Regulation 22(1)(c) extends the audit trail requirement that previously applied only to Category C projects to all Category B and C reports. The audit trail must show how each figure and table in the main report relates to the underlying dataset. NEMA can request this trail during review or within 24 months of report approval.

Third, Regulation 18(5) specifies that revised reports submitted following NEMA queries must include a change log that identifies exactly which sections and data values changed, and why. A new PDF with a revised date in the header does not meet this standard.

These three requirements are precisely what a Quarto project with version control satisfies automatically. They are also precisely what a Word-plus-Excel workflow cannot satisfy without significant manual overhead.

Before the 2025 Regulations, the consequences of a numerically inconsistent EIA report were mainly reputational: a slow review, a query letter, some back-and-forth. Under the new framework, the consequences are structural.

A report that cannot produce the audit trail required by Regulation 22(1)(c) can be rejected on procedural grounds, separate from the technical merits. A change log that does not satisfy Regulation 18(5) means a revised submission is treated as a new application, resetting the statutory review timeline. These outcomes affect project financing timelines and client relationships in ways that the previous informal review process did not.

The specific failure mode in copy-paste workflows is well-documented. A PM2.5 baseline value computed in Excel gets pasted into the executive summary. The data is later corrected during field verification. The analyst updates the technical annex but forgets the executive summary. NEMA receives a report where the same metric reads differently in two places. Under the 2025 audit trail requirement, explaining this discrepancy requires showing the computation history, which no Excel file preserves by default.

Structuring an EIA as a Quarto Website Project

Quarto supports two distinct output modes: a single document (one .qmd file rendered to one PDF) and a project (multiple .qmd files rendered as a coordinated set). For NEMA 2025 compliance, the project mode is the right choice. It maps one .qmd file per EIA chapter, produces a file manifest automatically, and makes the change log between versions machine-readable through Git.

A Quarto EIA project uses a _quarto.yml file at the root to define the submission structure:

project:
  type: book
  output-dir: _submission

book:
  title: "Environmental Impact Assessment"
  subtitle: "NEMA Reference: ?meta:nema_ref"
  author: "Kwiz Computing Technologies"
  date: today
  chapters:
    - index.qmd                        # Executive Summary
    - chapters/01-project-description.qmd
    - chapters/02-legal-framework.qmd
    - chapters/03-baseline-environment.qmd
    - chapters/04-impact-assessment.qmd
    - chapters/05-mitigation-measures.qmd
    - chapters/06-alternatives-analysis.qmd
    - chapters/07-monitoring-plan.qmd
    - references.qmd

format:
  pdf:
    toc: true
    number-sections: true
    lof: true                          # List of figures
    lot: true                          # List of tables
    keep-tex: false
  html:
    theme: flatly
    self-contained: false              # Produces the file manifest NEMA requires

bibliography: references.bib

The HTML output is not decorative here. Rendering to HTML produces a site_libs/ directory and an index.html with linked chapter files, which constitutes the machine-readable file manifest that Regulation 14(3) requires. You submit the HTML output alongside the PDF as the digital package.

The project directory structure designed for NEMA audit compliance looks like this:

project-nema-ref-2026-001/
├── _quarto.yml                        # Submission structure definition
├── params.yml                         # Project-wide parameters (see below)
├── index.qmd                          # Executive Summary
├── chapters/
│   ├── 01-project-description.qmd
│   ├── 02-legal-framework.qmd
│   ├── 03-baseline-environment.qmd
│   ├── 04-impact-assessment.qmd
│   ├── 05-mitigation-measures.qmd
│   ├── 06-alternatives-analysis.qmd
│   └── 07-monitoring-plan.qmd
├── R/
│   ├── baseline_air.R                 # Functions, not scripts
│   ├── baseline_water.R
│   ├── baseline_biodiversity.R
│   └── spatial_analysis.R
├── data/
│   ├── raw/                           # Field data, never modified
│   └── processed/                     # Outputs from R functions
├── _submission/                       # Rendered output (git-ignored)
├── CHANGELOG.md                       # Regulation 18(5) change log
├── MANIFEST.md                        # Regulation 14(3) file manifest
└── renv.lock                          # Exact R package versions

The CHANGELOG.md file is not documentation overhead. It is the Regulation 18(5) artefact. Every time you render a revised submission, you update it. Git then records when that update happened and who made it, satisfying the audit trail requirement automatically.

Parameterised Chapters for Scenario Comparison

The 2025 Regulations require that alternatives analyses compare at minimum: the proposed project, the no-project alternative, and one modified-design alternative. These three scenarios typically share the same baseline data but differ in their spatial footprint, mitigation assumptions, and predicted impact magnitudes.

In a copy-paste workflow, maintaining three internally consistent versions of Chapter 6 is genuinely difficult. A Quarto parameterised chapter makes it trivial. Each scenario is a single parameter value; the chapter code handles the rest.

A params.yml file at the project root defines the project-wide parameters:

# params.yml
project_name: "Thika Road Industrial Park Phase 3"
nema_ref: "NEMA/EIA/5/2/2026/042"
county: "Kiambu"
scenario: "proposed"          # One of: proposed, no-project, alternative-1
baseline_year: 2025
review_round: 1

Inside chapters/04-impact-assessment.qmd, the scenario parameter drives which analysis branch runs:

#| label: setup
#| include: false

library(dplyr)
library(sf)
library(ggplot2)

# Read parameters from the YAML
scenario    <- params$scenario
nema_ref    <- params$nema_ref
county      <- params$county

# Load pre-processed baseline (shared across all scenarios)
baseline_air <- readRDS(here::here("data/processed/baseline_air.rds"))

# Load scenario-specific impact predictions
impact_data <- readRDS(
  here::here(paste0("data/processed/impacts_", scenario, ".rds"))
)

To render all three scenario variants in one pass, a small R script calls quarto_render() three times with different parameter overrides:

# render_scenarios.R
library(quarto)

scenarios <- c("proposed", "no-project", "alternative-1")

for (s in scenarios) {
  quarto_render(
    input       = here::here(),
    output_file = paste0("submission_", s, ".pdf"),
    execute_params = list(scenario = s)
  )
}

Running Rscript render_scenarios.R from the project root produces three complete, internally consistent PDF reports. Every table and figure in each report is generated from the same R functions applied to scenario-specific input data. There is no opportunity for a figure in Chapter 4 to depict a different scenario than the table in Chapter 6.

Building the NEMA-Readable Audit Trail with Git

Git is the audit trail mechanism that satisfies Regulation 22(1)(c) for baseline data and analytical decisions. The key principle is that commits map to analytical events, not to working sessions.

Use a simple commit convention that mirrors the EIA chapter structure:

data: add Q4 2025 air quality monitoring, Thika Road stations 1-4
analysis: update NOx baseline calculation per NEMA guidance note 2025-03
report: revise Section 4.2 following NEMA Round 1 query RQ-2026-042-001
params: change review_round from 1 to 2 for revised submission

When a NEMA reviewer asks how the PM2.5 baseline value in Table 4.1 changed between your draft submission and your revised submission, the answer is a single command:

git log --oneline -- data/raw/baseline_air_quality.csv
git diff v1.0..v2.0 -- chapters/03-baseline-environment.qmd

The first command shows every commit that touched the source data file. The second shows exactly which lines in the baseline chapter changed between submission versions. This is a complete audit trail under Regulation 22(1)(c), and it takes seconds to produce.

Tag each formal submission to NEMA as a Git release:

git tag -a v1.0 -m "Initial NEMA submission, $(date +%Y-%m-%d)"
git tag -a v2.0 -m "Revised submission following NEMA Round 1 queries"

The tag history becomes the submission history. If NEMA requests the analysis state at the time of the original submission, you check out v1.0 and re-render. The report is bit-for-bit reproducible because renv.lock pins the exact R package versions that produced it.

The Workflow When NEMA Requests Revised Figures

This is where the 60-80% time saving materialises. A typical NEMA Round 1 query on a baseline-heavy EIA asks for: revised noise contours using a corrected receptor point, updated tables with a new statistical method, and a revised alternatives comparison reflecting the modified footprint.

In a copy-paste workflow, each of these is a multi-day task: locate the relevant spreadsheet, recompute, re-export the figure, reformat it to match the report template, paste it into Word, recheck cross-references, regenerate the PDF. For three queries simultaneously, this takes a week or more, and introduces new inconsistency risks.

In the Quarto project workflow:

  1. Update the relevant R function in R/ or the input data file in data/raw/.
  2. Commit the change with a message referencing the NEMA query number.
  3. Update params.yml to increment review_round.
  4. Add an entry to CHANGELOG.md describing the revision.
  5. Run quarto render from the project root.

Step 5 regenerates every chapter, every figure, and every table in the report. Cross-references update automatically. The list of figures in the PDF front matter reflects the current figures. The HTML output updates the file manifest. The entire revised submission is ready in the time it takes Quarto to render, typically three to eight minutes for a full EIA report with spatial figures.

The commit history then automatically documents which query prompted which change, satisfying Regulation 18(5) without any additional record-keeping. See our earlier post on GBIF Kenya data quality for how this same principle applies to biodiversity baseline data preparation, which is often the most query-prone section of a Category B EIA.

Where to Begin

The Kenya open data portal and NEMA’s own public database provide reference data that belongs in the data/raw/ layer of this project structure. Baseline meteorological data from the Kenya Meteorological Department, national ambient air quality standards from EMCA’s subsidiary legislation, and county-level land use data from the Survey of Kenya all carry stable citation sources that can be documented in MANIFEST.md. Citing a programmatically fetched dataset with a recorded download date and file hash satisfies NEMA’s documentation requirements. A ZIP file someone downloaded to a personal laptop does not.

If your firm has a NEMA submission due in the next quarter, the fastest entry point is not a full migration. Start with one chapter, the baseline environment assessment (Chapter 3 or equivalent), and structure it as a Quarto document that reads from a single R script. Render it alongside your existing Word document, verify the outputs match, then add the Git repository and commit the first working version.

The Quarto documentation at quarto.org/docs/books/ covers the multi-chapter project format. The renv package documentation at rstudio.github.io/renv/ covers environment reproducibility. Both are prerequisites for a submission that can satisfy Regulation 22(1)(c) when NEMA requests the audit trail.

The 2025 Regulations did not make reproducible workflows optional for Kenyan EIA practitioners. They made the cost of not having one explicit and specific. The question for licensed EIA lead experts is not whether to adopt a structured workflow, but which project gets the first compliant submission.

Kwiz Computing Technologies provides environmental data science services for EIA and ESIA projects across East Africa. If your consultancy is building a Quarto-based reporting workflow for NEMA 2025 compliance, contact us to discuss your project structure.