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.

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.

The Business Case

Addressing Common Concerns

When R Makes Strategic Sense

R is the right investment when your organisation:

• Is data-centric and analytics drives core business decisions
• Employs domain specialists (statisticians, data scientists, researchers) who already think in R
• Needs specialised statistical capabilities that R’s ecosystem provides uniquely
• Operates in regulated industries where reproducibility and auditability are requirements
• Prioritises speed from insight to production over infrastructure flexibility

When R Is Not the Answer

R is not a general-purpose web development framework. If you’re building a consumer-facing web application, a mobile app, or a system where analytical computation is a minor component, other technologies are better suited. The key is recognising R as a specialised tool that excels in specific contexts — not a replacement for your entire technology stack.

The Integration Approach

Successful organisations don’t replace their existing technology portfolio with R. They integrate R as a specialised capability alongside their existing systems. R handles the analytical and statistical workloads where it excels, connected to the broader infrastructure through APIs and containerised deployments.

This is exactly how we work at Kwiz Computing Technologies. R is our primary language because our work — environmental data science, enterprise analytics, quantitative finance — sits squarely in R’s zone of excellence. For organisations with similar data-intensive, analytically complex workloads, R delivers genuine strategic value.

Building Bridges with R

Our approach is to build R packages that wrap these data sources into clean, documented, testable interfaces. The kenyaEIAFetcher package is our first public contribution — providing structured access to Kenya’s Environmental Impact Assessment database.

Each package follows enterprise-grade development standards: comprehensive documentation with roxygen2, full test suites with testthat, continuous integration via GitHub Actions, and pkgdown documentation sites.

What’s Next

We’re exploring additional packages for other Kenyan data sources, with a focus on environmental and governance data. If you’re working with Kenyan open data and want to collaborate, get in touch.

A Better Approach

At Kwiz Computing Technologies, we advocate for reproducible ESIA workflows built on R and Quarto. This means version-controlled code, automated data pipelines, parameterised reports, and transparent methodology that any qualified reviewer can verify.

Our kenyaEIAFetcher package is one step in this direction — providing programmatic access to Kenya’s EIA database so that researchers and practitioners can work with structured data rather than manual downloads.

Key Principles

The same engineering discipline we apply to our trading systems serves environmental data science: test your code, document your methods, version your analyses, and make your work reproducible by default.

Reproducibility isn’t just good science — it’s good engineering.