You can enjoy an AUDIO Version Here
Everybody loves the vision.
Smart buildings that can contribute validated indoor maps. Hospitals that can push hazard zones and access routes. Campuses that can deliver real-time status from security systems, cameras, and building controls—so responders roll in informed instead of blind.
It’s a great future.
It’s also the point where we usually trip over the same pothole: we obsess over the data… and skip the humans who have to own it. And ownership, whether we like it or not, is a security issue.
“Who owns this layer?” isn’t a project question. It’s a security question.
In public safety, “ownership” often gets treated like a project management checkbox. The kind of thing you throw into a chart, highlight in yellow during a meeting, and then never truly resolve because everyone has a day job.
In security, ownership is everything.
Because if nobody owns a layer, nobody maintains it. If nobody maintains it, it becomes stale. If it becomes stale, users work around it. If users work around it, the system becomes irrelevant. And once the system becomes irrelevant, it becomes easier to compromise—because nobody’s watching it anymore.
That’s not fearmongering. That’s just how quiet failures happen.
So here’s the uncomfortable truth: every critical GIS layer needs an accountable human owner. Not “the GIS team.” Not “Facilities.” Not “IT.” A named role with defined expectations—someone who can answer, in plain language, “Yes, this is current” or “No, it’s due for validation.”
And this is where I’ll ruin the “technology is cool” vibe one more time:
Security isn’t just firewalls and passwords. It’s governance that still functions on a Tuesday afternoon.
Not during a conference. Not during an audit. Tuesday—when the phone is ringing, staffing is short, and the priorities are flying around like a swarm of bees. If your governance only works when everyone is calm and well-rested, it doesn’t work.
Bring Your Own Building Intelligence: I love it… but the pipeline is the danger
Now let’s talk about the shiny thing: “Bring your own building intelligence.”
I genuinely love the concept. Buildings contributing validated indoor maps, hazard information, access routes, and even real-time status is exactly where NG911 needs to go if we want “end-to-end” to actually mean end-to-end.
But here’s the deal: the more dynamic the data, the more dangerous the pipeline.
Static data is already hard to keep correct. Real-time building inputs introduce a new level of risk because now we’re talking about frequent updates, more systems involved, more vendors, more integrations, and more opportunities for compromise. The moment you start accepting feeds from IoT, OT, building management systems, access control, and camera analytics, you’ve expanded the attack surface from a manageable yard into an entire neighborhood.
So if an enterprise wants to contribute dynamic data, the standard can’t be “send it over and we’ll figure it out.” It has to be: prove identity, authenticate correctly, limit what can be changed, and support rapid rollback.
Rollback is the point most people skip, and it’s the one I care about most. Because if a bad update breaks something at 2:00 AM, the response can’t be:
“We’ll fix it in the morning.”
Public safety doesn’t get “in the morning.” If enterprise-contributed data is going to influence emergency decisions, versioning, auditability, then rapid restore needs to be designed in from day one. Not added after the first failure.
Budget constraints are real. That doesn’t mean “do nothing” is the answer.
Let’s talk enterprise and commercial reality: budgets are tight.
Hospitals aren’t swimming in extra dollars. Universities are balancing safety with costs. Warehouses, hotels, manufacturing, senior living—most facilities are not excited about adding “public safety data engineering” to their annual budget plans.
Here’s the good news: you don’t have to start with perfection. In fact, the best starting point is usually not “create brand new data.” It’s this:
Validate what you already have. Then publish it responsibly.
Most organizations already have floor plans, facility maps, evacuation routes, access points, and hazard inventories. The problem is the assets are scattered, outdated, or locked in systems never intended to support emergency response workflows. So instead of trying to build a futuristic digital twin overnight, take what exists and do the one step that turns it into operational value: make it trustworthy.
Assign ownership. Establish an update and validation cadence. Define what happens when a record is wrong or suspicious. Then publish the data into a structure designed for emergency use—not just internal convenience.
And yes, I’ll be slightly snarky here: a beautifully detailed floor plan that’s wrong is worse than a basic one that’s right—because responders will trust it. Trust is expensive to earn and easy to burn.
Where this data should live: NG911 Additional Data Repositories (ADRs)
If we want enterprise and commercial facilities contributing data to NG911 in a way that scales, the architecture has to mature. We need a sane place for this information to live—securely, versioned, governed, and retrievable when it matters.
That’s the role of NG911 ADRs: Additional Data Repositories.
Not email attachments. Not “call this number and ask for Bob.” Not a shared drive folder with three different versions of the same map.
ADRs are where validated additional data can be stored and managed so it can be delivered based on incident context and destination—especially when the incident crosses jurisdictions or requires interop with multiple systems. And ADRs can exist in different places depending on the enterprise’s maturity:
Some organizations can host ADR capability internally. That can work—if they can operate it with real security discipline, high availability, auditing, and resilience. But for many enterprises, it will make more sense to publish through a commercial provider that can handle the heavy lifting: identity proofing, credentialing, authentication, policy controls, format normalization, and secure delivery. That normalization piece matters more than people realize, because a destination PSAP isn’t a generic endpoint. Different PSAPs have different workflows, tools, and ingestion capabilities. A provider that can transform enterprise data into compliant formats based on where the call is going eliminates a massive amount of friction.
Why public safety can’t manage thousands of bespoke secure feeds
Here’s the scaling problem in plain English:
Public safety does not have the manpower to credential and manage secure data feeds for thousands of businesses one-by-one. Even if every enterprise had good intentions, you’d still be asking PSAPs and ECCs to become identity proofing shops, certificate managers, integration engineers, access control administrators, and 24/7 troubleshooting teams. That’s not NG911 progress. That’s operational collapse. So we need a middle layer that can handle this at scale, without dumping complexity onto the people answering the calls.
The logical middle: carriers and ESInet ecosystem providers
This is where carrier-adjacent and ESInet ecosystem entities can play a major role.
Organizations already building and operating ESInets across the U.S.—and those deeply involved in routing and managed services—are positioned in the “end-to-end connectivity” layer. They understand routing. They understand operational availability. They understand scaling secure onboarding and support.
That makes them a logical place to broker identity proofing, credentialing, policy enforcement, data normalization, monitoring, and rollback capability—so PSAPs don’t have to manage thousands of one-off trust relationships.
And there’s another benefit: this creates an open architecture where new providers—especially in the camera and AI space—have a practical way to extend their services into public safety without forcing every PSAP to integrate “yet another platform.”
Innovation becomes possible without creating chaos. The bottom line: this is how we get end-to-end NG911. The end goal is simple to say and hard to deliver:
When an emergency originates in an enterprise environment, the PSAP should receive the event plus trusted, relevant additional data—quickly, securely, and in a way that fits their workflow.
We don’t get there by hoping every enterprise is perfect.
We get there with an operating model that scales: explicit ownership, Tuesday-afternoon governance, strong authentication with no shared logins, defined limits on what can change, and rollback capability that respects the reality of a 2:00 AM incident.
Do that, and enterprise data becomes a force multiplier instead of a risk surface.
And that’s the path to the real promise of NG911: a true end-to-end experience, where the right information meets the right people at the right time—without heroics, without duct tape, and without emailing PDFs like it’s 2007.
If you find my blogs informative, I invite you to follow me on X @Fletch911. You can also follow my profiles on LinkedIN and Facebook and catch up on all my blogs at https://Fletch.tv. AND BE SURE TO CHECK OUT MY LATEST PROJECT TiPS: Today on Public Safety @ http://911TiPS.com
Thanks for spending time with me; I look forward to next time. Stay safe and take care.
Follow me on Twitter/X @Fletch911
See my profiles on LinkedIN and Facebook
Check out my Blogs on: Fletch and http://911TiPS.com
© 2026, All Rights Reserved, Fletch 911, LLC
Reuse and quote permitted with attribution and URL