What the GHGP Scope 3 Standard Actually Requires

The GHG Protocol Corporate Value Chain Standard is not a regulation. It is a widely adopted methodology framework that organises the 15 Scope 3 categories into two groups.

Upstream categories (1-8) cover activities related to purchased inputs:

1. Purchased goods and services
2. Capital goods
3. Fuel- and energy-related activities
4. Upstream transportation and distribution
5. Waste generated in operations
6. Business travel
7. Employee commuting
8. Upstream leased assets

Downstream categories (9-15) cover what happens after you sell:

9. Downstream transportation and distribution
10. Processing of sold products
11. Use of sold products
12. End-of-life treatment of sold products
13. Downstream leased assets
14. Franchises
15. Investments

For most Kenyan manufacturers, importers, and service firms, categories 1 (purchased goods and services) and 6 (business travel) tend to dominate. A Nairobi-based FMCG company sourcing raw materials from across East Africa will find that category 1 alone can account for 60-80% of total Scope 3.

The standard distinguishes between required and optional categories depending on your industry, but the expectation from voluntary frameworks like CDP and the emerging ISSB standards is that material categories must be disclosed with a credible methodology.

Two Methods: Spend-Based and Activity-Based

There are two practical approaches for quantifying Scope 3 emissions, each with different data requirements and accuracy levels.

Activity-based methods multiply physical activity data (tonnes of material purchased, kilometres travelled, cubic metres of waste) by a corresponding emission factor. They are more accurate but require granular procurement data that most Kenyan companies do not yet collect systematically.

Spend-based methods multiply financial spend data (cost in USD or KES) by an economic emission intensity factor, expressed in kg CO2e per unit of spend in a given industry sector. This is the practical starting point for organisations beginning their Scope 3 journey.

The US EPA’s Environmentally Extended Input-Output (USEEIO) model provides spend-based emission factors for 411 industry sectors of the US economy. While built on US data, these factors are used globally as a first-approximation tool. Exiobase, a multi-regional input-output database covering 44 countries and 5 rest-of-world regions, offers geographically closer factors for some East African supply chains, though it requires more pre-processing.

For a Kenyan company in 2026, a reasonable starting protocol is: use USEEIO factors for categories where supply chains are internationally sourced (electronics, vehicles, chemicals), and supplement with locally derived activity-based factors where Kenyan context is available.

Building the R Workflow

The workflow below demonstrates Scope 3 category 1 (purchased goods and services) using spend data and USEEIO emission factors. The same pattern extends to any spend-based category.

library(tidyverse)

# Download USEEIO v2.0 supply chain GHG factors
# Source: https://www.epa.gov/system/files/documents/2024-01/useeio_2.0_supply_chain_ghg_emission_factors_v1.1.csv
useeio_url <- paste0(
  "https://www.epa.gov/system/files/documents/2024-01/",
  "useeio_2.0_supply_chain_ghg_emission_factors_v1.1.csv"
)

# Read and clean
useeio_factors <- read_csv(useeio_url, show_col_types = FALSE) |>
  select(
    sector_code   = `2017 NAICS Code`,
    sector_name   = `2017 NAICS Title`,
    ghg_factor    = `Supply Chain Emission Factors without Margins (kg CO2e/2021 USD)`
  ) |>
  mutate(
    sector_code = as.character(sector_code),
    ghg_factor  = as.numeric(ghg_factor)
  ) |>
  filter(!is.na(ghg_factor))

head(useeio_factors, 5)

# Example procurement data for a Kenyan manufacturer
# In practice, this comes from your ERP or accounts payable system
procurement <- tibble(
  category      = c("Steel & fabricated metals", "Plastic packaging",
                    "Chemical inputs", "Road freight", "IT equipment"),
  naics_code    = c("332", "3261", "325", "4841", "334"),
  spend_ksh     = c(12_500_000, 4_800_000, 7_200_000, 3_100_000, 1_900_000),
  spend_usd     = spend_ksh / 130  # approximate KES/USD exchange rate
)

# Aggregate USEEIO factors to 3-digit NAICS for the join
# (USEEIO provides 6-digit detail; our procurement may only have 3-digit codes)
useeio_3digit <- useeio_factors |>
  mutate(naics_3 = str_sub(sector_code, 1, 3)) |>
  summarise(
    ghg_factor = mean(ghg_factor, na.rm = TRUE),
    .by = naics_3
  )

# Join and compute
scope3_cat1 <- procurement |>
  left_join(useeio_3digit, by = c("naics_code" = "naics_3")) |>
  mutate(
    emissions_kg_co2e   = spend_usd * ghg_factor,
    emissions_tco2e     = emissions_kg_co2e / 1000
  )

# Summary
scope3_cat1 |>
  summarise(
    total_spend_usd    = sum(spend_usd),
    total_tco2e        = sum(emissions_tco2e, na.rm = TRUE)
  )

library(ggplot2)

scope3_cat1 |>
  arrange(desc(emissions_tco2e)) |>
  mutate(category = fct_inorder(category)) |>
  ggplot(aes(x = emissions_tco2e, y = category, fill = emissions_tco2e)) +
  geom_col(show.legend = FALSE) +
  scale_fill_gradient(low = "#aed6b1", high = "#2d6a4f") +
  scale_x_continuous(labels = scales::comma) +
  labs(
    title    = "Scope 3 Category 1: Purchased Goods and Services",
    subtitle = "Spend-based estimates using USEEIO v2.0 emission factors",
    x        = "Estimated emissions (tCO2e)",
    y        = NULL,
    caption  = "Emission factors: EPA USEEIO v2.0 | Spend converted at 130 KES/USD"
  ) +
  theme_minimal(base_size = 13)

Kenya-Specific Context: NSE, NEMA, and What Is Coming

No Kenyan statute currently mandates Scope 3 disclosure. But three forces are changing the calculation for NSE-listed companies and large private firms.

First, the Capital Markets Authority’s draft sustainability reporting guidelines, aligned with ISSB’s IFRS S2, include climate-related disclosures. IFRS S2 explicitly references the GHG Protocol and expects material Scope 3 categories to be disclosed once the standard is adopted, which is anticipated for listed companies.

Second, multinational buyers are increasingly passing climate requirements down their supply chains. A Kenyan exporter selling to European retailers operating under the EU Corporate Sustainability Reporting Directive (CSRD) will find that their Scope 3 category 1 emissions become their customer’s Scope 3 category 1 concern. Supply chain pressure is already the fastest path to mandatory Scope 3 disclosure for Kenyan exporters.

Third, NEMA’s environmental management framework continues to expand. While NEMA’s current focus is on direct environmental impacts assessed through EIAs (see our post on ESIA reproducibility), GHG accounting is increasingly part of environmental management plans for large projects.

The East African context also shapes which Scope 3 categories matter most. Companies sourcing from smallholder agricultural supply chains in the region (coffee, tea, cut flowers, macadamia) carry significant upstream land-use change emissions in category 1 that USEEIO factors, built on US industry data, will systematically underestimate. For these sectors, activity-based accounting with Africa-specific emission factors from sources like the IPCC national inventory guidelines or the Cool Farm Tool is more appropriate.

Limitations and the Path to Better Data

The spend-based method is a starting point, not a final answer. USEEIO factors represent average US industrial emissions intensity, which diverges from Kenyan supply chain reality in significant ways. The electricity grid in Kenya is far cleaner than the US average (roughly 90% renewable generation), so any factor applied to energy-intensive local processes will overestimate actual emissions. Conversely, for imported goods produced in coal-heavy economies, USEEIO may underestimate.

The improvement path is sequential. Start with spend-based estimates to identify material hotspots. Then focus data collection effort on the top two or three categories by estimated emissions. Transition those categories to activity-based accounting using actual supplier data or industry-specific factors. The remaining categories can stay on spend-based estimates indefinitely if they are not material.

For organisations building this capability from scratch, our Kenya open data post covers how to access public datasets programmatically. The same principles apply to structuring your internal ESG data for repeatable analysis.

Building a Defensible, Auditable GHG Inventory

A Scope 3 inventory only has value if it can withstand scrutiny. Three practices make the difference between a credible disclosure and a spreadsheet exercise.

Document your methodology explicitly: which categories you calculated, which method you used per category, which emission factor database and vintage you applied, and what assumptions you made on currency conversion or NAICS mapping. The GHG Protocol provides an assurance readiness checklist as part of its Scope 3 guidance.

Version-control your calculation code. An R script under git history is a better audit trail than an Excel file with “final_v3_FINAL.xlsx” in the name. Quarto reports render the methodology narrative and the computed results together, so there is no gap between what you documented and what you calculated. This mirrors the reproducibility principles we apply to environmental impact assessments.

Apply uncertainty bounds. Spend-based emission factors carry large uncertainty ranges, typically plus or minus 30-50%. Reporting a single point estimate without acknowledging this overstates precision. A simple Monte Carlo simulation over the factor distributions communicates the range of possible outcomes and builds credibility with sophisticated reviewers.

Scope 3 accounting separates organisations that are genuinely working through their climate exposure from those producing disclosure documents for appearances. The methodology is not opaque, and the tools are not expensive. What it requires is structured procurement data, a clear methodology, and a willingness to show your work.

If your organisation is working through this for the first time, what is the biggest obstacle you are running into: data quality, methodology uncertainty, or internal buy-in for the process?

Kwiz Computing Technologies provides ESG analytics services for Kenyan and East African organisations, including GHG inventory design, reproducible Scope 3 workflows in R, and sustainability reporting support. Reach out if you want to build this capability in-house or need a partner for your next climate disclosure.

The Realistic Data Mess: M-Pesa Aggregation

Consider a Nairobi-based B2B distributor that processes payments through Safaricom’s M-Pesa Bulk Disbursement API. Every morning, the finance team exports three separate data artefacts:

• M-Pesa transaction CSVs from the Business Pay portal, one file per settlement batch, inconsistent column names across Safaricom API versions
• USSD session logs from their internal USSD shortcode, a pipe-delimited flat file recording which merchants initiated which sessions
• CRM export from their Salesforce instance, JSON-formatted, containing merchant master data including county, tier, and assigned sales rep

The current process: a finance analyst manually downloads all three, pastes them into a master Excel sheet, and sends it to the sales director by 10 a.m. When the analyst is out sick, the director works blind. When two M-Pesa API versions are running simultaneously (which Safaricom does during gradual rollouts), the manual merge produces silent duplicates.

This is the pipeline we will build.

Why {targets} Fits Data Engineering

{targets} is a Make-like pipeline orchestrator for R. Each unit of computation is a “target” defined by a name, a function, and its dependencies. When you run the pipeline, {targets} builds a directed acyclic graph (DAG) of all targets, checks which outputs are already up-to-date, and skips recomputation for any target whose inputs have not changed.

That behaviour matters for ETL. If the CRM export has not changed since yesterday’s run, {targets} will not re-parse and re-validate it. If only the M-Pesa CSV is new, only the targets downstream of that file get recomputed. This is incremental execution without writing any custom caching logic.

The entire pipeline lives in a _targets.R file at the project root:

# _targets.R
library(targets)
library(tarchetypes)

tar_option_set(
  packages = c(
    "dplyr", "readr", "jsonlite", "arrow",
    "DBI", "RPostgres", "pointblank", "lubridate"
  ),
  # Store intermediate targets as Arrow/Parquet files
  format = "parquet"
)

# Source pipeline functions
tar_source("R/")

list(
  # ── Raw ingest targets ───────────────────────────────────────────────────
  tar_target(
    mpesa_raw,
    ingest_mpesa_csvs("data/raw/mpesa/"),
    format = "parquet"
  ),
  tar_target(
    ussd_raw,
    ingest_ussd_logs("data/raw/ussd/session_log.psv"),
    format = "parquet"
  ),
  tar_target(
    crm_raw,
    ingest_crm_json("data/raw/crm/merchants.json"),
    format = "parquet"
  ),

  # ── Validation targets ───────────────────────────────────────────────────
  tar_target(mpesa_validated,   validate_mpesa(mpesa_raw)),
  tar_target(ussd_validated,    validate_ussd(ussd_raw)),
  tar_target(crm_validated,     validate_crm(crm_raw)),

  # ── Transform to canonical schema ───────────────────────────────────────
  tar_target(
    transactions_canonical,
    build_transactions(mpesa_validated, ussd_validated, crm_validated),
    format = "parquet"
  ),

  # ── Warehouse write ──────────────────────────────────────────────────────
  tar_target(
    warehouse_write,
    write_to_warehouse(transactions_canonical),
    format = "rds"   # Return a status object, not the data itself
  )
)

Run the full pipeline with tar_make(). Inspect the dependency graph with tar_visnetwork(). Check which targets are outdated with tar_outdated(). These three functions cover most of the operator workflow.

Raw Ingest Functions

The M-Pesa portal produces CSVs with shifting column names. Safaricom’s API v2 uses TransactionID; v3 uses transaction_id. The ingest function normalises both:

# R/ingest.R

ingest_mpesa_csvs <- function(dir_path) {
  csv_files <- list.files(dir_path, pattern = "\\.csv$", full.names = TRUE)

  if (length(csv_files) == 0) {
    stop("No M-Pesa CSV files found in: ", dir_path)
  }

  purrr::map(csv_files, function(f) {
    df <- readr::read_csv(f, show_col_types = FALSE)

    # Normalise column names: handle v2 and v3 API schemas
    df |>
      dplyr::rename_with(tolower) |>
      dplyr::rename_with(~ gsub(" ", "_", .x)) |>
      # Coerce either naming convention to canonical names
      dplyr::rename(
        any_of(c(
          transaction_id    = "transactionid",
          merchant_phone    = "phone_number",
          amount_kes        = "amount",
          transaction_date  = "date",
          transaction_date  = "transactiondate"
        ))
      ) |>
      dplyr::mutate(
        source_file = basename(f),
        ingested_at = lubridate::now("Africa/Nairobi")
      )
  }) |>
    dplyr::bind_rows()
}

ingest_ussd_logs <- function(file_path) {
  readr::read_delim(
    file_path,
    delim = "|",
    col_types = readr::cols(
      session_id   = readr::col_character(),
      phone        = readr::col_character(),
      initiated_at = readr::col_datetime(format = "%Y-%m-%d %H:%M:%S"),
      menu_path    = readr::col_character(),
      completed    = readr::col_logical()
    )
  ) |>
    dplyr::mutate(ingested_at = lubridate::now("Africa/Nairobi"))
}

ingest_crm_json <- function(file_path) {
  raw <- jsonlite::read_json(file_path, simplifyVector = TRUE)
  tibble::as_tibble(raw) |>
    dplyr::mutate(ingested_at = lubridate::now("Africa/Nairobi"))
}

Keeping ingest functions pure (no side effects, no database calls) means {targets} can cache their outputs independently. If only the USSD log changes, the M-Pesa ingest result stays cached.

Validation with {pointblank}

Silent bad data is worse than a failed pipeline. A single duplicated transaction_id or a NULL merchant_phone can corrupt downstream aggregations without raising any errors. The validation step makes those problems loud:

# R/validate.R

validate_mpesa <- function(df) {
  agent <- pointblank::create_agent(tbl = df, label = "M-Pesa validation") |>
    pointblank::col_is_character(vars(transaction_id)) |>
    pointblank::col_vals_not_null(vars(transaction_id, amount_kes, merchant_phone)) |>
    pointblank::col_vals_gt(vars(amount_kes), value = 0) |>
    pointblank::col_vals_regex(
      vars(merchant_phone),
      regex = "^2547[0-9]{8}$"   # Safaricom 07xx -> 2547xx normalised
    ) |>
    pointblank::rows_distinct(vars(transaction_id)) |>
    pointblank::interrogate()

  # Fail the pipeline target if critical checks do not pass
  if (pointblank::all_passed(agent) == FALSE) {
    stop(
      "M-Pesa validation failed. Run pointblank::get_agent_report(agent) to inspect.\n",
      "Failed checks: ",
      paste(pointblank::get_sundered_data(agent, type = "fail") |> nrow(), "rows rejected")
    )
  }

  # Return only rows that passed all checks
  pointblank::get_sundered_data(agent, type = "pass")
}

The same pattern applies to USSD and CRM targets. Failed validation stops the pipeline at the right point, before bad data reaches the warehouse.

Arrow/Parquet for Intermediate Storage

The format = "parquet" argument in tar_option_set() tells {targets} to serialise each target’s output as a Parquet file rather than an RDS object. For a few million M-Pesa rows, this matters: Parquet files are 5-10x smaller than equivalent RDS files, read faster with columnar access patterns, and can be queried directly by DuckDB or shared with Python colleagues without conversion.

For targets that need to cross the R-to-R boundary within the pipeline, this is transparent. {targets} reads and writes Parquet automatically using {arrow}. For targets that need further processing before the warehouse write, you can work with Arrow tables directly:

# R/transform.R

build_transactions <- function(mpesa, ussd, crm) {
  # Join M-Pesa transactions with USSD session data on merchant phone
  transactions <- mpesa |>
    dplyr::left_join(
      ussd |> dplyr::select(phone, session_id, initiated_at, completed),
      by = c("merchant_phone" = "phone"),
      relationship = "many-to-one"
    ) |>
    # Enrich with CRM merchant data
    dplyr::left_join(
      crm |> dplyr::select(phone, merchant_name, county, tier, sales_rep),
      by = c("merchant_phone" = "phone")
    ) |>
    dplyr::mutate(
      transaction_date = lubridate::as_date(transaction_date),
      week_start       = lubridate::floor_date(transaction_date, "week"),
      county           = dplyr::coalesce(county, "Unknown"),
      amount_kes       = as.numeric(amount_kes)
    ) |>
    dplyr::select(
      transaction_id, transaction_date, week_start,
      merchant_phone, merchant_name, county, tier, sales_rep,
      amount_kes, session_id, completed, source_file, ingested_at
    )

  transactions
}

Writing to PostgreSQL with DBI

The warehouse write target connects to PostgreSQL and upserts the canonical transactions table. The pattern uses DBI::dbWriteTable() with a staging table for idempotent loads: write the new batch to a staging table, then merge into the production table on transaction_id. That way, re-running the pipeline after a partial failure does not create duplicates.

# R/warehouse.R

write_to_warehouse <- function(transactions) {
  con <- DBI::dbConnect(
    RPostgres::Postgres(),
    host     = Sys.getenv("PG_HOST"),
    port     = as.integer(Sys.getenv("PG_PORT", "5432")),
    dbname   = Sys.getenv("PG_DB"),
    user     = Sys.getenv("PG_USER"),
    password = Sys.getenv("PG_PASSWORD")
  )
  on.exit(DBI::dbDisconnect(con), add = TRUE)

  # Write to staging table (overwrite on each run)
  DBI::dbWriteTable(
    con,
    name      = "mpesa_transactions_staging",
    value     = transactions,
    overwrite = TRUE,
    row.names = FALSE
  )

  # Upsert from staging to production table
  DBI::dbExecute(con, "
    INSERT INTO mpesa_transactions (
      transaction_id, transaction_date, week_start,
      merchant_phone, merchant_name, county, tier, sales_rep,
      amount_kes, session_id, completed, source_file, ingested_at
    )
    SELECT
      transaction_id, transaction_date, week_start,
      merchant_phone, merchant_name, county, tier, sales_rep,
      amount_kes, session_id, completed, source_file, ingested_at
    FROM mpesa_transactions_staging
    ON CONFLICT (transaction_id)
    DO UPDATE SET
      amount_kes   = EXCLUDED.amount_kes,
      ingested_at  = EXCLUDED.ingested_at
  ")

  rows_written <- DBI::dbGetQuery(
    con,
    "SELECT COUNT(*) AS n FROM mpesa_transactions_staging"
  )$n

  list(status = "ok", rows = rows_written, timestamp = Sys.time())
}

The function returns a small status list rather than the full dataset. {targets} stores this as an RDS file, keeping the cache small and the pipeline log readable.

Scheduling: Cron and GitHub Actions

The pipeline runs daily. Two scheduling options work cleanly with this {targets} setup.

Cron on a Linux server: A crontab entry calls an R script that sets environment variables from a .Renviron file and runs tar_make():

# Run pipeline Monday-Friday at 07:00 Nairobi time (EAT = UTC+3)
0 4 * * 1-5 /usr/bin/Rscript /opt/pipelines/mpesa-etl/run_pipeline.R >> /var/log/mpesa-etl.log 2>&1

The run_pipeline.R script:

#!/usr/bin/env Rscript
readRenviron("/opt/pipelines/.Renviron")
targets::tar_make(reporter = "timestamp")

GitHub Actions: For teams that store the pipeline in Git (recommended), a workflow file handles scheduling and sends failures to a Slack webhook:

name: M-Pesa ETL Pipeline

on:
  schedule:
    - cron: "0 4 * * 1-5"   # 07:00 EAT, weekdays
  workflow_dispatch:          # Allow manual trigger

jobs:
  run-pipeline:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: r-lib/actions/setup-r@v2
        with:
          r-version: "4.4"

      - name: Restore targets cache
        uses: actions/cache@v4
        with:
          path: _targets/
          key: targets-${{ hashFiles('_targets.R', 'R/**') }}
          restore-keys: targets-

      - name: Run pipeline
        env:
          PG_HOST:     ${{ secrets.PG_HOST }}
          PG_DB:       ${{ secrets.PG_DB }}
          PG_USER:     ${{ secrets.PG_USER }}
          PG_PASSWORD: ${{ secrets.PG_PASSWORD }}
        run: Rscript -e "targets::tar_make(reporter = 'timestamp')"

      - name: Notify on failure
        if: failure()
        uses: slackapi/slack-github-action@v1
        with:
          payload: '{"text": "M-Pesa ETL failed. Check the Actions log."}'
        env:
          SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK }}

The actions/cache step restores the _targets/ store between runs. GitHub Actions only re-runs targets whose inputs changed, because the cached store persists across workflow runs. For a pipeline that ingests daily increments, this means only the new M-Pesa batch gets processed on most days.

Error Handling and Observability

{targets} surfaces errors at the target level. When validate_mpesa throws, the pipeline stops there, the error message goes to stdout (and to the Actions log), and all downstream targets are marked as failed. The CRM and USSD targets, which have no dependency on mpesa_validated, still succeed and get cached.

For production alerting, wrap tar_make() in a tryCatch and notify on failure:

# run_pipeline.R
readRenviron(".Renviron")

tryCatch(
  {
    targets::tar_make(reporter = "timestamp")
    message("Pipeline completed: ", Sys.time())
  },
  error = function(e) {
    msg <- paste0("ETL pipeline failed at ", Sys.time(), "\n", conditionMessage(e))
    message(msg)
    httr2::request(Sys.getenv("SLACK_WEBHOOK")) |>
      httr2::req_body_json(list(text = msg)) |>
      httr2::req_perform()
    quit(status = 1)
  }
)

This pattern keeps the scheduling layer thin. Whether you use cron, GitHub Actions, or a task runner like {rrq}, the pipeline itself handles error propagation through the DAG.

What This Solves in Practice

The Nairobi distributor scenario from the opening is representative of dozens of companies operating at this scale across East Africa: telecom payment data, field agent apps generating USSD logs, and CRM systems that do not talk to each other. The data volumes sit comfortably below 100 GB. The analytical questions (weekly revenue by county, merchant tier performance, sales rep attribution) do not require Spark.

What they require is a pipeline that runs reliably, fails loudly, and does not need a Python engineer to maintain. The {targets} stack delivers that. The finance analyst stops building spreadsheets at 9:45 a.m. The dashboard updates itself. The sales director gets county-level M-Pesa attribution by the time the morning stand-up starts.

A few practical notes from running this pattern with clients in Nairobi and Mombasa. First, store the _targets/ directory on a mounted volume if you run in Docker; it is your cache and you do not want it wiped on container restart. Second, the {dm} package fits naturally between the transform and warehouse-write steps: define your relational model once, use dm_examine_constraints() to catch foreign key violations before the upsert, and you get an extra layer of guarantees without writing SQL assertions by hand. Third, run tar_prune() monthly to clean up cached targets that are no longer referenced by _targets.R; the _targets/objects/ directory grows faster than most teams expect.

If you are managing heterogeneous data sources at this scale, the Python assumption may be costing you more than you realise. The R tooling is ready. The question is whether your architecture is.

For teams that want help designing or reviewing a pipeline like this, Kwiz Computing builds data engineering systems for East African businesses across sectors. We also cover how these pipelines connect to production R deployments in our business leaders guide to R and the R Shiny hosting guide for teams that expose pipeline outputs as interactive dashboards.

What part of your current pipeline breaks most often: ingest, validation, or the warehouse write?

What NEMA Actually Requires

Kenya’s Environmental Impact Assessment and Audit Regulations (Legal Notice 101 of 2003, with subsequent amendments under EMCA) require a biodiversity baseline in every EIA study report. The regulations specify that the report must include a flora and fauna inventory, a description of habitat types, identification of rare or endangered species, and a statement on endemism.

What the regulations do not specify is any data format, column structure, or table layout. Every firm invents its own annex template. A NEMA review officer seeing your report may have reviewed three other EIAs that week, each with a completely different table structure. Inconsistencies between your species count in the narrative and the total in the annex are easy to introduce and easy for a reviewer to spot.

The practical requirement, inferred from review rejections and NEMA guidance notes, is: a complete species inventory with family and order, a habitat association column, IUCN Red List category for each species, a flag for endemic or near-endemic taxa, and observation counts or presence-absence by survey zone. That structure maps directly to a tidy R tibble.

Designing the Canonical Tibble

The data model is the foundation. Every downstream table, summary, and figure reads from this one object. The columns that matter for NEMA compliance are:

library(dplyr)
library(tibble)

# Minimal canonical schema for NEMA biodiversity inventory
species_data <- tibble(
  # Taxonomy
  species        = character(),   # Accepted binomial
  common_name    = character(),
  family         = character(),
  order          = character(),
  class          = character(),   # Aves, Mammalia, Reptilia, etc.

  # Spatial and habitat context
  habitat        = character(),   # Riparian, Savanna, Woodland, etc.
  survey_zone    = character(),   # e.g. "Zone A – Project Footprint"
  observation_count = integer(),
  detection_method = character(), # Transect, Mist-net, Camera-trap, etc.

  # Conservation status
  iucn_category  = character(),   # LC, NT, VU, EN, CR, EW, EX, DD, NE
  cites_appendix = character(),   # I, II, III, or NA
  endemic        = logical(),     # TRUE if Kenya endemic or near-endemic
  protected_under_wcma = logical(), # Wildlife Conservation & Management Act

  # Data provenance
  observer       = character(),
  survey_date    = as.Date(character()),
  record_id      = character()    # Unique key for each observation event
)

Build this once per project, populate it from your field datasheets, and never touch it manually again. If a field team revises their counts, they edit the source CSV. The tibble reads from that CSV. Every downstream product regenerates.

For actual project use, read the canonical tibble from a version-controlled CSV:

species_data <- readr::read_csv(
  "data/raw/biodiversity_field_records.csv",
  col_types = readr::cols(
    survey_date = readr::col_date(format = "%Y-%m-%d"),
    endemic = readr::col_logical(),
    protected_under_wcma = readr::col_logical(),
    observation_count = readr::col_integer()
  )
)

IUCN Red List Status: Lookup Without Manual Copying

Manually typing IUCN categories is where errors accumulate fastest. The rredlist package provides programmatic access to the IUCN Red List API. For field projects in Kenya, you typically work with a bounded species list, so a cached lookup makes more sense than live API calls during report rendering.

library(rredlist)

# One-time lookup: run this when species list is finalised
# Requires IUCN_REDLIST_KEY environment variable
fetch_iucn_status <- function(species_list, cache_path = "data/iucn_cache.rds") {

  if (file.exists(cache_path)) {
    return(readRDS(cache_path))
  }

  results <- purrr::map_dfr(species_list, function(sp) {
    resp <- tryCatch(
      rl_search(name = sp)$result,
      error = function(e) NULL
    )
    if (is.null(resp) || nrow(resp) == 0) {
      return(tibble(species = sp, iucn_category = "NE", iucn_id = NA_integer_))
    }
    tibble(
      species       = sp,
      iucn_category = resp$category[1],
      iucn_id       = resp$taxonid[1]
    )
  })

  saveRDS(results, cache_path)
  results
}

iucn_lookup <- fetch_iucn_status(unique(species_data$species))

# Join back to canonical tibble
species_data <- species_data |>
  select(-iucn_category) |>
  left_join(iucn_lookup, by = "species")

The cache at data/iucn_cache.rds persists across renders. When the IUCN updates a species’ status, you delete the cache file, re-run once, and the new status propagates to every table automatically. This approach also works offline once the cache exists, which matters on field trips with intermittent connectivity.

For projects where the species list is stable and well-known, a hand-curated lookup table stored as a CSV in data/reference/iucn_status.csv is a legitimate alternative. The critical point is that the status column in your canonical tibble is always derived, never typed by hand into the annex.

Species Richness and Diversity Indices

NEMA reviewers expect a summary of species richness by taxonomic group and habitat. Diversity indices (Shannon-Wiener and Simpson) add methodological weight and are standard in peer-reviewed baseline assessments across Kenya’s infrastructure corridor projects.

library(vegan)

# Species richness by class and habitat
richness_summary <- species_data |>
  group_by(class, habitat) |>
  summarise(
    species_richness = n_distinct(species),
    total_observations = sum(observation_count, na.rm = TRUE),
    threatened_spp = sum(iucn_category %in% c("VU", "EN", "CR"), na.rm = TRUE),
    endemic_spp = sum(endemic, na.rm = TRUE),
    .groups = "drop"
  ) |>
  arrange(class, desc(species_richness))

# Shannon-Wiener and Simpson indices per habitat
diversity_by_habitat <- species_data |>
  group_by(habitat, species) |>
  summarise(n = sum(observation_count, na.rm = TRUE), .groups = "drop") |>
  tidyr::pivot_wider(names_from = species, values_from = n, values_fill = 0) |>
  tibble::column_to_rownames("habitat") |>
  (\(m) {
    tibble(
      habitat  = rownames(m),
      H_shannon = vegan::diversity(m, index = "shannon"),
      D_simpson = vegan::diversity(m, index = "simpson"),
      S_richness = vegan::specnumber(m)
    )
  })()

The vegan package computes these indices from a species-by-site matrix. The pipeline above builds that matrix directly from the canonical tibble, so the indices update automatically when field data changes.

Generating the NEMA Annex Tables

The annex tables are where a reproducible workflow delivers the most visible return. A formatted knitr::kable() table with kableExtra styling produces output that matches what NEMA reviewers expect, derived entirely from the canonical tibble.

library(knitr)
library(kableExtra)

# Annex Table A: Complete Species Inventory
annex_inventory <- species_data |>
  arrange(class, order, family, species) |>
  mutate(
    iucn_display = case_when(
      iucn_category == "CR" ~ "CR*",
      iucn_category == "EN" ~ "EN*",
      iucn_category == "VU" ~ "VU*",
      TRUE ~ iucn_category
    ),
    endemic_display = if_else(endemic, "Yes", "No")
  ) |>
  select(
    `Class` = class,
    `Order` = order,
    `Family` = family,
    `Species` = species,
    `Common Name` = common_name,
    `Habitat` = habitat,
    `IUCN Status` = iucn_display,
    `Endemic` = endemic_display,
    `Detections` = observation_count,
    `Method` = detection_method
  )

annex_inventory |>
  kable(
    caption = paste0(
      "Annex A: Biodiversity Species Inventory: ",
      params$project_name,
      " (Survey Period: ", params$survey_period, ")"
    ),
    booktabs = TRUE,
    longtable = TRUE
  ) |>
  kable_styling(
    latex_options = c("repeat_header", "striped"),
    font_size = 9
  ) |>
  footnote(
    general = "* Threatened species (CR: Critically Endangered, EN: Endangered, VU: Vulnerable). IUCN Red List categories per IUCN (2024). Endemic status per Kenya Biodiversity Atlas.",
    threeparttable = TRUE
  )

A second table summarises richness and threat status, which typically appears in the main report body rather than the annex:

# Table in main report: Richness and threat status summary
richness_summary |>
  kable(
    col.names = c("Class", "Habitat", "Species Richness",
                  "Total Detections", "Threatened Spp.", "Endemic Spp."),
    caption = "Table 4.X: Species Richness and Conservation Status Summary by Taxonomic Class and Habitat Type",
    booktabs = TRUE
  ) |>
  kable_styling(latex_options = "striped") |>
  column_spec(5, bold = TRUE, color = "darkred")

Both tables are generated from the same object. If you change a field record in biodiversity_field_records.csv, both update on the next render.

Parameterising for Multi-Project Reuse

Kenya’s infrastructure pipeline means many consultancies run concurrent EIAs. The LAPSSET corridor alone involves environmental studies across Isiolo, Marsabit, and Lamu counties. SGR Phase 2 overlaps with sensitive savanna habitat across the Naivasha-Kisumu alignment. A single parameterised template handles all of them.

---
title: "Biodiversity Baseline Annex: `r params$project_name`"
subtitle: "NEMA Ref: `r params$nema_ref`"
format:
  pdf:
    toc: false
    number-sections: false
params:
  project_name: "Default Project"
  nema_ref: "NEMA/EIA/5/2/XXXX/XXX"
  survey_period: "Q1 2026"
  project_county: "Nairobi"
  project_coords: "1.2921° S, 36.8219° E"
  field_data_path: "data/raw/biodiversity_field_records.csv"
---

Render for each project from the command line:

quarto::quarto_render(
  input = "biodiversity_annex.qmd",
  execute_params = list(
    project_name    = "LAPSSET Port Access Road EIA",
    nema_ref        = "NEMA/EIA/5/2/2026/047",
    survey_period   = "Q4 2025",
    project_county  = "Lamu",
    project_coords  = "2.2717° S, 40.9020° E",
    field_data_path = "data/raw/lapsset_road_biodiversity.csv"
  ),
  output_file = "output/LAPSSET_biodiversity_annex_2026.pdf"
)

The template reads the field data from params$field_data_path, runs the IUCN lookup, computes richness, and renders the full annex. New project, new CSV, same template. The table structure stays consistent across submissions.

Cross-Checking Field Records Against GBIF

Field surveys have finite duration and effort. A useful quality control step is to cross-reference your inventory against GBIF occurrence records for the project area, flagging species present in GBIF that your survey did not record. This does not invalidate your baseline, but it documents the comparison and gives reviewers confidence that your team considered the broader evidence base.

library(rgbif)

# Pull GBIF records within project bounding box
gbif_crosscheck <- function(lat_centre, lon_centre, radius_km = 10) {
  occ_search(
    country     = "KE",
    decimalLatitude  = paste0(lat_centre - 0.1, ",", lat_centre + 0.1),
    decimalLongitude = paste0(lon_centre - 0.1, ",", lon_centre + 0.1),
    hasCoordinate = TRUE,
    limit = 5000
  )$data |>
    select(species, class, family, year, basisOfRecord) |>
    filter(!is.na(species), year >= 2015)
}

gbif_area <- gbif_crosscheck(lat_centre = -1.29, lon_centre = 36.82)

# Species in GBIF but not in field survey
gbif_only <- anti_join(
  gbif_area |> distinct(species),
  species_data |> distinct(species),
  by = "species"
)

The GBIF comparison belongs in the methods section, not the species inventory itself. Our earlier post on GBIF Kenya data quality covers the coordinate cleaning and taxonomic validation steps you should apply to this GBIF pull before using it as a cross-reference. Raw GBIF data without quality filtering will flag phantom species and undermine the comparison.

Project Structure for Biodiversity Annexes

A clean directory layout keeps the pipeline self-contained and legible to any colleague who picks it up:

project-eia-001/
├── biodiversity_annex.qmd       # Parameterised template
├── R/
│   ├── fetch_iucn_status.R      # Cached IUCN lookup function
│   ├── compute_richness.R       # Richness and diversity indices
│   └── build_annex_tables.R     # kable table builders
├── data/
│   ├── raw/
│   │   └── biodiversity_field_records.csv   # Source of truth: never edit directly
│   ├── reference/
│   │   └── iucn_cache.rds       # Cached IUCN API responses
│   └── processed/               # Outputs written by pipeline
└── output/                      # Rendered PDFs

The data/raw/ CSV is the only file field staff need to update. The R/ functions are testable in isolation. The iucn_cache.rds persists between renders. If you also run a {targets} pipeline for the full EIA (as described in our post on EIA reproducibility), the biodiversity tibble is one target in that pipeline, with the annex tables as downstream targets.

The Commercial Case

A single annex regeneration typically takes forty minutes of manual effort on a typical Kenyan EIA project: find the original data, update the relevant rows, reformat the table, check the column totals, update the summary statistics in the narrative, and check whether the threat-status flags are still correct. With the workflow above, the same update takes under two minutes.

Across four concurrent ASAL county screenings or three SGR-corridor EIAs running simultaneously, that difference compounds. The bigger cost, though, is the rejection risk. A NEMA review officer who finds a species count in Annex C that differs from Chapter 4 by even a small margin has grounds to return the report, and the revision clock restarts. The canonical tibble approach makes that class of error structurally impossible.

The data model, IUCN lookup, richness calculation, and parameterised output described here are the specific pieces that other posts in this series do not cover. The GBIF Kenya data quality post handles the upstream data sourcing. The broader pipeline and audit-trail approach are covered in ESIA reproducibility. This piece fills the gap: the biodiversity data model itself, and the code that turns it into compliant NEMA annex tables.

If your consultancy produces more than two EIAs per year and still assembles biodiversity annexes by hand, what is the cost of the next rejection?

Kwiz Computing Technologies provides environmental data science services for EIA and ESIA projects across East Africa. Contact us to discuss reproducible biodiversity baseline workflows for your NEMA submissions.

Why Hello-World Plumber Tutorials Leave You Exposed

The standard Plumber quickstart looks like this:

library(plumber)

#* @get /predict
function(x) {
  list(result = as.numeric(x) * 2)
}

That is enough to demonstrate the concept. It is not enough for production. The endpoint accepts any request from anyone, has no error handling, logs nothing, and crashes if x is not numeric. On a shared server, one malformed request can take down every endpoint.

Production APIs need four things the tutorial skips: authentication, rate limiting, structured error handling, and a deployment target that stays running after you close your terminal.

Structuring a Plumber App for Production

Separate your concerns from the start. A flat api.R file gets unmanageable fast. Instead, use this layout:

api/
├── plumber.R        # Router definition and filter registration
├── auth.R           # Authentication helpers
├── rate_limit.R     # Rate limiting state and logic
├── endpoints/
│   ├── predict.R
│   └── data.R
└── run.R            # Entry point

Your run.R keeps the server start separate from the router logic:

library(plumber)
source("plumber.R")

pr() |>
  pr_run(host = "0.0.0.0", port = 8000)

Your plumber.R defines the router and registers filters before any endpoint:

library(plumber)

source("auth.R")
source("rate_limit.R")

#* @apiTitle Kwiz Analytics API
#* @apiVersion 1.0.0

# Filters run in registration order before every matching endpoint
#* @filter log_request
log_request <- function(req, res) {
  cat(format(Sys.time()), req$REQUEST_METHOD, req$PATH_INFO,
      req$HTTP_X_FORWARDED_FOR %||% req$REMOTE_ADDR, "\n")
  plumber::forward()
}

#* @filter authenticate
authenticate_request <- function(req, res) {
  authenticate(req, res)
  plumber::forward()
}

#* @filter rate_limit
rate_limit_request <- function(req, res) {
  check_rate_limit(req, res)
  plumber::forward()
}

# Include endpoint files
#* @plumber
function(pr) {
  pr |>
    pr_mount("/predict", plumb("endpoints/predict.R")) |>
    pr_mount("/data",    plumb("endpoints/data.R"))
}

The %||% operator is a simple null-coalescing helper. Add it to auth.R:

`%||%` <- function(a, b) if (!is.null(a) && nchar(a) > 0) a else b

API Key Authentication with Plumber Filters

Filters are the right place for authentication. They run before your endpoint function, so a rejected request never reaches your business logic.

A minimal API key system stores hashed keys in a flat file or database. This example uses a named list as an in-memory store. In a real deployment, read from a Postgres table or Redis on startup.

# auth.R
library(openssl)

# In production, load from environment or database at startup
VALID_KEYS <- list(
  "client_nairobi_erp"  = digest::digest("sk_live_abc123", algo = "sha256"),
  "client_mombasa_dash" = digest::digest("sk_live_xyz789", algo = "sha256")
)

authenticate <- function(req, res) {
  # Accept key from header (preferred) or query string (for testing only)
  api_key <- req$HTTP_X_API_KEY %||% req$args$api_key

  if (is.null(api_key) || api_key == "") {
    res$status <- 401
    stop(jsonlite::toJSON(list(error = "Missing API key"), auto_unbox = TRUE))
  }

  key_hash <- digest::digest(api_key, algo = "sha256")

  # Constant-time comparison to prevent timing attacks
  valid <- any(vapply(VALID_KEYS, function(h) identical(h, key_hash), logical(1)))

  if (!valid) {
    res$status <- 403
    stop(jsonlite::toJSON(list(error = "Invalid API key"), auto_unbox = TRUE))
  }

  # Attach client identity to request for downstream use
  req$client_id <- names(which(vapply(VALID_KEYS,
    function(h) identical(h, key_hash), logical(1))))[1]

  invisible(NULL)
}

The stop() pattern halts filter execution and returns the error body to the caller. Plumber catches the condition and sends the response.

JWT Authentication for User-Scoped Endpoints

API keys work well for service-to-service calls. For endpoints that serve individual users (common when a Shiny app is the frontend), JWTs let you encode identity and expiry without a database lookup on every request.

# jwt_auth.R
library(jose)

JWT_SECRET <- Sys.getenv("JWT_SECRET")  # Set in .Renviron or Docker env

issue_token <- function(user_id, role, expires_hours = 8) {
  payload <- list(
    sub  = user_id,
    role = role,
    iat  = as.integer(Sys.time()),
    exp  = as.integer(Sys.time()) + (expires_hours * 3600)
  )
  jwt_encode_hmac(payload, secret = JWT_SECRET)
}

verify_token <- function(req, res) {
  auth_header <- req$HTTP_AUTHORIZATION
  if (is.null(auth_header) || !startsWith(auth_header, "Bearer ")) {
    res$status <- 401
    stop(jsonlite::toJSON(list(error = "Missing bearer token"), auto_unbox = TRUE))
  }

  token <- sub("^Bearer ", "", auth_header)

  claims <- tryCatch(
    jwt_decode_hmac(token, secret = JWT_SECRET),
    error = function(e) NULL
  )

  if (is.null(claims)) {
    res$status <- 401
    stop(jsonlite::toJSON(list(error = "Invalid or expired token"), auto_unbox = TRUE))
  }

  if (as.integer(Sys.time()) > claims$exp) {
    res$status <- 401
    stop(jsonlite::toJSON(list(error = "Token expired"), auto_unbox = TRUE))
  }

  req$user_id <- claims$sub
  req$user_role <- claims$role
  invisible(NULL)
}

Your Shiny frontend calls /auth/login to get a token, then includes it in every subsequent API request as Authorization: Bearer <token>. This pairs naturally with the architecture described in the R Shiny hosting guide.

Rate Limiting with a Token Bucket

Rate limiting protects your API from both malicious abuse and accidental loops in client code. The token bucket algorithm is simple to implement in R: each client gets a bucket of N tokens that refills at a fixed rate. Each request consumes one token. When the bucket is empty, the request is rejected.

# rate_limit.R

# In-memory state: named list of lists(tokens, last_refill)
# For multi-process deployments, move this to Redis via the redux package
rate_limit_state <- new.env(hash = TRUE, parent = emptyenv())

BUCKET_CAPACITY  <- 60   # Max tokens per client
REFILL_RATE      <- 60   # Tokens added per minute
REFILL_INTERVAL  <- 60   # Seconds between refills

get_client_key <- function(req) {
  # Use API key identity if available, otherwise IP
  req$client_id %||% (req$HTTP_X_FORWARDED_FOR %||% req$REMOTE_ADDR)
}

check_rate_limit <- function(req, res) {
  client <- get_client_key(req)
  now    <- as.numeric(Sys.time())

  if (!exists(client, envir = rate_limit_state)) {
    assign(client,
           list(tokens = BUCKET_CAPACITY, last_refill = now),
           envir = rate_limit_state)
  }

  state <- get(client, envir = rate_limit_state)

  # Refill tokens based on elapsed time
  elapsed       <- now - state$last_refill
  refill_amount <- floor(elapsed / REFILL_INTERVAL) * REFILL_RATE
  new_tokens    <- min(BUCKET_CAPACITY, state$tokens + refill_amount)
  last_refill   <- if (refill_amount > 0) now else state$last_refill

  if (new_tokens < 1) {
    res$status <- 429
    res$setHeader("Retry-After", ceiling(REFILL_INTERVAL - (now - last_refill)))
    stop(jsonlite::toJSON(list(error = "Rate limit exceeded"), auto_unbox = TRUE))
  }

  # Consume one token
  assign(client,
         list(tokens = new_tokens - 1, last_refill = last_refill),
         envir = rate_limit_state)

  invisible(NULL)
}

This in-memory approach works for a single-process deployment. For multiple workers, replace rate_limit_state with Redis calls via the redux package: each check becomes HINCRBY and EXPIRE operations on a Redis hash keyed by client ID.

Packaging with Docker

Docker solves the “works on my machine” problem. It also makes deployment to any Linux VPS straightforward, including the affordable DigitalOcean droplets and Hetzner servers that many East African development teams use when AWS credit access is limited.

Create a Dockerfile at the project root:

FROM rocker/r-ver:4.4.0

# System dependencies
RUN apt-get update && apt-get install -y \
    libcurl4-openssl-dev \
    libssl-dev \
    libsodium-dev \
    && rm -rf /var/lib/apt/lists/*

# Install R packages
RUN Rscript -e "install.packages(c(
  'plumber', 'jsonlite', 'digest', 'jose', 'redux', 'logger'
), repos = 'https://cloud.r-project.org')"

WORKDIR /api

# Copy application code
COPY api/ .

EXPOSE 8000

CMD ["Rscript", "run.R"]

Build and run locally to verify:

docker build -t kwiz-api:latest .
docker run -p 8000:8000 \
  -e JWT_SECRET="your-secret-here" \
  kwiz-api:latest

Test authentication before shipping:

# Should return 401
curl http://localhost:8000/predict/score

# Should return data
curl -H "X-Api-Key: sk_live_abc123" http://localhost:8000/predict/score?x=42

Deploying to a VPS

A 2 GB RAM DigitalOcean droplet (about $12/month, payable in KES via M-Pesa through Safaricom or PayPal) handles moderate API traffic without the complexity of managed Kubernetes. The deployment process is the same on Hetzner, Vultr, or any other provider.

On the server, install Docker and docker-compose, then write a docker-compose.yml:

version: "3.8"
services:
  api:
    image: kwiz-api:latest
    restart: always
    ports:
      - "8000:8000"
    environment:
      - JWT_SECRET=${JWT_SECRET}
    volumes:
      - ./logs:/api/logs

  nginx:
    image: nginx:alpine
    restart: always
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf
      - /etc/letsencrypt:/etc/letsencrypt:ro

Your nginx.conf handles TLS termination and proxies requests to the Plumber container. Use certbot with Let’s Encrypt for free TLS certificates. This matches the Quarto cloud deployment pattern if you are hosting both your site and API on the same server.

Push your image to Docker Hub or GitHub Container Registry, then pull and start on the server:

docker-compose pull
docker-compose up -d

Set restart: always so the container comes back up after a server reboot or crash.

Connecting a Shiny Frontend

Once the API is running, your Shiny app calls it with httr2:

library(httr2)

get_prediction <- function(x, api_key) {
  request("https://api.yourdomain.com/predict/score") |>
    req_headers("X-Api-Key" = api_key) |>
    req_url_query(x = x) |>
    req_perform() |>
    resp_body_json()
}

This separation keeps your Shiny app stateless. The API handles computation and data access; Shiny handles the interface. Teams can update the model backend without redeploying the frontend, and multiple Shiny apps can share the same API. For teams already following this approach, see how it fits into a broader enterprise R architecture in our guide for business leaders on R.

Several enterprise clients we work with in Nairobi run this exact stack: a Plumber API on a VPS handling model inference, Shiny apps connecting to it from shinyapps.io, and API keys rotated quarterly. It keeps infrastructure costs low while maintaining clear security boundaries.

What to Build Next

The patterns here scale further. Add an /auth/token endpoint that issues short-lived JWTs in exchange for valid API keys. Wire the rate limiter to Redis so it works across multiple API containers behind a load balancer. Add a /health endpoint that checks database connectivity and returns a non-200 status if anything is broken, so your uptime monitor catches problems before users do.

If your team is exposing model predictions or data pipelines as HTTP endpoints and you want a review of the architecture or help with the deployment, Kwiz Computing works with data science teams across East Africa on exactly this kind of infrastructure.

What part of the Plumber-to-production gap is slowing your team down most? Authentication, deployment, or scaling?

What Kariba Taught the Market

The Kariba REDD+ project in Zimbabwe became the most discussed over-crediting case in voluntary carbon market history. Independent analysis published by Carbon Market Watch and others showed that the baseline deforestation rate used to calculate avoided emissions was set far above what satellite data and matching-region comparisons could justify, resulting in the issuance of millions of credits that did not represent real emission reductions.

Kariba directly affected Kenyan projects because scrutiny radiates. After the investigation, buyers began applying much tighter due diligence to all African REDD+ credits, including projects under the Northern Rangelands Trust (NRT), which operates across arid and semi-arid lands in Samburu, Isiolo, and Laikipia counties. The NRT credits are methodologically distinct from Kariba and generally regarded as higher-quality, but the market re-pricing that followed Kariba’s exposure affected the entire regional asset class.

The lesson for Kenyan developers is not just about methodology integrity. It is about pricing defensibility: can you show a buyer exactly where your credit sits in the distribution of comparable assets, with quantified uncertainty, before they ask?

What Institutional Buyers Now Require

The voluntary carbon market has moved from qualitative ratings to quantitative scoring. BeZero Carbon and Sylvera both publish probability-of-credit-performance ratings derived from satellite monitoring, additionality analysis, and permanence risk models. Buyers use these ratings as a direct input into pricing.

The Kenya Carbon Market Authority (CMA) Bill, currently advancing through Kenya’s legislative pipeline, will formalise domestic verification and registry requirements. Once enacted, it will require projects to demonstrate pricing based on validated methodologies, not informal benchmarks. Projects that cannot produce defensible price estimates with documented uncertainty ranges will face longer approval timelines and reduced buyer confidence.

The market has also fragmented by quality tier. A Verra-registered cookstoves credit with a BeZero A rating does not price the same as an unrated REDD+ credit from the same country. The spread between the top and bottom quality tiers in the voluntary carbon market widened to roughly USD 30 per tonne by 2024 and has not compressed. Models that ignore this spread undervalue the best projects and overprice the weakest.

The Quantitative Approach

Voluntary carbon credit prices are not random. They vary systematically with a small set of observable characteristics. The quantitative approach is a hedonic pricing model: regress observed transaction prices against project characteristics to estimate the contribution of each characteristic to price, then use those coefficients to price a new project.

The key co-variates are:

• Project type: REDD+ commands a discount versus improved cookstoves and blue carbon in most recent samples. Cookstoves projects under the Gold Standard have benefited from stronger co-benefit narratives (health, gender, clean air). Blue carbon is a premium niche with limited supply from East Africa.
• Registry: Verra (VCS) is the volume registry. Gold Standard carries a consistent premium, historically 20-40% above comparable VCS credits.
• Vintage year: Older vintages trade at a discount as buyers become more aware of permanence risks and baseline drift. Expect roughly USD 0.50-1.50 per tonne discount per year of vintage age in the current market.
• Rating: BeZero A-rated credits price significantly above unrated equivalents. Sylvera’s top tier shows similar effects. The rating premium is the strongest single predictor in recent transaction data.
• Country and region: African credits as a class traded at a discount relative to Latin American REDD+ during the 2023-2024 scrutiny period. That discount is narrowing for well-rated East African projects.

A Minimal R Implementation

The code below builds a linear pricing model from a representative sample of voluntary carbon market transactions and uses it to produce a prediction interval for a new Kenyan project. In practice, you would source transaction data from platforms like xpansiv/CBL, MSCI’s Carbon Markets data products, or aggregated registry issuance and cancellation records.

library(tidyverse)

# Simulated VCM transaction data with realistic structure
# In production: replace with CBL/xpansiv API data or
# manually cleaned registry transaction records
set.seed(42)
n <- 180

vcm_transactions <- tibble(
  price_usd_tco2e = NA_real_,
  project_type    = sample(
    c("REDD+", "cookstoves", "blue_carbon", "afforestation"),
    n, replace = TRUE, prob = c(0.45, 0.30, 0.10, 0.15)
  ),
  registry        = sample(
    c("Verra", "Gold_Standard"),
    n, replace = TRUE, prob = c(0.70, 0.30)
  ),
  vintage_year    = sample(2018:2023, n, replace = TRUE),
  bezero_rating   = sample(
    c("A", "BB", "B", "unrated"),
    n, replace = TRUE, prob = c(0.15, 0.25, 0.30, 0.30)
  ),
  african_project = sample(c(TRUE, FALSE), n, replace = TRUE, prob = c(0.40, 0.60))
)

# Simulate price as a function of known drivers
# Coefficients approximate published hedonic estimates (Ecosystem Marketplace 2024)
vcm_transactions <- vcm_transactions |>
  mutate(
    base_price = 8.0,
    type_adj   = case_when(
      project_type == "cookstoves"    ~  4.5,
      project_type == "blue_carbon"   ~  6.0,
      project_type == "afforestation" ~  1.5,
      project_type == "REDD+"         ~  0.0
    ),
    registry_adj  = if_else(registry == "Gold_Standard", 3.5, 0.0),
    vintage_adj   = (vintage_year - 2023) * -0.80,
    rating_adj    = case_when(
      bezero_rating == "A"       ~  5.0,
      bezero_rating == "BB"      ~  2.5,
      bezero_rating == "B"       ~  0.5,
      bezero_rating == "unrated" ~ -1.5
    ),
    africa_adj    = if_else(african_project, -1.2, 0.0),
    noise         = rnorm(n, 0, 2.5),
    price_usd_tco2e = pmax(2, base_price + type_adj + registry_adj +
                               vintage_adj + rating_adj + africa_adj + noise)
  ) |>
  select(-base_price, -type_adj, -registry_adj,
         -vintage_adj, -rating_adj, -africa_adj, -noise)

# Encode categorical predictors
vcm_model_data <- vcm_transactions |>
  mutate(
    across(c(project_type, registry, bezero_rating), as.factor),
    vintage_age = 2024 - vintage_year   # age in years relative to current
  )

# Fit hedonic pricing model
price_model <- lm(
  price_usd_tco2e ~ project_type + registry + vintage_age +
                    bezero_rating + african_project,
  data = vcm_model_data
)

summary(price_model)

The model summary shows coefficient estimates with standard errors. Each coefficient tells you the marginal price contribution of that characteristic, holding all others constant. A Gold Standard cookstoves credit from 2023 with a BeZero A rating is not just “a good credit”; it is a credit where you can quantify exactly how much each attribute contributes to its price.

# Predict price for a new Northern Rangelands Trust REDD+ project
# Assumptions: Verra registry, 2024 vintage, BeZero BB rating,
# African project (Kenya)
new_project <- tibble(
  project_type    = factor("REDD+",      levels = levels(vcm_model_data$project_type)),
  registry        = factor("Verra",      levels = levels(vcm_model_data$registry)),
  vintage_age     = 0,                   # 2024 vintage
  bezero_rating   = factor("BB",         levels = levels(vcm_model_data$bezero_rating)),
  african_project = TRUE
)

# Point estimate with 95% prediction interval
prediction <- predict(
  price_model,
  newdata   = new_project,
  interval  = "prediction",
  level     = 0.95
)

cat(sprintf(
  "Estimated price: USD %.2f/tCO2e\n95%% prediction interval: USD %.2f - USD %.2f\n",
  prediction[1, "fit"],
  prediction[1, "lwr"],
  prediction[1, "upr"]
))

The prediction interval is the output that institutional buyers and the CMA will want to see. A point estimate of USD 9.50 per tonne is a claim. A point estimate of USD 9.50 with a 95% interval of USD 5.20 to USD 13.80 is a transparent disclosure of uncertainty that buyers can incorporate into their own valuation models.

Practical Application for Kenyan Developers

The Northern Rangelands Trust operates grassland carbon projects across roughly 42,000 square kilometres of community conservancies in northern Kenya. NRT credits are REDD+ by project type (protecting grassland and rangeland carbon stocks from degradation), registered under Verra VCS, and increasingly rated by third-party raters. They sit at a methodologically stronger position than many African REDD+ projects because NRT’s monitoring framework integrates ground-level pastoral management data with satellite biomass estimates.

To apply this model to an NRT-equivalent project or to any new Kenyan carbon development, you need four data points:

1. Project type: REDD+, improved cookstoves, small-scale solar, blue carbon, or afforestation. This is determined by your methodology choice.
2. Registry: Verra VCS or Gold Standard are the two registries that attract institutional buyer interest. Other registries carry a significant liquidity discount.
3. Vintage year: The year credits are issued, which follows verification, which follows the monitoring period. Plan for a 12-18 month lag from project activity to issuance.
4. Third-party rating: BeZero and Sylvera both accept project submissions. The rating process takes 3-6 months and costs on the order of USD 20,000-50,000 for a first assessment. For a project expecting to issue 100,000 tonnes per year, the pricing uplift from a strong rating typically covers that cost within the first issuance cycle.

Running the model before you approach buyers tells you three things: where your credits sit relative to the market distribution, what the model-implied fair price range is, and which attribute changes (getting rated, switching registry, accelerating issuance to preserve vintage recency) would shift your price the most.

For a project issuing 500,000 tonnes over a 10-year crediting period, a 15% pricing improvement from a well-executed rating process represents USD 750,000 at USD 10 per tonne baseline. The analysis cost is a rounding error relative to that.

Defensible Pricing Is Not Optional Anymore

The voluntary carbon market in East Africa is entering a period where reputational and regulatory scrutiny will only increase. The Kenya CMA Bill, institutional buyer requirements for uncertainty quantification, and the fallout from high-profile over-crediting cases have together raised the bar for what a credible project pricing document looks like.

Systematic, data-driven pricing protects Kenyan developers on two fronts: it prevents underselling relative to project quality, and it provides documented methodology to show buyers, regulators, and the public when the inevitable questions arise.

The R approach shown here is a starting point. Production implementations benefit from richer transaction datasets, time-varying coefficients, and project-specific additionality risk priors. But even the minimal model outperforms a spreadsheet average in transparency, reproducibility, and defensibility.

For developers building this capability for the first time, our posts on carbon markets and quantitative methods and Kenya open data sources cover the data infrastructure you need. The reproducibility principles from EIA workflows also apply directly: version-controlled code, documented assumptions, and rendered outputs that show methodology and results together.

What does your current pricing process look like? If you are working from comparable-transaction averages without uncertainty ranges, the model above is a two-hour implementation that immediately changes your negotiating position.

Kwiz Computing Technologies provides quantitative environmental analytics services for Kenyan and East African carbon project developers, including hedonic pricing models, additionality analysis, and monitoring data workflows. Reach out if you want to build defensible pricing into your next project cycle.

What Kenya’s NDC Actually Commits To

Kenya’s updated 2030 NDC, submitted in 2020, uses a 2016 baseline of approximately 73 MtCO2e. The 32% conditional target implies keeping total emissions at or below roughly 50 MtCO2e by 2030. A 3% unconditional reduction is committed regardless of external financing.

The sectoral breakdown covers four main areas:

• Energy: efficiency improvements and renewable expansion, including geothermal and solar
• Transport: bus rapid transit, modal shift, and electric mobility targets in urban corridors
• Forestry and land use: increasing forest cover from roughly 7% to 10% of land area, protecting existing forests
• Agriculture: reduced emissions intensity from livestock, sustainable soil management

Each sector has quantitative sub-targets in the NDC text, but the sectoral monitoring frameworks are not yet consistently populated. The national reporting to the UNFCCC, through Biennial Transparency Reports and National Communications, lags reality by three to five years in most cases.

Why NDC Progress Tracking Stays Opaque

The data problem is structural. Kenya’s emissions data is scattered across at least four distinct systems that do not talk to each other.

NEMA’s national GHG inventory follows IPCC methodology but is updated infrequently, with the most recent National Communication covering data through 2015. The Kenya Climate Action Tracker (part of the global CAT project) provides independent estimates but relies on its own modelling assumptions. EDGAR (Emissions Database for Global Atmospheric Research, produced by the EU Joint Research Centre) publishes annual country-level estimates using a consistent global methodology. PRIMAP-hist, maintained by the Potsdam Institute for Climate Impact Research, provides a third independent time series back to 1750.

None of these is “the” authoritative source. NEMA’s inventory is most Kenya-specific but least current. EDGAR and PRIMAP-hist are current but use global proxy methods where country-specific data is sparse. The Kenya National Bureau of Statistics publishes activity data (energy consumption, livestock numbers, land cover change) that feeds into these models but is rarely read alongside them.

For a policy professional trying to answer “is Kenya on track?”, choosing which dataset to use is already a methodological decision that most NDC progress reports leave implicit.

Accessing EDGAR and PRIMAP-hist in R

Both EDGAR and PRIMAP-hist publish data as downloadable CSV files with stable URLs. Neither requires an API key for basic access.

library(tidyverse)

# EDGAR v8.0 total GHG (CO2, CH4, N2O, F-gases) by country
# Source: https://edgar.jrc.ec.europa.eu/dataset_ghg80
edgar_url <- paste0(
  "https://jeodpp.jrc.ec.europa.eu/ftp/jrc-opendata/EDGAR/datasets/",
  "v80_FT2022_GHG/IEA_EDGAR_CO2_1970_2022.zip"
)

# For a self-contained example, we work with the pre-downloaded CSV
# edgar_ghg <- read_csv("IEA_EDGAR_CO2_1970_2022.csv")

# The file has wide format with one column per year
# Pivot to long and filter to Kenya
kenya_edgar <- edgar_ghg |>
  filter(Country_code_A3 == "KEN") |>
  pivot_longer(
    cols      = matches("^Y_\\d{4}$"),
    names_to  = "year",
    values_to = "emissions_mt_co2e"
  ) |>
  mutate(
    year             = as.integer(str_remove(year, "^Y_")),
    emissions_mt_co2e = as.numeric(emissions_mt_co2e)
  ) |>
  filter(year >= 2000)

# PRIMAP-hist v2.5: country-level, all sectors, CO2e (AR4 GWPs)
# Source: https://zenodo.org/records/10705513
primap_url <- paste0(
  "https://zenodo.org/records/10705513/files/",
  "Guetschow-et-al-2024-PRIMAP-hist_v2.5.1_final_no_rounding.csv"
)

primap_raw <- read_csv(primap_url, show_col_types = FALSE)

kenya_primap <- primap_raw |>
  filter(
    country  == "KEN",
    category == "KYOTOGHG (AR4GWP100)",  # All Kyoto gases in CO2e
    scenario == "HISTCR"                 # Country-reported priority
  ) |>
  pivot_longer(
    cols      = matches("^\\d{4}$"),
    names_to  = "year",
    values_to = "emissions_mt_co2e"
  ) |>
  mutate(
    year             = as.integer(year),
    emissions_mt_co2e = emissions_mt_co2e / 1000  # Convert kt to Mt
  ) |>
  filter(year >= 2000)

Building the Progress Chart

With both datasets in hand, the core analytical question is: how does Kenya’s actual emissions trajectory compare to the path implied by the NDC target?

The NDC specifies a 32% reduction from a 2016 baseline. Using the PRIMAP-hist value for 2016 as the reference point, the target path is a straight line from the 2016 baseline to 68% of that value in 2030. This is a simplification: the NDC does not specify an annual trajectory, only a 2030 endpoint. But for visualisation purposes it is a reasonable linear interpolation.

library(ggplot2)

# Establish the 2016 baseline from PRIMAP-hist
baseline_2016 <- kenya_primap |>
  filter(year == 2016) |>
  pull(emissions_mt_co2e)

# NDC target: 32% below 2016 baseline by 2030
ndc_target_2030 <- baseline_2016 * (1 - 0.32)

# Build the linear target path (2016 to 2030)
target_path <- tibble(
  year             = c(2016, 2030),
  emissions_mt_co2e = c(baseline_2016, ndc_target_2030)
)

# Most recent data year in PRIMAP-hist
latest_year <- max(kenya_primap$year)

# Chart
ggplot() +
  # Historical PRIMAP-hist trajectory
  geom_line(
    data    = kenya_primap,
    mapping = aes(x = year, y = emissions_mt_co2e, colour = "Actual (PRIMAP-hist)"),
    linewidth = 1
  ) +
  # NDC target path
  geom_line(
    data     = target_path,
    mapping  = aes(x = year, y = emissions_mt_co2e, colour = "NDC target path"),
    linetype = "dashed",
    linewidth = 1
  ) +
  # Mark the NDC baseline year
  geom_vline(xintercept = 2016, colour = "grey60", linetype = "dotted") +
  # Mark the 2030 target endpoint
  geom_point(
    data    = target_path |> filter(year == 2030),
    mapping = aes(x = year, y = emissions_mt_co2e),
    colour  = "#e63946", size = 3
  ) +
  annotate(
    "text", x = 2030.3, y = ndc_target_2030,
    label = paste0(round(ndc_target_2030, 1), " MtCO2e\n(32% reduction target)"),
    hjust = 0, size = 3.2, colour = "#e63946"
  ) +
  scale_colour_manual(
    values = c("Actual (PRIMAP-hist)" = "#2d6a4f", "NDC target path" = "#e63946")
  ) +
  scale_x_continuous(breaks = seq(2000, 2030, by = 5)) +
  labs(
    title    = "Kenya GHG Emissions vs. 2030 NDC Target",
    subtitle = paste0(
      "Actual trajectory (PRIMAP-hist v2.5) vs. conditional NDC path\n",
      "Baseline: 2016 | Target: 32% reduction by 2030"
    ),
    x       = NULL,
    y       = "Total GHG emissions (MtCO2e, AR4)",
    colour  = NULL,
    caption = paste0(
      "Source: PRIMAP-hist v2.5 (Gütschow et al., 2024) | ",
      "NDC target: Kenya Updated NDC 2020"
    )
  ) +
  theme_minimal(base_size = 13) +
  theme(legend.position = "top")

Running this code with current PRIMAP-hist data shows Kenya’s emissions rising from around 60 MtCO2e in 2000 to the 2016 baseline, with upward pressure continuing through the early 2020s. The NDC target path runs sharply downward from 2016. The gap between those two lines is the policy challenge in visual form.

What the Trajectory Actually Shows

PRIMAP-hist data for Kenya through 2022 puts total GHG emissions at roughly 80-85 MtCO2e when land-use change is included. The 32% conditional target, measured against a 73 MtCO2e baseline, implies reaching approximately 50 MtCO2e by 2030.

That is a substantial reversal of a multi-decade upward trend. Kenya’s population grew from 30 million in 2000 to over 55 million by 2025. Agricultural emissions, driven largely by livestock (Kenya has one of Africa’s larger cattle populations), account for roughly 40% of total GHG output. Land-use change from deforestation and agricultural expansion has been a persistent emissions source, partially offset by reforestation efforts in recent years.

The energy sector, by contrast, shows a more favourable story. Kenya’s electricity grid runs on roughly 90% renewable generation, dominated by geothermal from the Olkaria complex. The expansion of solar and wind capacity in recent years has kept the power sector’s emissions growth modest relative to GDP growth. This is the structural advantage Kenya brings to its NDC: it does not need to decarbonise its power grid, which is already cleaner than most middle-income countries.

The harder sectors are transport and agriculture. Transport emissions are rising with vehicle imports and urban congestion. Agriculture, where methane from livestock dominates, is difficult to reduce without affecting food security and rural livelihoods that depend on the livestock economy.

The Conditionality Question in Practice

The 32% target is explicitly conditional on receiving “adequate, predictable, and sustainable means of implementation from the international community.” Kenya’s unconditional commitment is 3% below the baseline, which amounts to modest efficiency improvements on a business-as-usual path.

What does that conditionality mean in practice? Kenya’s NDC financing needs are estimated at roughly USD 62 billion over the 2020-2030 period for both mitigation and adaptation. That financing must come from a combination of grants, concessional loans, and private climate finance, primarily through mechanisms such as the Green Climate Fund, bilateral climate finance commitments, and voluntary carbon markets.

The tracking challenge is that no public dashboard currently links Kenya’s NDC financing received to emissions reductions achieved. Development finance institutions publish their climate commitments in aggregate. NEMA reports sectoral mitigation actions. But the implied question of the NDC framework, namely whether the international support conditionality is being met at a level that enables the 32% target, is not answered anywhere in a format that a policy analyst can use directly.

This is precisely where a reproducible R workflow adds value. A tracker that combines PRIMAP-hist emissions data, Kenya’s Biennial Transparency Reports, and GCF and bilateral disbursement data (available through the OECD DAC Creditor Reporting System) could produce an annual progress assessment. None of those datasets requires special access. All of them can be read into R and updated when new vintages are published.

Building a Repeatable Tracker

The workflow outlined above handles the emissions side. Adding the finance side requires one more data source: the OECD CRS database, which tracks climate-tagged development finance by recipient country.

# OECD Creditor Reporting System: climate-tagged flows to Kenya
# Available at: https://stats.oecd.org/DownloadFiles.aspx?DatasetCode=CRS1
# Filter: recipient = Kenya, purpose codes related to energy and environment

oecd_crs <- read_csv("CRS_2023_download.csv", show_col_types = FALSE) |>
  filter(
    RecipientName == "Kenya",
    str_detect(PurposeName, "Climate|Renewable|Forest|Environment")
  ) |>
  summarise(
    climate_finance_usd_m = sum(USD_Disbursement, na.rm = TRUE),
    .by = Year
  )

# Join with emissions trajectory for a combined tracker
ndc_tracker <- kenya_primap |>
  left_join(oecd_crs, by = c("year" = "Year")) |>
  mutate(
    target_path_mt = case_when(
      year <= 2016 ~ NA_real_,
      year >  2016 ~ baseline_2016 - (baseline_2016 - ndc_target_2030) *
                     ((year - 2016) / (2030 - 2016))
    ),
    gap_to_target = emissions_mt_co2e - target_path_mt
  )

This structure gives you a single data frame with actual emissions, the implied target path for each year, the gap between them, and the climate finance received. Rendered through a Quarto document, it becomes an annually updatable NDC progress report that can be shared with government counterparts, development partners, or parliamentary committees.

For organisations already using R for environmental assessments or Kenya open data work, extending this to NDC tracking requires no new infrastructure. The same reproducibility principles that apply to EIA reporting apply here: version-controlled code, documented data sources, transparent assumptions.

The Analysts Who Should Build This

Climate policy professionals in Kenya’s Ministry of Environment, NEMA, and the National Treasury work with NDC commitments regularly. Development finance analysts at the African Development Bank, KfW, and bilateral donors need progress data to justify continued climate finance. NGO researchers at organisations like the African Centre for Technology Studies produce independent assessments that would benefit from a common data infrastructure.

None of these groups currently has a shared, reproducible tracking framework. The UNFCCC’s own transparency portal provides raw data but no country-specific analysis. The Climate Action Tracker covers Kenya but updates infrequently and does not expose its underlying calculations.

The tools to build this exist today. The databases are public. The analytical methods are straightforward. What is missing is the institutional commitment to treat NDC tracking as a data engineering problem, not just a reporting obligation.

If your organisation monitors Kenya’s climate commitments and you are building something along these lines, what data source has been your biggest obstacle? The comments are open, and so is our contact page.

Kwiz Computing Technologies provides climate analytics services for development finance institutions, government agencies, and NGOs working on Kenya and East Africa climate policy. Our work on carbon markets and ESG analytics uses the same open data infrastructure described here.

Why Sizing Dominates Entry Signals

Consider a coin-flip strategy: 55% win rate, pays 1:1. Trade it at 50% of capital per flip and you will almost certainly go broke, because a short losing streak wipes you out before the edge compounds. Trade it at 1% and you survive but grow slowly. Trade it at the Kelly-optimal 10% and geometric growth is maximised.

Mathematically, the long-run compound growth rate of a strategy is:

where f is the fraction of capital risked, b is the win-to-loss ratio, and p is the win rate. This expression has a maximum at a specific f. Above that maximum, growth falls, and well above it, ruin becomes certain. That maximum is the Kelly fraction.

A systematic forex trader in Nairobi running a 52% win rate breakout strategy on EURUSD has an edge. Whether that edge translates into account growth depends almost entirely on how they size positions.

The Kelly Criterion: Formula and Derivation

John Kelly derived his formula in 1956 to solve optimal bet sizing for a gambler with a noisy signal. For a binary outcome game (win b units or lose 1 unit per bet), the Kelly fraction is:

where p is win probability and q = 1 - p. The formula tells you the fraction of current capital to risk on each trade. For a strategy with 55% wins and average payoff ratio 1.5:

Risk 25% of equity per trade. That is the full Kelly recommendation for those parameters, and it is almost certainly too aggressive for a live forex account. We will get to why shortly.

Estimating Parameters and Computing Kelly in R

Before sizing, you need reliable estimates of p and b from real trade data. The following R code reads an MT5-style trade log and computes both parameters.

library(dplyr)
library(readr)

# MT5 exports a semicolon-delimited file; adjust sep as needed
trades <- read_delim("mt5_history.csv", delim = ";", col_types = cols()) |>
  rename_with(tolower) |>
  filter(type %in% c("buy", "sell")) |>    # exclude deposits/withdrawals
  mutate(profit = as.numeric(profit))

# Separate wins from losses
wins  <- trades |> filter(profit > 0)
losses <- trades |> filter(profit < 0)

win_rate   <- nrow(wins) / nrow(trades)
avg_win    <- mean(wins$profit)
avg_loss   <- abs(mean(losses$profit))
payoff_ratio <- avg_win / avg_loss

cat(sprintf(
  "Trades: %d | Win rate: %.1f%% | Avg win: %.2f | Avg loss: %.2f | Payoff: %.2f\n",
  nrow(trades), win_rate * 100, avg_win, avg_loss, payoff_ratio
))

For real East African forex traders operating on ECN brokers through Nairobi-based prop desks, the average trade log contains 200 to 800 trades per year. That is enough data to estimate win rate with reasonable precision, but not enough to treat the estimate as exact. We return to this limitation in the next section.

kelly_fraction <- function(win_rate, payoff_ratio) {
  q <- 1 - win_rate
  (win_rate * payoff_ratio - q) / payoff_ratio
}

f_star <- kelly_fraction(win_rate, payoff_ratio)
cat(sprintf("Full Kelly fraction: %.4f (%.1f%% of equity per trade)\n",
            f_star, f_star * 100))

lot_size_from_kelly <- function(balance_usd, kelly_f, pip_value, stop_loss_pips) {
  # kelly_f is fraction of equity to risk
  # pip_value in USD per standard lot
  risk_usd  <- balance_usd * kelly_f
  lots      <- risk_usd / (stop_loss_pips * pip_value)
  round(lots, 2)
}

# Example: $10,000 account, EURUSD, 10 pip SL, pip value = $10/lot
lot_size_from_kelly(
  balance_usd    = 10000,
  kelly_f        = f_star,
  pip_value      = 10,
  stop_loss_pips = 10
)

Why Full Kelly Is Almost Always Too Aggressive

The Kelly fraction is extremely sensitive to the input estimates. A win rate of 55% yields a Kelly fraction well above zero. A win rate of 49%, estimated from a different 300-trade sample of the same strategy, produces a negative Kelly fraction: do not trade. That gap between estimates is entirely plausible due to sampling noise.

This is the core problem. Full Kelly sized to your point estimate of p and b is almost always too aggressive, because your estimates contain error. The resulting over-sizing produces severe drawdowns that compound faster than your edge can recover them.

Bootstrap confidence intervals make this concrete. You can resample your trade history to see how much the Kelly fraction bounces around:

library(rsample)
library(purrr)

bootstrap_kelly <- function(trades, n_boot = 2000) {
  boot_samples <- bootstraps(trades, times = n_boot)

  map_dbl(boot_samples$splits, function(split) {
    d      <- analysis(split)
    wins   <- d |> filter(profit > 0)
    losses <- d |> filter(profit < 0)

    if (nrow(wins) == 0 || nrow(losses) == 0) return(NA_real_)

    p_b <- nrow(wins) / nrow(d)
    b_b <- mean(wins$profit) / abs(mean(losses$profit))
    kelly_fraction(p_b, b_b)
  }) |>
    na.omit()
}

boot_kelly <- bootstrap_kelly(trades)

cat(sprintf(
  "Kelly fraction: point est = %.3f | 5th pct = %.3f | 95th pct = %.3f\n",
  f_star,
  quantile(boot_kelly, 0.05),
  quantile(boot_kelly, 0.95)
))

# Plot the bootstrap distribution
hist(boot_kelly,
     breaks = 50,
     main   = "Bootstrap Distribution of Kelly Fraction",
     xlab   = "Kelly f*",
     col    = "#4E79A7",
     border = "white")
abline(v = f_star, col = "red", lwd = 2, lty = 2)
abline(v = quantile(boot_kelly, c(0.05, 0.95)), col = "orange", lwd = 1.5, lty = 3)

When a strategy has 300 trades, the 90% bootstrap interval for the Kelly fraction typically spans 15 percentage points or more. Sizing to the upper end of that range is ruin territory. This is why practitioners universally apply a fractional Kelly.

See the related discussion on overfitting and estimation bias in our post on combinatorial purged cross-validation, which applies the same resampling logic to strategy selection.

Half-Kelly and Fractional Kelly in Practice

The solution is to trade a fixed fraction of the Kelly recommendation. Half-Kelly (f = 0.5 * f*) is the most common choice, and it has attractive theoretical properties: it retains roughly 75% of the full Kelly growth rate while halving the variance of outcomes and reducing the severity of drawdowns substantially.

compare_sizing_methods <- function(trades, account_size = 10000,
                                   pip_value = 10, stop_loss_pips = 10) {
  wins   <- trades |> filter(profit > 0)
  losses <- trades |> filter(profit < 0)

  p_est <- nrow(wins) / nrow(trades)
  b_est <- mean(wins$profit) / abs(mean(losses$profit))
  f_k   <- kelly_fraction(p_est, b_est)

  methods <- tibble(
    method       = c("Full Kelly", "Half Kelly", "Fixed 2%", "Fixed 1%"),
    fraction     = c(f_k, f_k / 2, 0.02, 0.01),
    lots = map_dbl(fraction, \(f)
      lot_size_from_kelly(account_size, f, pip_value, stop_loss_pips))
  )

  methods
}

sizing_table <- compare_sizing_methods(trades)
print(sizing_table)

The fixed 1% and 2% rules are simple and widely used, including by many prop firms and retail brokers operating in East Africa. They work, but they are arbitrary. If your strategy has a Kelly fraction of 4%, the 1% rule is overly conservative and leaves growth on the table. If your Kelly fraction is 1%, the 2% rule is over-leveraged.

Fractional Kelly anchors your sizing to your actual edge rather than an arbitrary number.

simulate_equity <- function(trades, fraction, n_trades = 500,
                            n_sims = 200, start_equity = 10000) {
  # Normalise profits to fraction-of-equity units
  wins_pct   <- trades |> filter(profit > 0) |> pull(profit) / start_equity
  losses_pct <- trades |> filter(profit < 0) |> pull(profit) / start_equity

  replicate(n_sims, {
    equity <- start_equity
    for (i in seq_len(n_trades)) {
      if (runif(1) < win_rate) {
        r <- sample(wins_pct, 1)
      } else {
        r <- sample(losses_pct, 1)
      }
      equity <- equity * (1 + fraction * sign(r) * abs(r) /
                            (abs(trades$profit |> mean())))
      if (equity < 0) { equity <- 0; break }
    }
    equity
  })
}

set.seed(42)
results <- list(
  full_kelly  = simulate_equity(trades, f_star),
  half_kelly  = simulate_equity(trades, f_star / 2),
  fixed_2pct  = simulate_equity(trades, 0.02),
  fixed_1pct  = simulate_equity(trades, 0.01)
)

# Median terminal equity per method
sapply(results, median)

# Run this from a Plumber API endpoint called by the EA before order submission
# See our MT5-R bridge architecture in the systematic trading post

current_equity <- 12500  # fetched from MT5 account info
kelly_lots <- lot_size_from_kelly(
  balance_usd    = current_equity,
  kelly_f        = f_star / 2,    # half-Kelly
  pip_value      = 10,
  stop_loss_pips = 15             # from strategy signal
)

# Return to EA
list(recommended_lots = kelly_lots, method = "half-kelly", fraction = f_star / 2)

The Bottom Line

Kelly sizing is not a silver bullet. It requires honest estimates of your edge, bootstrap intervals to understand estimation uncertainty, and the discipline to apply fractional Kelly rather than the full formula. Applied properly, it gives you a principled answer to the question that matters most in long-run trading: not which direction to trade, but how much.

The traders on Nairobi’s retail forex desks who run consistent edge lose that edge to poor sizing more often than to poor signals. If you have a backtested strategy with documented win rate and payoff data, run the numbers. A 15-minute R script will tell you whether your current sizing is leaving growth on the table or pushing you toward ruin.

What does your bootstrap Kelly interval look like? If you share your trade log, the Kwiz Quants team can run a full sizing analysis as part of our strategy evaluation service.

What Rhino Adds to a Production Shiny App

Rhino is an application framework developed by Appsilon for building Shiny apps with engineering-grade structure. Without it, Shiny projects tend to accumulate logic in server.R until the file becomes impossible to test or maintain. Rhino enforces a module system, separates UI from logic, and integrates testthat from the start.

A Rhino project for a trading dashboard has this directory layout:

trading-dashboard/
├── app/
│   ├── main.R               # Entry point
│   ├── logic/
│   │   ├── trade_log.R      # Data ingestion and cleaning
│   │   ├── drawdown.R       # Drawdown computation
│   │   └── regime.R         # Regime detection logic
│   └── view/
│       ├── overview.R       # Overview tab UI + server
│       ├── drawdown.R       # Drawdown tab UI + server
│       └── regime.R         # Regime tab UI + server
├── tests/
│   └── testthat/
│       └── test-drawdown.R  # Unit tests for risk metrics
├── renv.lock
└── rhino.yml

The logic/ layer is pure R: no Shiny dependencies, fully testable. The view/ layer contains Shiny modules that consume the logic layer’s output. This separation is what makes the dashboard maintainable once it reaches production.

Ingesting MT5 Trade Logs

MT5 exports a structured HTML or CSV report from the terminal’s “Account History” section. The CSV variant is easier to parse programmatically. A typical MT5 export has columns for ticket number, open time, close time, symbol, type, lots, open price, close price, and profit.

The ingestion module lives in app/logic/trade_log.R:

box::use(
  dplyr[...],
  readr[read_csv, cols, col_character, col_double, col_datetime],
  lubridate[ymd_hms, with_tz]
)

#' Load and clean an MT5 trade history CSV
#'
#' @param path Path to the exported CSV file
#' @param tz   Timezone of the MT5 server (e.g. "Africa/Nairobi")
#' @return A tibble with one row per closed trade
load_mt5_trades <- function(path, tz = "Africa/Nairobi") {
  raw <- read_csv(path, col_types = cols(
    Ticket     = col_double(),
    OpenTime   = col_character(),
    CloseTime  = col_character(),
    Symbol     = col_character(),
    Type       = col_character(),
    Lots       = col_double(),
    OpenPrice  = col_double(),
    ClosePrice = col_double(),
    Profit     = col_double()
  ))

  raw |>
    filter(Type %in% c("buy", "sell")) |>
    mutate(
      open_time  = ymd_hms(OpenTime)  |> with_tz(tz),
      close_time = ymd_hms(CloseTime) |> with_tz(tz),
      duration_hrs = as.numeric(close_time - open_time, units = "hours")
    ) |>
    select(ticket = Ticket, symbol = Symbol, type = Type, lots = Lots,
           open_price = OpenPrice, close_price = ClosePrice,
           profit = Profit, open_time, close_time, duration_hrs) |>
    arrange(close_time)
}

The box::use() call at the top is Rhino’s preferred import style: explicit, testable, and collision-free. Setting the timezone to "Africa/Nairobi" (EAT, UTC+3) matters for any analysis involving trading sessions, because session-based performance metrics behave differently when timestamps are in the broker’s server time versus your local time.

The Drawdown Module

Drawdown is where most retail monitoring tools fall short. A broker dashboard shows open equity, but it does not show you the maximum drawdown from peak over your last 200 trades, the time spent in drawdown, or whether the current drawdown is within historical norms for your system.

The computation lives in app/logic/drawdown.R:

box::use(dplyr[...], tibble[tibble])

#' Compute running drawdown metrics from a trade sequence
#'
#' @param trades A tibble from load_mt5_trades()
#' @param initial_balance Starting account balance in USD
#' @return A tibble with equity curve and drawdown columns
compute_drawdown <- function(trades, initial_balance = 10000) {
  trades |>
    arrange(close_time) |>
    mutate(
      cumulative_pnl = cumsum(profit),
      equity         = initial_balance + cumulative_pnl,
      running_peak   = cummax(equity),
      drawdown_abs   = running_peak - equity,
      drawdown_pct   = drawdown_abs / running_peak
    )
}

#' Summarise key drawdown statistics
#'
#' @param dd_tbl Output from compute_drawdown()
#' @return A named list of summary statistics
drawdown_summary <- function(dd_tbl) {
  list(
    max_drawdown_pct  = max(dd_tbl$drawdown_pct),
    max_drawdown_abs  = max(dd_tbl$drawdown_abs),
    current_dd_pct    = tail(dd_tbl$drawdown_pct, 1),
    trades_in_dd      = sum(dd_tbl$drawdown_pct > 0),
    recovery_factor   = tail(dd_tbl$cumulative_pnl, 1) / max(dd_tbl$drawdown_abs)
  )
}

The recovery factor, total net profit divided by maximum drawdown, gives a single number that captures whether the system earns enough to justify the pain of its worst losing streak. A recovery factor below 1 means the system has not yet earned back its worst drawdown in total profits. Most retail traders do not track this number at all.

The Shiny module that renders this in the dashboard (app/view/drawdown.R) uses echarts4r for the equity curve chart, which renders cleanly on mobile browsers, a practical requirement for traders monitoring positions from a phone:

box::use(shiny[...], echarts4r[...])
box::use(app/logic/drawdown[compute_drawdown, drawdown_summary])

drawdown_ui <- function(id) {
  ns <- NS(id)
  tagList(
    echarts4rOutput(ns("equity_curve")),
    verbatimTextOutput(ns("dd_stats"))
  )
}

drawdown_server <- function(id, trades, initial_balance) {
  moduleServer(id, function(input, output, session) {
    dd_data <- reactive({
      compute_drawdown(trades(), initial_balance())
    })

    output$equity_curve <- renderEcharts4r({
      dd_data() |>
        e_charts(close_time) |>
        e_line(equity, name = "Equity") |>
        e_line(running_peak, name = "Peak", lineStyle = list(type = "dashed")) |>
        e_area(drawdown_abs, name = "Drawdown") |>
        e_tooltip(trigger = "axis") |>
        e_theme("walden")
    })

    output$dd_stats <- renderPrint({
      drawdown_summary(dd_data())
    })
  })
}

Detecting Regime Shifts

A strategy optimised on 2022-2023 EURUSD data may stop working when the Fed’s rate cycle shifts. Monitoring for regime change is the difference between a system that adapts and one that silently bleeds an account. A simple but effective detector uses a rolling Sharpe Ratio with a rolling window and flags when it crosses a threshold.

The regime logic in app/logic/regime.R:

box::use(dplyr[...], slider[slide_dbl], zoo[rollmean])

#' Compute rolling Sharpe Ratio and flag regime shifts
#'
#' @param trades  A tibble from load_mt5_trades()
#' @param window  Rolling window in trades (default 50)
#' @param sr_warn Sharpe threshold below which a warning is flagged
#' @return A tibble with rolling Sharpe and a regime flag column
detect_regime <- function(trades, window = 50, sr_warn = 0.5) {
  annualisation <- sqrt(252)   # Assumes roughly one trade per day on average

  trades |>
    arrange(close_time) |>
    mutate(
      rolling_mean_pnl = slide_dbl(profit, mean, .before = window - 1,
                                   .complete = TRUE),
      rolling_sd_pnl   = slide_dbl(profit, sd,   .before = window - 1,
                                   .complete = TRUE),
      rolling_sr       = (rolling_mean_pnl / rolling_sd_pnl) * annualisation,
      regime_warning   = !is.na(rolling_sr) & rolling_sr < sr_warn
    )
}

The slider package is well-suited here because it handles partial windows gracefully and integrates with the tidyverse pipe. When regime_warning flips to TRUE, the dashboard surfaces a red indicator in the overview tab. The threshold of 0.5 is conservative, consistent with the Deflated Sharpe Ratio reasoning that a Sharpe below a certain adjusted threshold signals the edge has degraded.

Deploying Without an Institutional Budget

The full Rhino app runs as a Docker container. A minimal Dockerfile for this dashboard:

FROM rocker/shiny-verse:4.4.0

RUN apt-get update && apt-get install -y libssl-dev libcurl4-openssl-dev

WORKDIR /app
COPY renv.lock renv.lock
RUN R -e "renv::restore(lockfile = 'renv.lock', prompt = FALSE)"

COPY . .

EXPOSE 3838
CMD ["R", "-e", "rhino::app() |> shiny::runApp(port = 3838, host = '0.0.0.0')"]

A DigitalOcean Droplet at $12/month (2 vCPU, 2 GB RAM) handles this comfortably for a single user or a small team monitoring shared strategies. Add Nginx in front for SSL termination and the total infrastructure cost stays well under $20/month, comparable to a single Bloomberg terminal keyboard and far below the cost of a missed drawdown.

For teams already running MT5 on a VPS, co-locating the dashboard on the same machine eliminates latency in trade log access. The load_mt5_trades() function accepts any file path, so it reads directly from a shared network folder or a scheduled rsync from the MT5 server. For a deeper look at hosting options for Shiny applications, see the R Shiny hosting guide.

Where the Real Edge Goes

The traders who get consistent results from systematic strategies are not the ones with the best entry signals. They are the ones who know, in real time, whether their system is behaving within historical norms or has entered a new regime that their backtest never saw.

A Rhino-structured Shiny dashboard built the way described here gives a Kenyan quant trader the same observability infrastructure that quantitative hedge funds maintain at institutional scale: drawdown tracking, regime monitoring, and historical context, for the cost of a weekend’s work and a $12 VPS. The technology gap between a retail trader in Westlands and a prop desk in Sandton is far smaller than the monitoring gap.

The question worth sitting with: if your live performance diverged from your backtest six weeks ago, would your current tools tell you?

Building systematic forex monitoring infrastructure? Kwiz Computing Technologies builds production R/Shiny applications for trading teams across East Africa. See how we structure systematic trading in R and how the deflated Sharpe ratio can sharpen your strategy validation before you touch live capital.

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.

What Happened to Kenya’s Forex Market After 2023

Kenya’s Central Bank tightened its forex dealer licensing framework in 2023, raising capital requirements and compliance obligations that pushed several local brokers out of the market. The direct effect was predictable: retail traders migrated toward regulated offshore brokers, particularly those regulated by the FCA, FSCA, and CySEC. Platforms like Exness, Pepperstone, and IC Markets saw significant uptake across East Africa.

What did not migrate with those traders was any improvement in method. According to industry data from broker disclosure reports, roughly 70-80% of retail forex accounts lose money in any given quarter. That number holds across regions and has held for years. The offshore move changed the regulatory wrapper but not the underlying problem.

The problem is structure. Institutional desks trade with rules. Most retail traders in Kenya trade with feelings dressed up as rules.

The Institutional Edge Is Not What You Think

People assume the institutional edge comes from proprietary data or faster execution. Both matter, but neither is the primary driver of systematic profitability. The real edge is the discipline to test hypotheses rigorously before risking capital on them, then execute without emotional override.

A systematic strategy answers three questions before it goes live. First: does the signal actually exist in historical data, or did I find it by testing enough variations that something was bound to look good? Second: does the strategy work on data it was never trained on? Third: what is the realistic worst-case drawdown, and can I stay solvent through it?

Retail traders skip all three questions. They see a strategy work on a demo account for three weeks and call it validated. A demo account run over three weeks is not evidence of anything. It is a coin flip that landed in your favor.

The Tooling That Closes the Gap

Here is the specific stack that makes systematic trading possible without an institutional budget.

Backtesting and signal validation. The quantstrat package in R provides a full backtesting framework. More importantly, R’s statistical ecosystem allows you to apply proper validation methods. At Kwiz Computing, we build every strategy against the Deflated Sharpe Ratio framework before any live testing begins. The DSR adjusts your observed Sharpe Ratio for the number of strategies you tested to find it. If you tested 200 variations of a moving average crossover and picked the best one, your backtest result is almost certainly a false discovery. The DSR tells you whether it is.

Walk-forward validation. A single in-sample/out-of-sample split is not enough for currency strategies, because forex regimes shift. We use combinatorial purged cross-validation, a technique from Marcos Lopez de Prado’s work, to test strategies across many non-overlapping time windows without introducing lookahead bias. This is the difference between a strategy that looks good on paper and one that has actually been stress-tested.

Automated execution. MetaTrader 5 supports algorithmic execution through Expert Advisors (EAs). You can connect R strategy logic to MT5 execution via MetaSocket, which is exactly what the Kwiz Quants infrastructure uses. The R side handles signal generation and risk sizing; MT5 handles order routing. This removes the moment-to-moment discretion that kills most retail accounts.

Risk management as code. Position sizing based on Kelly fractions or fixed-fractional rules, automatic stop placement, and daily drawdown limits can all be implemented as functions that run before any order is submitted. When risk management is code, it does not flinch. It does not convince itself that “this trade is different.”

Why This Matters Specifically for African Practitioners

The argument sometimes made is that systematic trading is irrelevant to African markets because our capital bases are smaller and our access to institutional data is limited. This argument is wrong on both counts.

Systematic trading helps small accounts more than large ones, not less. A discretionary trader with a $500 account who blows up on three bad weeks of impulsive trading loses everything. A systematic trader with the same account running a strategy with defined stops and position sizing loses a controlled amount, learns something specific from the drawdown, and adjusts. The discipline compounds.

On data access: forex data is among the most democratised financial data in the world. Tick data for major and minor pairs going back ten or more years is available from brokers, from Dukascopy, and from aggregators. A Nairobi-based quant analyst with an internet connection has access to essentially the same raw price data as a desk in Zurich.

The gap is not access. It is the knowledge that proper validation exists, and the willingness to apply it before going live.

Where Most People Get Stuck (and What to Do)

The typical journey for a data-literate practitioner who wants to build systematic trading infrastructure goes like this. They read about backtesting, implement something in Python or R, see impressive backtest results, and try it live. It fails. They conclude that systematic trading does not work.

The conclusion is wrong. The workflow was wrong. Specifically, the backtest had one or more of the following problems: it was fit on the same data used to evaluate it, it did not account for transaction costs and slippage, or it was selected from many strategies tested on the same dataset, making the result a statistical artifact rather than a real signal.

Fixing these problems is not complicated. It requires applying the right statistical framework in the right order. Validate the signal with DSR before selection. Use purged cross-validation to test generalization. Paper-trade with realistic costs before going live. The framework is documented, the tools are in R and Python, and the process is repeatable.

The practical starting point is simpler than most people expect. Pick one currency pair you trade. Define one rule-based entry signal. Define exact exit rules. Backtest it on five years of hourly data. Apply the DSR. If it passes, validate with walk-forward testing. If it still passes, size it conservatively and run it on demo for sixty days with automated execution. That process is within reach for anyone with working knowledge of R or Python.

The Structural Opportunity

Retail forex trading in Kenya and across East Africa is growing. The post-2023 shift toward offshore regulated brokers has, if anything, accelerated participation, because traders now have access to tighter spreads, more instruments, and better execution than was possible through local dealers.

Almost none of that participation is systematic. That is not a permanent condition. It is a skills gap, and skills gaps close.

The practitioners who close this gap first will have a durable edge, not because systematic trading is guaranteed to win, but because trading without a tested, rule-based framework is almost guaranteed to lose over any meaningful time horizon. The statistics on retail trading outcomes are not ambiguous. They have been consistent for decades across every market that has disclosed them.

The question is not whether data science applies to African retail forex. It clearly does. The question is whether you will be among the practitioners who apply it, or among the ones who continue to hand their capital to the algorithms on the other side of the order book.

If you want to build systematic trading infrastructure on a realistic budget, we write about the specific tools and methods at Kwiz Quants. The framework is not theoretical. We use it ourselves.

Why NEMA’s 2024 Amendment Changes the Rules

Before the amendment, most NEMA review queries were handled informally between a firm and the review officer. The 2024 Environmental Management and Co-ordination Act amendment introduced a structured peer-review stage that puts a second qualified expert in the room, one with the authority to raise formal objections that delay approval.

The practical consequence is that any table, figure, or statistic in your report needs a clear chain of custody from raw data to final output. If your baseline water quality data lives in one Excel file, your calculations live in another, and your report was written by copying numbers into Word, you have no chain of custody. You have a liability.

Structured as a version-controlled R project with a {targets} pipeline and parameterised Quarto output, the same report becomes self-auditing: every number traces back to a function, every function traces back to a data file, and every data file carries a hash that confirms it has not been altered since the analysis ran.

The {targets} Package: What It Does for EIA Work

The {targets} package by Will Landau implements pipeline-based computation for R. Instead of running scripts sequentially, you declare a set of targets, each one a named object that depends on other targets or on raw inputs. {targets} builds only what has changed since the last run. It records the state of every intermediate object. It skips targets that are already up to date.

For an EIA project, this maps directly to the structure of the work: baseline data collection feeds into data cleaning, which feeds into statistical analysis, which feeds into the tables and figures that populate the report.

A minimal _targets.R file for a Category B EIA looks like this:

library(targets)
library(tarchetypes)

tar_option_set(
  packages = c("dplyr", "readxl", "sf", "ggplot2", "quarto")
)

list(
  # 1. Raw data ingestion
  tar_target(
    raw_air_quality,
    read_excel("data/raw/baseline_air_quality.xlsx"),
    format = "rds"
  ),
  tar_target(
    raw_water_quality,
    read_excel("data/raw/baseline_water_quality.xlsx"),
    format = "rds"
  ),

  # 2. Cleaning and validation
  tar_target(
    air_quality_clean,
    clean_air_quality(raw_air_quality),
    format = "rds"
  ),
  tar_target(
    water_quality_clean,
    clean_water_quality(raw_water_quality),
    format = "rds"
  ),

  # 3. Statistical summaries
  tar_target(
    air_summary_table,
    summarise_air_baseline(air_quality_clean),
    format = "rds"
  ),
  tar_target(
    water_summary_table,
    summarise_water_baseline(water_quality_clean),
    format = "rds"
  ),

  # 4. Parameterised report
  tar_quarto(
    eia_report,
    path = "report/eia_report.qmd",
    execute_params = list(
      project_name = "Nairobi Southern Bypass Phase 2",
      nema_ref = "NEMA/EIA/5/2/2026/001",
      reporting_period = "Q4 2025"
    )
  )
)

Running tar_make() in the project root builds the entire pipeline. Running it again after changing a single data file rebuilds only the targets that depend on that file, and nothing else. Every intermediate result is stored with a content hash. If someone changes baseline_air_quality.xlsx and does not tell you, the next tar_make() will detect the change and recompute downstream targets automatically.

Parameterised Quarto Reports

The report itself is a Quarto document with a params block in its YAML header. Parameters are injected at render time by {targets}, so the same .qmd template can produce outputs for different project phases, project areas, or reporting periods without any manual editing.

A simplified eia_report.qmd header:

---
title: "Environmental Impact Assessment: `r params$project_name`"
subtitle: "NEMA Reference: `r params$nema_ref`"
author: "Kwiz Computing Technologies"
date: "`r Sys.Date()`"
format:
  pdf:
    toc: true
    number-sections: true
    keep-tex: false
params:
  project_name: "Default Project"
  nema_ref: "NEMA/EIA/5/2/XXXX/XXX"
  reporting_period: "Q1 2026"
---

Inside the document, every table and figure calls a target object directly:

# In a code chunk: pull the pre-computed summary table
tar_read(air_summary_table) |>
  knitr::kable(
    caption = paste0(
      "Table 4.1: Baseline Air Quality Summary, ",
      params$reporting_period
    ),
    digits = 2
  )

Because tar_read() retrieves the stored target object rather than recomputing it, every figure and table in the rendered PDF is guaranteed to match the pipeline output exactly. The discrepancy that triggers NEMA queries, a number in the executive summary that differs from the technical appendix, cannot occur when both sections pull from the same target.

project-nema-eia-001/
├── _targets.R              # Pipeline definition
├── _targets/               # Cached pipeline state (git-ignored)
├── R/
│   ├── clean_air_quality.R
│   ├── clean_water_quality.R
│   ├── summarise_air_baseline.R
│   └── summarise_water_baseline.R
├── data/
│   ├── raw/                # Original field data (never modified)
│   └── processed/          # Outputs written by the pipeline
├── report/
│   ├── eia_report.qmd      # Main report template
│   └── sections/           # Child documents for each chapter
├── output/                 # Rendered PDF reports
├── renv.lock               # Exact package versions (reproducible environment)
└── README.md               # Instructions to reproduce the analysis

Migrating from Excel-Based Workflows

Most Kenyan EIA consultancies do not start with a clean slate. They have existing Excel-based workflows, established templates, and staff who are not R users. The migration does not have to be immediate or total.

A practical three-phase approach:

Phase 1: Read, do not replace. Keep your Excel files as the primary data store. Write R functions that read from them using readxl or openxlsx. Run those functions through a {targets} pipeline. The team keeps working in Excel; R becomes the computation layer downstream of it.

Phase 2: Parameterise the report. Move one chapter of your standard NEMA report template into a Quarto document. Have it read from the {targets} pipeline. Render it alongside the Word document initially. Once the team trusts the output, the Quarto version becomes the primary.

Phase 3: Bring data entry into R. Once the pipeline is established, replace manual Excel data entry with validated R data entry forms or structured CSV templates. At this stage the full pipeline is reproducible from raw inputs.

The two packages that smooth this transition most are readxl for reading Excel files without converting them, and writexl for producing Excel outputs if a client or regulator specifically requires them. Neither requires Excel to be installed.

For biodiversity baseline data, our earlier post on GBIF Kenya data quality covers the specific quality checks that belong in the cleaning stage of your pipeline.

What NEMA Peer Reviewers Actually Look For

Conversations with practitioners who have been through the 2024 peer-review process point to three recurring flashpoints.

First, inconsistent summary statistics: a mean value reported differently in the executive summary, the baseline chapter, and the annexes. This is a copy-paste artefact that a {targets} pipeline eliminates entirely because every section pulls from the same computed object.

Second, undocumented data transformations: a baseline dataset that has been filtered or corrected without any record of the decision. The R/ functions in your project document every transformation in code, and Git records when and why the code changed.

Third, outdated figures: a map or chart that reflects an earlier version of the data because the analyst forgot to regenerate it after a late field correction. {targets} makes stale outputs structurally impossible: if the data changes, the pipeline marks downstream targets as outdated and rebuilds them on the next tar_make() call.

The Kenya open data portal and the previous post on ESIA reproducibility provide additional context on the data sources and principles that underpin this kind of workflow.

Why This Matters in Kenya Right Now

The Nairobi Securities Exchange retail participation rate has grown, but the tools available to individual traders have not kept pace with the sophistication of those traders. Kenya’s forex community is one of the most active in Sub-Saharan Africa, with thousands of retail participants running algorithmic strategies on MT5. Many have genuine quantitative skills: statistics degrees, actuarial backgrounds, engineering training.

The gap is not talent. The gap is infrastructure. A quant at a Nairobi prop desk has a Bloomberg terminal, a risk system, and a data warehouse. An equally skilled independent quant in Westlands has a laptop and a spreadsheet.

R closes that gap faster than any other tool stack. The packages exist, the deployment patterns are proven, and the R/Shiny skill set that Nairobi’s data consultancy community already uses for enterprise dashboards translates directly to trading infrastructure. The same Rhino-structured Shiny application that powers a client-facing business intelligence dashboard can, with different modules, run a live signal monitor for a systematic forex strategy.

The Four Components of a Complete Trading System

Institutional trading infrastructure, stripped to its functional core, has four layers. Understanding what each layer does makes it clear why R covers all four without reaching for expensive commercial alternatives.

The data layer ingests price data, cleans it, stores it, and makes it queryable. For NSE equities, this means pulling end-of-day prices. For forex, it means connecting to a broker’s historical tick or OHLCV data. For macro signals, it means scraping Central Bank of Kenya rate decisions or pulling World Bank API data.

The backtesting engine applies a strategy to historical data to estimate how it would have performed. It handles position sizing, transaction cost modelling, and produces performance metrics. A proper backtesting engine avoids look-ahead bias and accounts for the statistical problems that make most backtests unreliable.

The signal dashboard displays current live signals from the strategy, the current position or recommended position, and enough context to understand why the signal fired. This is the component a trader watches during market hours.

The risk monitor tracks live exposure, drawdown from peak, value at risk, and any circuit-breaker conditions that should force a position reduction or halt. It runs continuously and alerts when thresholds are breached.

These four components map cleanly onto a single Rhino project.

Rhino Project Structure for a Full Trading System

Rhino is Appsilon’s framework for building production-grade Shiny applications with engineering discipline. It enforces a module system, separates logic from presentation, and integrates testing from the start. For a trading system, this separation matters enormously: backtesting logic, signal computation, and risk calculations should be testable pure R functions, independent of any Shiny dependency.

A complete Rhino trading system project looks like this:

kwiz-trading-system/
├── app/
│   ├── main.R                    # Entry point, tab routing
│   ├── logic/
│   │   ├── data/
│   │   │   ├── nse_prices.R      # NSE equity price ingestion
│   │   │   ├── forex_ohlcv.R     # Forex OHLCV from broker API
│   │   │   └── macro_signals.R   # CBK rates, macro data
│   │   ├── backtest/
│   │   │   ├── engine.R          # Vectorised backtest runner
│   │   │   ├── metrics.R         # Sharpe, drawdown, Calmar
│   │   │   └── walk_forward.R    # Walk-forward validation
│   │   ├── signals/
│   │   │   ├── momentum.R        # Momentum signal module
│   │   │   └── mean_reversion.R  # Mean-reversion signal module
│   │   └── risk/
│   │       ├── position_size.R   # Kelly and fixed-fraction sizing
│   │       ├── drawdown.R        # Running drawdown monitor
│   │       └── var.R             # Historical VaR computation
│   └── view/
│       ├── backtest_tab.R        # Backtest results UI + server
│       ├── signals_tab.R         # Live signal dashboard UI + server
│       └── risk_tab.R            # Risk monitor UI + server
├── tests/
│   └── testthat/
│       ├── test-engine.R
│       ├── test-metrics.R
│       └── test-risk.R
├── renv.lock
└── rhino.yml

The logic/ layer contains no Shiny code. Every function in it can be called from a test, from the Shiny server, or from a batch job. This is what makes the difference between a trading dashboard that a single developer can maintain and one that becomes unmaintainable when the original author leaves.

Data Sources Available to Kenyan Quants

Before building any of the other components, the data layer determines what is actually possible. Here is what is available without paying for Bloomberg.

For NSE equities, the NSE website publishes daily brokerage trade reports in CSV format. The quantmod package can pull some emerging market data. For more complete NSE historical data, services like Africa Financial Data (Africagis) and some local brokers provide API access. The httr2 package handles any REST-based data ingestion cleanly.

For forex, MetaTrader 5’s built-in history export is the most practical starting point for retail quants. Any broker running MT5 stores tick and OHLCV data that can be exported programmatically. The RMT5 community package provides a bridge; alternatively, exporting to CSV via MT5’s scripting interface and ingesting with readr is reliable and broker-agnostic.

For macro data, the World Bank API is accessible via the wbstats package. The Central Bank of Kenya publishes rate decisions, money supply data, and exchange rate history on its website, accessible via rvest for scraping or via direct CSV download where structured formats are available.

Vectorised Backtesting in R

The backtesting engine is where most independent quants spend the most time and make the most mistakes. A vectorised approach using xts and PerformanceAnalytics is both fast and statistically defensible. The core engine lives in app/logic/backtest/engine.R:

box::use(
  xts[xts, endpoints, period.apply],
  zoo[coredata, index],
  PerformanceAnalytics[Return.calculate, SharpeRatio, maxDrawdown, CalmarRatio],
  dplyr[tibble, mutate, lag],
  TTR[SMA, RSI, MACD]
)

#' Run a vectorised backtest on OHLCV data
#'
#' @param ohlcv     An xts object with OHLC columns and a Volume column
#' @param signal_fn A function that takes ohlcv and returns a numeric signal
#'                  vector: +1 (long), -1 (short), 0 (flat)
#' @param cost_bps  Round-trip transaction cost in basis points (default 5)
#' @return A list with equity curve (xts), trade log (tibble), and metrics
run_backtest <- function(ohlcv, signal_fn, cost_bps = 5) {

  # Generate signals from close prices; strictly lagged to avoid look-ahead
  signal <- signal_fn(ohlcv)
  signal_lagged <- lag(signal, 1)          # Apply signal on next bar open
  signal_lagged[1] <- 0                    # No position on first bar

  # Daily returns from close-to-close
  close_prices  <- ohlcv[, "Close"]
  daily_returns <- Return.calculate(close_prices, method = "discrete")
  daily_returns[1] <- 0

  # Strategy returns: signal * next-bar return, minus costs on position changes
  position_change <- abs(diff(signal_lagged))
  position_change[1] <- 0
  cost_drag <- position_change * (cost_bps / 10000)

  strategy_returns <- (signal_lagged * coredata(daily_returns)) - cost_drag

  # Build equity curve from strategy returns
  equity_xts <- xts(
    cumprod(1 + strategy_returns) * 10000,   # Starting with 10,000 units
    order.by = index(ohlcv)
  )
  colnames(equity_xts) <- "equity"

  # Compute performance metrics
  ann_factor <- 252   # Trading days per year
  metrics <- list(
    sharpe_ratio  = SharpeRatio(strategy_returns, annualize = TRUE,
                                FUN = "StdDev")[1],
    max_drawdown  = maxDrawdown(strategy_returns),
    calmar_ratio  = CalmarRatio(strategy_returns),
    total_return  = as.numeric(tail(equity_xts, 1)) / 10000 - 1,
    n_trades      = sum(position_change > 0, na.rm = TRUE)
  )

  list(
    equity  = equity_xts,
    returns = strategy_returns,
    metrics = metrics
  )
}

One implementation detail matters more than any other: the lag(signal, 1) call on line 13. This is the look-ahead barrier. The signal computed on bar is applied to bar , which is the earliest possible execution. Skipping this step is the most common source of unrealistic backtest results. The strategy appears to execute at the same price it used to generate the signal, which is impossible in live trading.

A Signal Module: Momentum with Trend Filter

The signal module in app/logic/signals/momentum.R implements a simple but testable momentum strategy. The filter prevents trading against a longer-term trend, a common technique for reducing whipsaw in trending markets:

box::use(
  TTR[SMA, RSI],
  zoo[coredata]
)

#' Momentum signal with 200-day trend filter
#'
#' @param ohlcv  xts OHLCV object
#' @param fast   Fast SMA window (default 20)
#' @param slow   Slow SMA window (default 50)
#' @param trend  Long-term trend SMA window (default 200)
#' @param rsi_w  RSI window for overbought/oversold filter (default 14)
#' @return Numeric vector: +1 (long), -1 (short), 0 (flat)
momentum_signal <- function(ohlcv, fast = 20, slow = 50,
                            trend = 200, rsi_w = 14) {
  close  <- coredata(ohlcv[, "Close"])
  sma_f  <- SMA(close, n = fast)
  sma_s  <- SMA(close, n = slow)
  sma_t  <- SMA(close, n = trend)
  rsi    <- RSI(close, n = rsi_w)

  n      <- length(close)
  signal <- numeric(n)

  for (i in seq_len(n)) {
    if (is.na(sma_f[i]) || is.na(sma_s[i]) || is.na(sma_t[i])) next

    above_trend <- close[i] > sma_t[i]
    momentum_up <- sma_f[i] > sma_s[i]

    # Long: above trend, momentum positive, not overbought
    if (above_trend && momentum_up && !is.na(rsi[i]) && rsi[i] < 70) {
      signal[i] <- 1L
    # Short: below trend, momentum negative, not oversold
    } else if (!above_trend && !momentum_up && !is.na(rsi[i]) && rsi[i] > 30) {
      signal[i] <- -1L
    }
  }

  signal
}

This signal function takes an xts object and returns a plain numeric vector. No Shiny dependencies, no global state. The tests/testthat/test-engine.R file can call momentum_signal() directly on synthetic data and assert that the output has the right length, contains only -1, 0, and 1, and returns 0 for the first 199 bars where the trend filter has insufficient history.

Risk Monitor: Position Sizing and Live Drawdown

The risk monitor is the component most independent traders skip and most regret skipping. The position sizing module in app/logic/risk/position_size.R implements both fractional Kelly and fixed-fraction sizing, giving the trader control over how aggressively the system bets:

box::use(dplyr[...])

#' Compute position size using fractional Kelly criterion
#'
#' @param win_rate    Historical win rate (proportion, 0 to 1)
#' @param win_loss_r  Average win-to-loss ratio
#' @param kelly_frac  Kelly fraction to apply (0.25 = quarter-Kelly)
#' @param account_eq  Current account equity in base currency
#' @param price       Current asset price
#' @return Recommended position size in units
kelly_position_size <- function(win_rate, win_loss_r,
                                kelly_frac = 0.25,
                                account_eq, price) {
  # Full Kelly fraction of capital to risk
  full_kelly <- (win_rate * win_loss_r - (1 - win_rate)) / win_loss_r
  fractional_kelly <- max(0, full_kelly * kelly_frac)

  capital_at_risk <- account_eq * fractional_kelly
  units <- floor(capital_at_risk / price)
  units
}

#' Check if drawdown circuit breakers are active
#'
#' @param current_equity  Current account equity
#' @param peak_equity     Highest recorded equity
#' @param soft_limit_pct  Drawdown % that triggers reduced sizing (default 0.10)
#' @param hard_limit_pct  Drawdown % that halts all trading (default 0.20)
#' @return A list with status ("normal", "reduced", "halted") and drawdown_pct
check_circuit_breakers <- function(current_equity, peak_equity,
                                   soft_limit_pct = 0.10,
                                   hard_limit_pct = 0.20) {
  dd_pct <- (peak_equity - current_equity) / peak_equity

  status <- dplyr::case_when(
    dd_pct >= hard_limit_pct ~ "halted",
    dd_pct >= soft_limit_pct ~ "reduced",
    TRUE                     ~ "normal"
  )

  list(status = status, drawdown_pct = dd_pct)
}

The circuit breaker logic is what separates a risk monitor from a reporting tool. When status is "halted", the signal dashboard should display a hard stop and the system should not generate new position recommendations regardless of what the signal module outputs. This logic runs before signal generation in the Shiny server, not after.

For more on position sizing foundations, see the Kelly criterion and position sizing guide.

What This Stack Cannot Do: Honest Limitations

Any serious treatment of this topic requires acknowledging where R-based independent infrastructure falls short of institutional systems.

Latency. R is not a low-latency execution environment. Institutional high-frequency trading systems operate in microseconds using co-located C++ or FPGA hardware. This stack targets end-of-day or intraday strategies with holding periods measured in minutes or longer. If your edge requires sub-second execution, this is the wrong tool. For NSE equities, where the market operates in a relatively low-frequency environment, end-of-day and intraday signals on the 5-minute or 15-minute timeframe are entirely realistic targets.

Data quality. NSE historical data has gaps, corporate action adjustments that are not always clean, and limited tick-level granularity. Any backtest using NSE data needs explicit handling of trading halts, delisting events, and dividend adjustments. Survivorship bias is a real risk if you build a universe of NSE stocks using the current listing and backtest historically.

Execution integration. This stack produces signals and monitors risk, but it does not execute trades directly. Integration with an execution layer (MT5 via MetaSocket, or a broker API for NSE equities) adds engineering complexity that goes beyond the scope of a single Shiny application.

Regulatory compliance. The Capital Markets Authority has specific requirements for algorithmic trading in Kenya. Independent quants should review the CMA’s framework before deploying any live automated system, even for personal account trading.

The Infrastructure Cost Comparison

To make the cost contrast concrete: running this full stack in production costs between $24 and $48 per month on a DigitalOcean or Hetzner VPS. The lower end handles a single-user setup with one or two strategies. The higher end covers a small team, a PostgreSQL instance for trade logging, and enough headroom for backtesting runs that crunch several years of daily data.

Bloomberg Terminal: approximately $2,083 per month. FactSet: approximately $1,000 to $2,000 per month. A complete R/Shiny Rhino stack: under $50 per month, open-source tools, and full ownership of the code.

The remaining gap is not technology. It is data, and specifically tick-level or institutional-grade data for assets where the edge lives in microstructure. For strategies that operate on daily or hourly data, that gap effectively does not exist.

For the deployment side of this infrastructure, the R Shiny hosting guide covers the options from shinyapps.io to self-hosted Docker containers in detail. For the statistical rigour that the backtesting metrics need, the Deflated Sharpe Ratio post explains why the metrics this engine produces require adjustment before you trust them for strategy selection.

The Real Question for Kenyan Quants

The technology case for building institutional-grade trading infrastructure in R is clear. The packages exist, the deployment patterns work, and the cost is within reach of any serious independent practitioner.

The harder question is whether independent Kenyan quants are building anything at all, or whether the perception that institutional infrastructure is inaccessible is itself the barrier. The quant gap between a retail trader in Nairobi and a systematic desk in Johannesburg is closing from both directions: retail tools are improving, and institutional alpha in liquid markets is compressing. The window where independent quants in East Africa can build systematic edges with these tools is open now.

What stops most independent quants from building this is not capability. It is starting.

Kwiz Computing Technologies builds production R/Shiny and Rhino applications for trading teams and data-intensive businesses across East Africa. If you are working on systematic trading infrastructure and want to discuss architecture, see how we approach systematic trading in R or how the quant gap between retail and institutional traders is narrowing in Africa.

The Carbon Market Landscape

Quantitative Approaches

library(forecast)
library(tseries)

# Load EU ETS carbon price data
carbon_prices <- read_csv("eu_ets_prices.csv") |>
  mutate(log_return = log(price / lag(price)))

# Test for stationarity
adf.test(carbon_prices$log_return, alternative = "stationary")

# GARCH modelling for volatility dynamics
library(rugarch)

spec <- ugarchspec(
  variance.model = list(model = "sGARCH", garchOrder = c(1, 1)),
  mean.model = list(armaOrder = c(1, 0)),
  distribution.model = "std"  # Student-t for fat tails
)

fit <- ugarchfit(spec, carbon_prices$log_return)

library(depmixS4)

# Fit a 3-state HMM to carbon returns
hmm_model <- depmix(
  log_return ~ 1,
  data = carbon_prices,
  nstates = 3,
  family = gaussian()
)

hmm_fit <- fit(hmm_model)

# Extract regime probabilities
regimes <- posterior(hmm_fit)
carbon_prices$regime <- regimes$state

library(feasts)
library(tsibble)

carbon_tsibble <- carbon_prices |>
  as_tsibble(index = date)

decomposition <- carbon_tsibble |>
  model(STL(price ~ season(period = 252))) |>  # Trading days
  components()

autoplot(decomposition)

Environmental Data Meets Market Data

library(terra)
library(sf)

# Process satellite data for reforestation project
ndvi_timeseries <- rast("project_ndvi_2020_2025.tif") |>
  extract(project_boundary) |>
  summarise(mean_ndvi = mean(NDVI, na.rm = TRUE), .by = date)

# Correlate vegetation growth with credit issuance
correlation_analysis <- merge(
  ndvi_timeseries,
  credit_issuance,
  by = "date"
)

cor.test(
  correlation_analysis$mean_ndvi,
  correlation_analysis$credits_issued
)

# Synthetic control method for additionality assessment
library(Synth)

# Compare project region against similar non-project regions
# to estimate counterfactual emissions
synth_result <- synth(
  dataprep.out = dataprep(
    foo = emissions_data,
    predictors = c("gdp", "population", "forest_cover", "temperature"),
    dependent = "emissions",
    unit.variable = "region_id",
    time.variable = "year",
    treatment.identifier = project_region,
    controls.identifier = control_regions,
    time.predictors.prior = 2015:2019,
    time.optimize.ssr = 2015:2019,
    time.plot = 2015:2025
  )
)

The Kwiz Approach

Carbon markets represent a natural convergence of our two core competencies:

1. Environmental data science provides the domain knowledge to assess project quality, process satellite monitoring data, and understand the science behind emission reductions.

2. Quantitative finance provides the statistical framework for price modelling, regime detection, risk assessment, and systematic analysis of market dynamics.

We see carbon markets as a domain where interdisciplinary expertise — rather than pure financial engineering or pure environmental science alone — creates the most value. Organisations navigating these markets need partners who understand both the environmental integrity of carbon credits and the financial dynamics of the markets where they trade.

Looking Forward

As carbon markets mature and expand — the voluntary market alone is projected to grow substantially over the coming decade — the demand for rigorous, data-driven analysis will only increase. The organisations and projects that adopt quantitative methods for monitoring, verification, and market analysis will have a significant advantage over those relying on qualitative assessments and rules of thumb.

At Kwiz Computing, we are positioning ourselves at this intersection — applying the same engineering discipline and statistical rigour that characterises our trading infrastructure and environmental analytics to the carbon market ecosystem. It is, in many ways, the project that best represents what we do: building intelligent systems at the boundary between environmental science and finance.

The Purging and Embargo Solution

Marcos Lopez de Prado’s Combinatorial Purged Cross-Validation (CPCV) addresses these issues through two mechanisms:

Timeline:  |---Train---|xxxPURGEDxxx|---Test---|xxxPURGEDxxx|---Train---|

Timeline:  |---Train---|xxPURGExx|--EMBARGO--|---Test---|--EMBARGO--|xxPURGExx|---Train---|

The Combinatorial Approach

Standard walk-forward testing uses the data once: train on the first 80%, test on the last 20%. This is wasteful — you get a single estimate of performance from one specific market regime.

CPCV generates all possible combinations of contiguous training and test groups, subject to purging and embargo constraints. For a dataset split into N groups with k test groups, CPCV produces unique backtest paths.

This gives you:

1. Multiple independent performance estimates rather than a single point estimate
2. A distribution of backtest results that reveals strategy robustness
3. More efficient use of limited data — every observation appears in test sets

R Implementation

Here is a simplified implementation of the CPCV framework:

#' Generate CPCV train/test splits with purging and embargo
#'
#' @param n_obs Number of observations
#' @param n_groups Number of groups to split into
#' @param n_test Number of groups to use as test in each split
#' @param purge_length Number of observations to purge at boundaries
#' @param embargo_pct Embargo as a fraction of dataset length
#' @return List of train/test index pairs
generate_cpcv_splits <- function(n_obs, n_groups = 6, n_test = 2,
                                  purge_length = 5, embargo_pct = 0.01) {

  embargo_length <- ceiling(n_obs * embargo_pct)
  group_size <- floor(n_obs / n_groups)

  # Generate group boundaries
  groups <- lapply(seq_len(n_groups), function(g) {
    start <- (g - 1) * group_size + 1
    end <- min(g * group_size, n_obs)
    start:end
  })

  # Generate all combinations of test groups
  test_combos <- combn(n_groups, n_test, simplify = FALSE)

  splits <- lapply(test_combos, function(test_groups) {
    test_idx <- unlist(groups[test_groups])
    train_groups <- setdiff(seq_len(n_groups), test_groups)
    train_idx <- unlist(groups[train_groups])

    # Apply purging: remove training observations near test boundaries
    test_range <- range(test_idx)
    purge_zone <- c(
      (test_range[1] - purge_length):(test_range[1] - 1),
      (test_range[2] + 1):(test_range[2] + purge_length)
    )

    # Apply embargo
    embargo_zone <- c(
      (test_range[1] - purge_length - embargo_length):(test_range[1] - purge_length - 1),
      (test_range[2] + purge_length + 1):(test_range[2] + purge_length + embargo_length)
    )

    exclusion_zone <- unique(c(purge_zone, embargo_zone))
    exclusion_zone <- exclusion_zone[exclusion_zone > 0 & exclusion_zone <= n_obs]

    train_idx <- setdiff(train_idx, exclusion_zone)

    list(train = train_idx, test = test_idx)
  })

  splits
}

library(dplyr)
library(purrr)

# Generate splits
splits <- generate_cpcv_splits(
  n_obs = nrow(market_data),
  n_groups = 6,
  n_test = 2,
  purge_length = 10,
  embargo_pct = 0.02
)

# Evaluate strategy on each split
results <- map_dfr(splits, function(split) {
  train_data <- market_data[split$train, ]
  test_data <- market_data[split$test, ]

  # Fit strategy on training data
  model <- fit_strategy(train_data)

  # Evaluate on test data
  signals <- predict_signals(model, test_data)
  returns <- compute_strategy_returns(signals, test_data)

  tibble(
    sharpe = mean(returns) / sd(returns) * sqrt(252),
    max_drawdown = max_drawdown(cumsum(returns)),
    n_trades = sum(abs(diff(signals)) > 0)
  )
})

# Summary: distribution of out-of-sample performance
summary(results$sharpe)

CPCV vs Other Methods

Walk-forward testing avoids lookahead bias but gives you a single estimate from one market regime. Standard CV is efficient but leaks information. CPCV achieves both: no lookahead bias and multiple independent estimates.

Practical Considerations

Integration in the Kwiz Quants Pipeline

CPCV is the second validation gate in our pipeline, applied after the Deflated Sharpe Ratio screening. Strategies that pass DSR are subjected to CPCV to verify that their performance generalises across different time periods — not just the specific window that happened to produce the best-looking backtest.

Only strategies that show consistently positive risk-adjusted returns across all CPCV splits proceed to MT5 online backtesting. This ensures that when we deploy a strategy to live trading, we have evidence of robustness, not just a single favourable backtest.

Why the Standard Sharpe Ratio Fails

The Sharpe Ratio is the most widely used performance metric in quantitative finance. It measures risk-adjusted returns: the excess return per unit of volatility. A Sharpe Ratio of 1.0 is considered good; 2.0 is excellent.

But the standard Sharpe Ratio has no mechanism to account for how many strategies were tested to find the one being presented. If you tested 500 strategies and are showing the best one, the reported Sharpe Ratio is biased upward — sometimes dramatically so.

This is not a theoretical concern. It is the central challenge in quantitative strategy development, and the primary reason that “signal sellers” and retail strategy vendors consistently fail to deliver in live trading what they promised in backtests.

The Deflated Sharpe Ratio Framework

Marcos Lopez de Prado introduced the Deflated Sharpe Ratio (DSR) to address this problem directly. The DSR adjusts the observed Sharpe Ratio for:

1. The number of trials — how many strategies were tested before selecting this one
2. Skewness of the return distribution — asymmetry changes the significance threshold
3. Kurtosis of the return distribution — fat tails inflate the apparent Sharpe Ratio
4. The length of the backtest — shorter backtests are more susceptible to noise

The DSR answers a precise question: given how many strategies I tested and the statistical properties of the returns, what is the probability that this observed Sharpe Ratio is a false discovery?

Implementation in R

The DSR computation requires the observed Sharpe Ratio, the number of independent trials, and the higher moments of the return distribution:

#' Compute the Deflated Sharpe Ratio
#'
#' @param observed_sr Observed Sharpe Ratio of the selected strategy
#' @param n_trials Number of strategies tested
#' @param n_obs Number of return observations
#' @param skew Skewness of the return series
#' @param kurt Excess kurtosis of the return series
#' @return p-value: probability that the observed SR is a false discovery
deflated_sharpe_ratio <- function(observed_sr, n_trials, n_obs,
                                  skew = 0, kurt = 3) {

  # Expected maximum SR under the null hypothesis
  # (i.e., what you'd expect the best SR to be from n_trials of pure noise)
  euler_mascheroni <- 0.5772156649
  expected_max_sr <- sqrt(2 * log(n_trials)) -
    (log(pi) + euler_mascheroni) / (2 * sqrt(2 * log(n_trials)))

  # Standard error of the SR estimate, adjusted for higher moments
  sr_se <- sqrt(
    (1 - skew * observed_sr + ((kurt - 1) / 4) * observed_sr^2) / (n_obs - 1)
  )

  # Test statistic: how many SE above the expected maximum?
  test_stat <- (observed_sr - expected_max_sr) / sr_se

  # One-sided p-value
  p_value <- pnorm(test_stat, lower.tail = FALSE)

  list(
    observed_sr = observed_sr,
    expected_max_sr = expected_max_sr,
    p_value = p_value,
    is_significant = p_value < 0.05
  )
}

A Simulated Demonstration

To illustrate the DSR’s power, let’s generate 200 random strategies and see how many survive:

library(dplyr)
library(purrr)

set.seed(42)
n_strategies <- 200
n_days <- 500

# Generate random return series (no actual signal)
random_returns <- matrix(
  rnorm(n_strategies * n_days, mean = 0, sd = 0.01),
  nrow = n_days, ncol = n_strategies
)

# Compute Sharpe Ratios
sharpe_ratios <- apply(random_returns, 2, function(r) {
  mean(r) / sd(r) * sqrt(252)  # Annualised
})

# How many look "good" by naive SR?
sum(sharpe_ratios > 1.0)  # Typically 5-15 strategies

# Apply DSR to the best strategy
best_idx <- which.max(sharpe_ratios)
best_returns <- random_returns[, best_idx]

dsr_result <- deflated_sharpe_ratio(
  observed_sr = sharpe_ratios[best_idx],
  n_trials = n_strategies,
  n_obs = n_days,
  skew = moments::skewness(best_returns),
  kurt = moments::kurtosis(best_returns)
)

# The DSR will correctly identify this as NOT significant
# because the high SR is explained by the number of trials

In typical runs, the best random strategy achieves a Sharpe Ratio of 1.5-2.5 — impressive by conventional standards. But the DSR correctly identifies it as a false discovery, because the expected maximum SR from 200 random trials explains the observed value entirely.

How Kwiz Quants Uses DSR

In the Kwiz Quants validation pipeline, every strategy must pass the DSR test before proceeding to MT5 backtesting. This is the first gate in our multi-layer validation process:

1. DSR screening — Does the strategy’s Sharpe Ratio survive adjustment for the number of strategies tested? If not, it is discarded regardless of how good the backtest looks.
2. Combinatorial Purged Cross-Validation — Does the strategy generalise across non-overlapping time periods without lookahead bias?
3. MT5 online backtesting — Does the strategy perform with realistic spreads and slippage?
4. Demo live trading — Does the strategy work under real market conditions?

The DSR is the cheapest and most powerful filter. It eliminates the majority of false discoveries before they consume expensive testing resources downstream.

Implications

The DSR has a simple but profound implication: the number of strategies you tried matters as much as the performance of the one you selected. Any performance report that doesn’t disclose the number of trials is, at best, incomplete and, at worst, misleading.

For retail traders evaluating signal providers or strategy vendors, ask one question: how many strategies did you test before finding this one? If the answer is vague or unavailable, the reported performance is almost certainly inflated by selection bias.

For quantitative researchers, the DSR should be a standard part of every strategy development workflow. It costs almost nothing to compute and prevents the most common source of live trading disappointment.

Statistical Depth

R’s statistical ecosystem is unmatched. The breadth of packages for time series analysis, financial econometrics, and statistical testing is deeper than any other language. When you’re implementing combinatorial purged cross-validation or computing Deflated Sharpe Ratios, R’s statistical foundations make the work cleaner and more reliable.

Production-Ready R

The perception that R is “just for analysis” is outdated. Modern R infrastructure makes production deployment viable: Plumber for REST APIs, Docker for containerisation, renv for reproducible environments, and Rhino for application architecture.

The key is engineering discipline. We apply the same practices used in any production software stack: modular code with box, 95%+ test coverage with testthat, CI/CD pipelines, and structured logging.

The Kwiz Quants Stack

Our trading infrastructure connects R-based strategy engines to MetaTrader 5 execution via MetaSocket, with PostgreSQL for logging and Shiny for monitoring. Each component is containerised, tested, and designed for resilience — atomic writes, hot standby replicas, and versioned snapshots.

R isn’t the easy choice for trading infrastructure. But it’s the right choice for a system where statistical rigour is the core differentiator.

Why Data Quality Matters

Biodiversity data feeds directly into conservation planning, EIA baseline studies, and policy decisions. When that data contains coordinate errors, taxonomic misidentifications, or temporal gaps, the downstream consequences are real: protected areas drawn around phantom populations, impact assessments that miss genuinely sensitive species, and monitoring programmes built on unreliable baselines.

The challenge is that GBIF data comes from heterogeneous sources — museum collections, citizen science platforms, academic surveys — each with different quality standards and error profiles.

A Reproducible Quality Assessment Workflow

Our pipeline operates in four stages, each implemented as testable R functions:

library(rgbif)
library(dplyr)

# Retrieve occurrence data for Kenya
occurrences <- occ_search(
  country = "KE",
  hasCoordinate = TRUE,
  limit = 50000
)$data

# Initial profiling
profiling <- occurrences |>
  summarise(
    n_records = n(),
    n_species = n_distinct(species),
    date_range = paste(min(year, na.rm = TRUE), max(year, na.rm = TRUE), sep = "-"),
    pct_with_coords = mean(!is.na(decimalLatitude)) * 100
  )

library(sf)
library(CoordinateCleaner)

# Flag coordinate issues
cleaned <- occurrences |>
  cc_val() |>         # Remove invalid coordinates
  cc_zero() |>        # Flag zero coordinates
  cc_cen() |>         # Flag country centroids
  cc_dupl() |>        # Flag exact duplicates
  cc_gbif() |>        # Flag GBIF headquarters
  cc_inst()           # Flag biodiversity institutions

# Verify taxonomy against GBIF backbone
taxa_check <- occurrences |>
  distinct(species, taxonomicStatus, taxonRank) |>
  filter(
    taxonomicStatus != "ACCEPTED" |
    taxonRank != "SPECIES"
  )

Key Findings from the Kenya Dataset

Applying this pipeline to Kenyan GBIF data consistently reveals several patterns:

• A significant fraction of records fall on country or county centroids, indicating geocoding from administrative labels rather than actual observation coordinates
• Temporal coverage is heavily skewed toward recent decades, with sparse data before 2000
• Spatial sampling is concentrated along major transport corridors and near Nairobi, with large areas of northern Kenya essentially unsampled
• Bird records dominate the dataset, with invertebrates and plants substantially under-represented relative to their actual diversity

Implications for Practice

These findings have direct implications for how GBIF data should be used in environmental assessments:

1. Never use raw GBIF data without quality filtering. The proportion of records flagged by our pipeline typically ranges from 15-30% — enough to materially change any analysis.

2. Document your filtering decisions. Reproducible pipelines ensure that quality decisions are transparent and auditable — critical for EIA submissions.

3. Acknowledge sampling gaps. Absence of records does not mean absence of species. Reporting what the data cannot tell you is as important as what it can.

4. Combine sources. GBIF data should be supplemented with targeted field surveys, especially in under-sampled regions.

Building Better Tools

This work informs our broader commitment to environmental data transparency. Our open-source kenyaEIAFetcher R package applies similar principles to EIA data access, and we are working on additional tools to make environmental data quality assessment more accessible to practitioners across East Africa.

Reproducible, transparent data quality assessment is not just good practice — it is essential for environmental governance that works.

Why Data Matters in Informal Settlements

Formal urban development benefits from extensive data: cadastral records, utility maps, building permits, and environmental monitoring networks. Informal settlements typically lack all of these. Planning green infrastructure in data-scarce environments requires creative analytical approaches — exactly where R’s ecosystem excels.

R enables practitioners to:

• Map and analyse settlement patterns using satellite imagery and spatial data, even without official documentation
• Identify environmental vulnerabilities through statistical modelling and spatial analysis
• Optimise resource distribution using mathematical optimisation
• Establish rigorous evaluation frameworks for measuring intervention effectiveness

Use Case 1: Spatial Analysis for Green Infrastructure Planning

Determining where to place green infrastructure (community gardens, bio-swales, tree planting, green roofs) requires understanding complex spatial relationships. We use sf and leaflet to model site suitability based on multiple factors:

library(sf)
library(leaflet)

# Score potential sites based on multiple criteria
sites <- potential_locations |>
  mutate(
    suitability = 0.3 * drainage_score +
                  0.25 * access_score +
                  0.2 * sunlight_score +
                  0.15 * soil_quality +
                  0.1 * community_proximity,
    priority = case_when(
      suitability > 0.7 ~ "High",
      suitability > 0.4 ~ "Medium",
      TRUE ~ "Low"
    )
  )

# Interactive mapping for stakeholder engagement
leaflet(sites) |>
  addTiles() |>
  addCircleMarkers(
    color = ~priority_palette(priority),
    popup = ~paste("Type:", infrastructure_type,
                   "<br>Score:", round(suitability, 2))
  )

Interactive maps are particularly valuable for stakeholder engagement in communities where technical reports may not be accessible. A visual tool that residents can interact with drives better participation and more informed decision-making.

Use Case 2: Climate Vulnerability and Green Roof Modelling

Informal settlements experience disproportionate climate risks. Green roofs offer a relatively low-cost intervention for heat reduction, but planners need to understand the cost-benefit tradeoffs at different scales.

We model the relationship between green roof coverage and temperature reduction, then estimate the economic implications:

library(ggplot2)

# Model temperature reduction vs coverage
coverage_model <- tibble(
  coverage_pct = seq(0, 100, by = 5),
  temp_reduction = 5 * (coverage_pct / 100),  # Simplified linear model
  avoided_heat_days = temp_reduction * 8,       # Days above threshold
  cost_per_sqm = 45 - 0.15 * coverage_pct      # Economies of scale
)

ggplot(coverage_model, aes(coverage_pct, temp_reduction)) +
  geom_line(color = "#14b8a6", linewidth = 1.2) +
  labs(
    title = "Green Roof Coverage vs Temperature Reduction",
    x = "Coverage (%)",
    y = "Temperature Reduction (°C)"
  )

The analysis typically reveals diminishing cost-efficiency returns at higher coverage percentages — helping planners identify optimal intervention scales that maximise impact per unit of investment.

Use Case 3: Water Resource Optimisation

Many settlements experience simultaneous water scarcity during dry periods and flooding during rains. Rainwater harvesting systems can address both, but optimal tank sizing requires statistical modelling of rainfall patterns:

library(forecast)

# Model rainfall and harvesting potential
rainfall_model <- rainfall_data |>
  group_by(month) |>
  summarise(
    mean_rain = mean(rainfall_mm),
    p25 = quantile(rainfall_mm, 0.25),
    p75 = quantile(rainfall_mm, 0.75)
  )

# Optimise tank capacity for reliability
tank_optimisation <- tibble(
  capacity_litres = seq(500, 10000, by = 500)
) |>
  mutate(
    reliability = map_dbl(capacity_litres, ~simulate_tank(., rainfall_data)),
    cost = capacity_litres * cost_per_litre
  )

Use Case 4: Air Quality and Vegetation Impact

Informal settlements frequently suffer from poor air quality. We use spatial correlation analysis to quantify the relationship between vegetation cover (measured by NDVI from satellite imagery) and particulate matter concentrations:

library(terra)

# Correlate vegetation with air quality
ndvi <- rast("settlement_ndvi.tif")
pm25 <- rast("pm25_measurements.tif")

correlation <- layerCor(c(ndvi, pm25), fun = "pearson")

This analysis consistently shows that increased vegetation significantly reduces particulate pollution — providing an evidence base for prioritising tree planting and green space creation in the most polluted areas.

The Broader Vision

R enables a level of analytical rigour in informal settlement planning that was previously accessible only to well-resourced formal development projects. By making these tools open and reproducible, we aim to democratise evidence-based environmental planning for the communities that need it most.

This work sits at the intersection of our environmental data science practice and our commitment to using technology for social impact. The same spatial analysis capabilities we use for EIA assessments and biodiversity monitoring translate directly to urban environmental challenges — different domain, same engineering discipline.

The Hosting Landscape

library(rsconnect)
rsconnect::deployApp("my_app/")

FROM rocker/shiny-verse:4.3.0

# Install system dependencies
RUN apt-get update && apt-get install -y libpq-dev

# Copy renv lockfile and restore packages
COPY renv.lock /app/renv.lock
WORKDIR /app
RUN R -e "renv::restore()"

# Copy application code
COPY . /app

EXPOSE 3838
CMD ["R", "-e", "shiny::runApp('/app', port = 3838, host = '0.0.0.0')"]

Decision Framework

Essential Production Considerations

# GitHub Actions: deploy on push to main
name: Deploy Shiny App
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: r-lib/actions/setup-r@v2
      - run: Rscript -e "rsconnect::deployApp('.')"

Our Recommendation

Start with shinyapps.io for prototyping and stakeholder demos. When you need production stability, move to Docker containers deployed on your preferred cloud provider. This progression gives you speed early and control when it matters.

The key principle: get your app in front of users first, then optimise the infrastructure. Over-engineering the hosting before validating the application is a common mistake that slows the path to value.

Understanding Quarto Outputs

Before choosing a platform, understand what you’re deploying:

• Static websites (HTML/CSS/JS) — the most common output. These are just files that any web server can host.
• Interactive documents — Quarto docs with embedded Shiny components require a server-side R process. These need specialised hosting.
• Non-web outputs — PDFs, Word documents, and presentations are generated locally and don’t need hosting.

Most Quarto projects produce static websites, which gives you the widest range of hosting options.

Quick Start Platforms

# .github/workflows/publish.yml
name: Render and Deploy Quarto
on:
  push:
    branches: [main]

jobs:
  build-deploy:
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
      - uses: actions/checkout@v4
      - uses: quarto-dev/quarto-actions/setup@v2
      - name: Render
        run: quarto render
      - name: Deploy
        uses: peaceiris/actions-gh-pages@v4
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          publish_dir: ./_site

Enterprise Cloud Deployments

# Render and sync to S3
quarto render
aws s3 sync _site/ s3://your-bucket-name --delete

# Invalidate CloudFront cache
aws cloudfront create-invalidation \
  --distribution-id YOUR_DIST_ID \
  --paths "/*"

firebase init hosting
# Set public directory to _site
quarto render
firebase deploy

CI/CD Best Practices

Automate your deployment pipeline from day one. Manual deployment introduces human error and slows iteration.

Key principles:

1. Render on CI, not locally. This ensures your site builds from a clean environment, catching dependency issues early.
2. Pin your Quarto version. Use quarto-dev/quarto-actions/setup@v2 with a specific version to avoid surprise breaking changes.
3. Cache dependencies. R and Python package installation is the slowest part of most builds. Cache aggressively.
4. Deploy previews for PRs. Netlify and Cloudflare Pages offer this out of the box. For other platforms, deploy to a staging URL on pull requests.

Performance Optimisation

Once deployed, optimise for speed:

• Image optimisation — Use modern formats (WebP, AVIF) and appropriate dimensions. Tools like sharp or imagemagick can automate this in your build pipeline.
• Asset minification — Quarto handles CSS/JS minification by default, but verify this in your _quarto.yml configuration.
• Caching headers — Configure your CDN to cache static assets aggressively (e.g., 1 year for hashed filenames).
• Compression — Enable gzip or Brotli compression at the server/CDN level.

Choosing the Right Platform

Our Approach

At Kwiz Computing, we use GitHub Pages for our public-facing Quarto sites (including this one) and AWS infrastructure for client projects requiring custom domains, access control, or integration with existing cloud environments.

The fundamental recommendation: deploy early, automate immediately. Getting your content online and iterating in production is more valuable than perfecting your local build. Start with a free tier platform, add CI/CD automation, and only move to enterprise infrastructure when you have a concrete reason.