a windows-only modeling pipeline the portfolio owner could run from their mac

Context

The engagement modeled the impact of combining next-generation HIV prevention and treatment products — oral and injectable PrEP, rings, implants, bNAbs, a future vaccine and cure, VMMC, ART variants — across 55 countries and hundreds of rollout scenarios. The engine is Avenir Health’s Spectrum GOALS model, driven in batch. The modeling was sound; the bottleneck was operational: Spectrum is Windows-only and slow, and the person who owned the portfolio and its assumptions worked on a Mac.

What this is

A fully automated R pipeline in four stages:

• Templating — reads an Excel assumptions database, enumerates every product-combination branch, and applies market-dynamics rules (synergy, amplify, cannibalize) — e.g. long-acting PrEP cannibalizing oral PrEP.
• PJNZ editing — programmatically edits Spectrum country files, scoped to priority countries, in parallel.
• Extraction — runs Spectrum in batch over every branch, with a validation-and-auto-retry loop for corrupted or incomplete jobs.
• Post-processing — consolidates every branch into an analysis-ready dataset of infections, deaths, and coverage by country and scenario.

The architecture

The pipeline detects who is running it and on what OS, and picks a matching config. On Windows it runs Spectrum locally. On macOS it opens an SSH connection to the Windows box and dispatches the batch there — connection-multiplexed to stay fast, with results pulled back over SSH and, later, Dropbox acting as a shared filesystem so files propagate on their own. The portfolio owner set up their side with a short OpenSSH and key walkthrough I wrote into the docs. From their seat it was one command; the Windows box did the 24-to-48 hour job and the outputs appeared on their Mac.

What I owned

• The full pipeline — templating, PJNZ editing, extraction, and post-processing — and the market-dynamics rule engine.
• The cross-machine architecture: OS-aware config, SSH dispatch with connection multiplexing, and the Dropbox shared-filesystem fallback.
• The compute box itself — built, tuned, and parallelized for many-core batch.
• The onboarding: an OpenSSH / key-auth / remote-access guide so a non-engineer could drive it from a Mac.
• The owner-facing documentation site the whole workflow ships with.

What it changes

Modeling teams routinely hit this wall: the tool is platform-locked and slow, and the person who should be driving it can’t run it. The usual answers are a cloud VM or "email me the inputs and I’ll run it." This was neither — the owner kept hands on their own assumptions and launched real runs themselves, while the compute lived somewhere it could actually be fast. The owner ran the portfolio from a Mac, with no Windows workstation and no one between them and the model.