Program · Veteran Regional Stability Index
The Veteran Regional Stability Index, run as a program.
Eight federal data sources bound into one county-grain composite across five domains of veteran regional outcome — built on a partial-publish contract, so coverage ratchets up as schemas stabilize rather than waiting for perfection. This page is the program lens on VRSI; the analytical depth is in the case study.
Federal Sources
Eight — ACS, BLS, HUD, BEA, VA, IRS, HRSA, DOL. All public.
Structure
Twenty KPIs · five domains · one county-grain composite
Release Contract
Partial-publish — coverage ladder 10/20 live, 13/20 next, 17/20 target
Test Suite
1,008 passing · 0 regressions · CI-gated
The Program in Brief
A composite that stays honest about what it knows.
Most public reporting on veteran outcomes stops at the state level. The veteran in a rural Tennessee county does not see the same labor market, cost-burden structure, or clinical access as the veteran in Nashville — and yet state-level dashboards fold both into a single number. The Veteran Regional Stability Index closes that gap. It pulls from eight federal sources that already publish at the county grain, binds them into one reproducible composite across five domains, and surfaces the result at the level where employment programs, housing assistance, and benefits infrastructure are actually administered.
What makes VRSI a program rather than a one-off build is the contract it runs under. The composite does not invent data; it disciplines the existing public record. Every input is a public federal series, every transformation is logged and versioned, and the release is governed by a rule decided in advance: ship the version you can defend today, flag what you cannot, and let coverage ratchet up. That rule — the partial-publish contract — is the program decision this page is about.
Run as a Program
Three decisions that made it a program.
A seed universe, then scale
Phase 1–3 instrumented a twenty-one-county seed universe before scaling to all 3,143 counties. The seed is small enough to validate by hand and large enough to exercise every join — the same discipline as proving a pipeline on a sample before the full run.
Equal weighting, on purpose
Each KPI is min-max scaled and equally weighted within its domain; the five domains combine at equal twenty-percent weights. Unequal weights imply a prior about which domain matters most — and for a first-release composite on a small seed, that prior is not earned. Equal weighting is the defensible null; users who disagree can reweight from the per-domain subscores in the release manifest.
A coverage ladder as the release plan
The program does not wait for all twenty KPIs to be perfect. It publishes the ten it can defend, names the gap, and treats the climb to thirteen and then seventeen as a visible, scheduled release plan — not a private to-do list.
Risk Managed in Flight
When a federal source breaks, the program does not.
Eight federal sources on eight cadences and eight schema conventions guarantee that something will break mid-pull. The program's answer is the partial-publish contract: when a source breaks schema or rate-limits, the KPI it feeds drops to a disclosed proxy flag rather than falsifying a number or blocking the entire release. The risk — a broken upstream source — is not eliminated; it is contained, disclosed, and survivable.
A concrete instance: the VA facility directory was being pulled from a Socrata CSV endpoint that began returning a 404. Rather than let one dead endpoint stall a health-and-clinical-access KPI, the pull was rerouted to the authenticated VA Facilities API — a paginated JSON service — with the integration logged as a versioned build step. The same build cycle widened the column matchers for Socrata-style sources and added a Facilities API fallback, work expected to lift the next run from ten covered KPIs to thirteen. The fix is in the build log; the coverage ladder shows its effect.
| Run | Coverage | What changed | Status |
|---|---|---|---|
| Day 2.0 | 10 / 20 KPIs | Partial-publish floor — ship what is defensible, flag the rest | Live |
| Day 2.1 | 13 / 20 expected | Widened Socrata-style column matchers; Facilities API reroute and fallback | Built |
| Target | 17 / 20 | Remaining KPIs at stable fidelity as schemas settle | Planned |
How this program sits in the section
VRSI is presented here through the program lens — phased execution, a scope contract decided in advance, and risk contained in flight. It does not yet carry the full chartered artifact set that the Workforce Stability program does: a standalone charter, a formal risk register, an executive deck. Those are the anchor program's artifacts.
What VRSI does carry is the same operating discipline, evidenced in its own way — a versioned build log, a CI-gated test suite of 1,008 checks with zero regressions, and a release contract published on the page itself. The full methodology, weighting, and every fragility boundary live in the case study.
Go Deeper
The full VRSI case study
The case study carries the analytical depth this page summarizes — all twenty KPIs and their five domains, the composite construction step by step, the per-domain signal, the cross-domain insights, the risks and fragility boundaries disclosed up front, three tiers of recommendations, and the roadmap.
Analytics Case Study · Flagship II
A county-grain composite of veteran regional outcomes, built around partial-publish discipline and proxy-flagging. Methodology, weighting, and every fragility boundary disclosed on the page.
8
Federal Sources
20
KPIs
5
Domains
Work Together
Discipline that survives a broken source.
A release contract decided in advance, risk contained without falsifying a number, and a coverage ladder readers can see. If your team needs that kind of program discipline, let's talk.