From Afterthought to Core Strategy: Taming QA Exceptions in NG911 GIS

March 11, 2026

There are rules, and there are exceptions to the rules. That is life.

In the rigid world of NG911 GIS maintenance, this reality has historically been an afterthought. You run your validation rules, you get a list of violations, and you start fixing. But what about the “Grandfathered” rule violations that would require major readdressing or re-engineering? The legacy address points result in “sequence” inconsistency because the street centerline was laid out long before modern addressing standards existed. Technically, it’s a violation. Realistically, it’s the ground truth.

Or what about the “Warning” that doesn’t need your attention? A long fishbone that is perfectly legitimate, or an address density that exceeds your pre-configured size, but you don’t want your team tracking that warning count day after day.

In GIVE, we believe that exception management and NG911 GIS maintenance are two sides of the same coin. You cannot have an enterprise-grade QA process without an equally robust way to handle the outliers.

Here is how GIVE transforms exception management from a spreadsheet workaround into a core strategic feature.

Understanding the Why Behind Violation Exceptions

Before you manage an exception, you have to understand it. GIVE categorizes exceptions based on real-world NG911 scenarios:

• Grandfathered: Legacy data that doesn’t meet current specs but is spatially accurate (e.g., that crossing fishbone pattern).
• Legitimate Outliers: Features that are correct but fall outside normal parameters (e.g., a long, valid fishbone or a high-density address block).

Severity Matters: What Can Be Excepted?

Not all rules are created equal, and not all rules should be overridden. In GIVE, every QA code is assigned one of three severity levels:

• Critical
• Warning
• Informational

To maintain data integrity, Critical level rules are only eligible for permanent exceptions. This ensures the backbone of your data remains sacrosanct, even while you manage the nuance.

The Dimensions of an Exception

1. Temporary vs. Permanent Time is a critical factor in exception management. GIVE allows you to tag exceptions based on their lifespan:

• Temporary Exceptions: Perfect for de-cluttering your dashboard. Put non-urgent violations into a temporary exception state so your team can focus on the more pressing violations today, without losing track of the issue for future review.
• Permanent Exceptions: Reserved for truly grandfathered features that will never be “fixed” because they represent real-world conditions.

2. Batch vs. Individual Control Efficiency meets security.

• Individual Exceptions: Users can operate on any exception-eligible violation, flipping it from temporary to permanent status with full audit tracking.
• Batch Exceptions: Need to clean up a batch of known legacy issues quickly? You can batch-except violations, but with a critical safeguard: when batch-excepting critical violations, only temporary exceptions are allowed. This prevents accidental mass suppression of serious errors and potential abuse of the exception mechanism.

UI/UX: Flipping Context Like a Coin

The most powerful feature of an exception management system is how easily you can ignore it when you need to, and use it when you don’t.

In GIVE, switching between Exception Mode and Data Mode is as simple as flipping a coin. The context shifts instantly.

You keep your spatial context. You keep your filters. You just change what you are looking at.

The Bottom Line

In NG911, data quality isn’t just about clean maps; it’s about saving lives through accurate routing. You can’t afford to have your teams bogged down by false positives, but you also can’t afford to ignore the rules.

With GIVE, exception management isn’t an afterthought. It’s a first-class citizen, built to handle the complexity of real-world data.

Ready to flip the switch on smarter QA? Let’s talk about GIVE. #NG911 #GIS #DataQuality #ExceptionManagement #PublicSafety #GIVE #Geospatial