Work
Open Source Tools

CompToxR
R package for accessing US EPA CompTox Chemistry Dashboard APIs and related chemistry products. Supports programmatic retrieval of chemical identifiers, properties, hazard information, exposure predictions, and cheminformatics data for risk-evaluation workflows.

CONCERT
Chemical ontology harmonization and entity-resolution toolkit for identifier crosswalking, canonicalization, data reconciliation, and defensible transformation of messy source records into analysis-ready chemical data.

CHORUS
Constituent Hazard, Occurrence, Regulatory, and Uncertainty Screening. A screening framework for prioritizing environmental constituents by combining hazard and fate signals, occurrence evidence, regulatory benchmarks, and uncertainty-aware decision logic.

boosterpak
Reusable R project capability packs: typed bundles of dependencies, optional source specs, startup attachment intent, helper-function sidecars, and project-local setup conventions for reproducible workflows.

specmill
R package for generating and maintaining API clients from local OpenAPI schemas and reviewed YAML policy. Creates endpoint wrappers, documentation, and request contract tests while the client package retains control of HTTP, authentication, and response handling.

Serapeum
Local-first literature-review and research assistant built with R, Shiny, DuckDB, OpenAlex, and LLM-assisted analysis. Intended to make paper triage, metadata capture, and evidence synthesis reproducible instead of chat-log archaeology.
Packages and tools I use
This is the working stack, not a prescription. I care less about the exact app than whether the work can be inspected, reproduced, and handed to the next person without a séance.
Analysis, visualization, and maps
Most of my technical work starts in R and the tidyverse. I use dplyr, tidyr, readr, and purrr to make data transformations explicit rather than burying them in a succession of spreadsheet edits. ggplot2 is the default for figures, while plotly is useful when an interactive view actually helps someone explore a result.
For chemical and environmental work, the hard part is usually not the model. It is building a defensible path from messy source records to an analysis table. That means readable R scripts, stable identifiers, preserved raw inputs, and a record of each transformation.
Local data and applications
DuckDB and SQL are the local analytical layer. They are particularly useful when source data have outgrown a folder of CSV files but do not need a service or a full database administration project.
I build interactive tools with Shiny and bslib. The goal is not to put a dashboard on every question. It is to put methods, inputs, and results where collaborators can inspect and use them without asking someone to rerun a script.
Writing and publication
Quarto and Markdown are the publishing layer for reports, presentations, reproducible analyses, and this site. I want the prose, code, figures, citations, and output in one reviewable project rather than split across a document, a spreadsheet, and a folder named final_final_v3.
Obsidian is my durable notebook and operations record. Project notes, decisions, research references, and handoffs live there so the work has a memory outside of chat logs and my head.
Reproducible R projects
pak installs packages. renv records the project library and lockfile. They handle different jobs, and I use both.
I built boosterpak for the layer above that: a reusable project capability pack. A pack can declare dependencies, helper functions, startup choices, configuration, and checks for a specific kind of project. It keeps recurring setup visible and reusable without pretending a package list alone is a workflow.
Version control, automation, and remote work
Git and GitHub are the record of changes. GitHub Actions handles the boring, important checks and site deployment. Python and shell scripts fill the gaps when R is not the right tool for a small job.
I use Tailscale and mobile SSH through Terminus to reach the same working environment away from my desk. The point is continuity, not turning every project into an infrastructure project.
AI-assisted development
I use Claude Code, Hermes, and custom task skills as development tools. They are useful for bounded work: exploring a codebase, drafting a first pass, running checks, and keeping long projects moving. They are not a substitute for source data, domain judgment, or reviewing what actually changed.
Publications