Writing Law enforcement
What the Blue Envelope Got Right
The people who created the Blue Envelope program solved the hard part. Everything I built afterwards is downstream of an idea they got right first.
The Blue Envelope program is one of the best ideas anyone has had in public safety, and I want to start by saying so without qualification.
Here is how it works. A driver with autism keeps a blue envelope in the glovebox holding their license, registration, and a card explaining they may not make eye contact, may not respond to commands the way an officer expects, and may become distressed by raised voices. During a traffic stop, they hand it over. The officer reads it and adjusts.
It costs almost nothing. It requires no software, no procurement, no vendor. It has prevented outcomes nobody will ever count, because the incidents that don’t happen don’t generate reports.
And the hard part was never the envelope. The hard part was the insight, and the people who had it deserve the credit for everything built afterward: that an officer’s split-second read of unusual behavior is the most dangerous moment in an encounter, that the person least able to explain themselves is the one most at risk, and that the entire problem changes if the officer has context before they interpret. Advocates, families, and law enforcement worked that out together, with no budget and no technology, and they were right.
NPS-AID supports the Blue Envelope program. It did not replace it, and it was never meant to. Everything below is about extending that same idea. To more conditions, and to the encounters where an envelope cannot help because there is no glovebox in the room.
Paper has to be present. The envelope works in the vehicle it is in. If the encounter isn’t a traffic stop, there is no glovebox in the interaction at all. A wellness check, a missing person call, a medical emergency, a dispute between neighbors. The idea still applies; the envelope just isn’t there.
Paper arrives at contact, not before it. The officer learns about the disability at the moment they meet the person, after the approach has already been chosen. The most useful moment for that information is while the response is still being decided. For most calls that means at dispatch, minutes earlier.
Paper doesn’t travel. Blue Envelope programs are typically run by a single agency or county, which is exactly the right way to start something. Drive one town over and it may not exist, or may exist with different rules. Disability doesn’t respect jurisdiction, and neither should the record.
Those are not criticisms. They are the specification for what a digital version has to add. They are also the reason the paper version has to keep existing alongside it. A system that requires a database is useless in a county that hasn’t joined one, and an envelope in the glovebox works everywhere, forever, with no uptime requirement.
Why this one
I did not come to this as a vendor looking for a vertical.
I grew up around the special needs community. My brother has Down syndrome, and in my mid-twenties I worked at Bankbridge Development Center in Gloucester County, New Jersey, a school for students with autism, as a teacher’s aide and substitute teacher. You learn things in both places that do not survive translation into a requirements document. That a person who cannot answer a question is not being defiant. That the same sentence delivered two different ways produces two completely different days. That the distance between someone being understood and someone being misread is often one adult knowing one fact in advance.
That is the entire premise of the Blue Envelope, and it is why the program made immediate sense to me when I first saw it. It is also why the limits of paper bothered me enough to do something about them.
Extending it past autism
The Blue Envelope started where the need was clearest and the advocacy was strongest, and starting narrow is how good programs begin. But the underlying insight is not specific to autism at all. Give the responder context before they interpret behavior.
A person with dementia who has wandered from home cannot explain where they live, and may become frightened by the uniform trying to help. Someone mid-stroke can look intoxicated. A person having a diabetic emergency can present as combative. A deaf man who does not respond to shouted commands is not refusing them. Someone with PTSD may react to a raised voice in ways that escalate a situation nobody wanted escalated.
Every one of those is the same failure with a different label: a responder reading behavior without the one piece of context that would change their read.
So NPS-AID covers what the encounter actually requires rather than what one diagnosis needs. Dementia and Alzheimer’s. Autism and Asperger syndrome. Developmental and intellectual disabilities. Mobility issues, paralysis and stroke. Hearing, vision, and speech deficits. Mental health conditions and PTSD. Oxygen dependency, dialysis dependency, Guillain-Barré, CIDP. Life-threatening allergies.
Nobody assembled that list to win a feature comparison. It is just where you end up once you take the Blue Envelope’s premise seriously and follow it to everyone it applies to.
My brother is on that list, under developmental and intellectual disabilities. So is somebody else’s father with Alzheimer’s, and somebody else’s daughter with epilepsy. That is why it is national and free. No family should have to hope their county happened to start a program.
What the software has to do that paper cannot
The instinct is to build a database of disabled people and give police access to it. That instinct is wrong, and getting it wrong would be worse than doing nothing.
The design constraint that matters is this: the participant has to own the record. Not the agency, not the vendor, not the state. Individuals and caregivers enter their own information, control what it contains, and update it from anywhere at any time. If a family decides the record should say less, it says less. If they want it gone, it goes.
That single constraint rules out most of the architectures you would otherwise reach for. You cannot treat it as a law enforcement database with a public-facing form bolted on, because then the agency owns the data and the incentives invert immediately. It has to be a participant-owned record that agencies are granted narrow, auditable access to. That is a much harder system to build, and it is the only version that deserves to exist.
The second constraint is that the information has to be actionable, not merely descriptive. “Has autism” tells an officer almost nothing at 2am. What helps is specific and practical: how this person communicates, what escalates them, what calms them, whether they are likely to run, whether they are non-verbal under stress, who to call, what they look like, and what medical facts could turn a routine encounter into an emergency. Emergency contacts, physical descriptors, current photographs, communication considerations, de-escalation guidance, medical and behavioral alerts.
A registry answers who. This has to answer what do I do, which turns out to be a completely different data model.
Why it has to reach dispatch
If the information surfaces when the officer arrives, it is already late. It needs to reach the person deciding how to respond, at the moment they are deciding.
That means integrating with Computer-Aided Dispatch, the system that already sits between a call for service and the units that answer it. When a call involves a registered participant, dispatch is alerted that information exists, and the responding unit can be briefed before they are on scene. Nothing about the officer’s workflow changes. No new app to open, no second screen, no training program to roll out across a department that is already short-staffed.
I am not the only one who landed here, and I would rather cite someone with a badge than argue it myself. In Police Chief, the IACP’s own journal, Chief James J. Gerace of Colonie, New York and Todd H. Weiss of the Capital Region Crime Analysis Center wrote about exactly this problem. Their department had been distributing vulnerable person information the traditional way, at shift briefings, hoping it reached the officers who might need it. Their finding:
“Without personal experience to reinforce those neural pathways, however, this valuable information would often be forgotten by most personnel within weeks of the briefing.”
So they stopped relying on memory:
“Instead of relying upon individual officer memory retention, the police department integrated the vulnerable person registry information into a system the personnel use every day—computer-aided dispatch or CAD.”
That is the whole argument, made by a chief of police rather than a vendor. Information that depends on someone remembering a briefing from three weeks ago is not a system. It is a hope. The only place the information reliably survives is the tool they already have open.
This is also the slowest part, and I want to be precise about it rather than round it up. NPS-AID now has participants in more than 40 states. Enrollment is the easy half, because families sign up the moment they hear it exists. Full CAD and 911 integration is live in one county: Cumberland County, New Jersey. That is the first, and it took years.
The gap between those two numbers is the actual story of GovTech. Building the integration was months. Getting one county to adopt it meant procurement, legal review, a CAD vendor willing to cooperate, dispatch supervisors who had to retrain staff, and a county government persuaded to move first on something no peer had done. Every one of those is a person, not a ticket.
This is the part that is unglamorous and decisive. A better interface does not help if it is an interface nobody opens. The integration has to meet the workflow that already exists, which means the work is mostly in the seams. CAD interfaces, PSAP APIs, secure data access paths, and the access controls that make any of it defensible.
Why cross-jurisdiction is the whole point
A registry that stops at a boundary solves the problem for people who never leave. Everyone else is unprotected precisely when they are furthest from home and least able to explain themselves. Anyone who travels, commutes, visits family, or has an emergency one county over.
Building it nationally was never an ambition about scale. It was the requirement from the first day. A participant adds their information once and any authorized agency can access it, regardless of where that person happens to be. That is only possible if the system is designed cross-jurisdictionally from the first line of code, because retrofitting national access onto county-scoped data models is not a migration, it is a rewrite.
So the architecture is national from the outset and the deployment is county by county. Those are different clocks, and conflating them is how people end up overstating what a system does. The registry is national. The dispatch integration is one county and counting.
What this generalizes to
I have spent a long time building for law enforcement, and the pattern repeats: the paper process is almost never stupid. It encodes real institutional knowledge, it was designed by people closer to the problem than any vendor, and it survived because it works. What it cannot do is arrive early, travel, or scale.
The mistake technologists make is treating the paper process as the problem to be disrupted. It isn’t. It is the specification, written by the people who understood the problem first. The job is to keep everything the paper version got right, the consent and the dignity and the participant’s control over their own story, and fix only what the medium made impossible.
Get that backwards and you build something technically superior that nobody adopts, which is the ordinary way GovTech dies. Get it right and the paper version keeps working in every county you haven’t reached yet, which is most of them.