By Brian Brady, COO and VP of Business Development, Gistic Research, Inc.
The report arrives as a spreadsheet. A hundred and fifty rows, a feature class per row, a count of anomalies, a column of yeses under “Critical,” and a single number at the top: 82 percent compliant. Somebody has to turn that into a work plan by the next provisioning cycle.
I’ve read a lot of these reports with a lot of coordinators, and the same thing happens every time. The count looks enormous, the rule names sound like they were written by a database, and the number at the top gets quoted to the board as if it meant something.
Then the fixes get made in whatever order the spreadsheet happens to be sorted, and the next cycle’s report comes back with most of the same rows.
This article is the walk-through I wish came stapled to the report. It explains what the rule names actually check, which NENA-STA-006.3 fields and relationships they map to, why the counts can be misleading, and the order in which to work them so the same rows don’t keep coming back.
One thing first. Whether the report comes from your state program, your NGCS provider’s provisioning check, or a validation tool, it’s generally evaluating how well your data satisfies the NENA NG9-1-1 GIS Data Model (NENA-STA-006.3-2026) and applicable provisioning requirements, including those in NENA-STA-005. The names and specific checks can differ between tools, and not every provider applies the same validation rules.
The report, decoded
Most findings on a discrepancy report can be organized into five families. Once you can sort a row into its family, you’ll have a better idea of what it’s checking, roughly how hard it’ll be to fix, and where it belongs in the order of work.
1. Boundary containment
Rule names you may see: “Extends Beyond Provisioning Boundary” on the PSAP, fire, law and EMS layers.
What it checks: Whether emergency service boundary polygons fall within the provisioning boundary, the polygon that defines the geographic area you’re responsible for provisioning to the NGCS. In NENA-STA-006.3, this involves the relationship between the ProvisioningPolygon layer and the service boundary layers (PsapPolygon, PolicePolygon, FirePolygon, EmsPolygon).
Why the count misleads: On one report, 30 of 31 fire polygons were flagged. That didn’t necessarily mean there were 30 bad fire districts. The provisioning boundary had been drawn slightly inside the county line, so polygons touching that edge were flagged. Correcting the provisioning boundary to match the agreed area of responsibility could resolve those findings without changing the individual fire districts.
Why it matters: Data extending beyond the designated provisioning area can create problems during NGCS provisioning. These findings can affect routing-related datasets and should be addressed early.
2. Boundary topology
Rule names: “Gap,” “Overlap,” “is Multipart,” “Island,” “is Multipart and an Island.”
What it checks: Whether polygons within a service boundary layer provide the required coverage without unintended gaps or overlaps. NENA-STA-005 addresses the detection and reporting of gaps and overlaps affecting ECRF and LVF service coverage.
Multipart and island findings identify geometry that may require additional review. They’re not necessarily errors in every circumstance. Some service areas are legitimately disconnected, and some apparent gaps may represent areas where a particular service doesn’t exist. The important distinction is whether the geometry accurately represents the intended service coverage and satisfies the applicable provisioning requirements.
Why the count misleads: A single misaligned shared boundary can produce multiple findings, including gaps and overlaps along different portions of the same edge. Correcting the underlying boundary alignment may resolve several discrepancies at once.
Why it matters: A caller located in an unintended gap may not match the expected service boundary. A caller in an overlap may match more than one. Depending on the NGCS implementation, these conditions can introduce routing ambiguity, require additional processing, or trigger default routing procedures.
3. Centerline topology
Rule names: “Does Not Break at Boundary,” “Digitized Direction,” “Address Range Overlap.”
What it checks: Road centerline geometry, segmentation, digitized direction, and address ranges.
Depending on the applicable validation rules, centerlines may need to be split where they cross certain administrative or service boundaries so their attributes correctly represent each jurisdiction or service area.
As a general best practice, centerlines should be digitized in the direction of increasing address numbers, although exceptions exist. Address ranges should also be checked for unintended overlaps with other segments of the same street.
These checks involve the RoadCenterLine layer’s geometry and range fields: FromAddr_L, ToAddr_L, FromAddr_R and ToAddr_R.
Why the count misleads: “Does Not Break at Boundary” produced 1,669 findings on 6,634 segments in the report I’m looking at. That’s roughly a quarter of the road network.
It’s also one of the more mechanical types of correction. Where a split is required, the centerline can be divided at the boundary crossing, with the appropriate attributes preserved or recalculated for each new segment.
The count is large because the rule identifies every occurrence, not necessarily because each occurrence represents a difficult correction.
Why it matters: An unsplit centerline crossing a jurisdictional boundary can carry attributes that don’t correctly reflect both sides of that boundary. Overlapping address ranges can also create ambiguity when matching civic locations to road segments.
Both conditions can affect location validation and the accuracy of data used to support emergency call routing.
4. Required attribution
Rule names: “State Field Missing Attribution,” “Incorporated Municipality and Unincorporated Community is Blank or NULL,” “ES_NGUID Field Missing Attribution,” “ES_NGUID is Not Unique,” “Date Update Field Missing Attribution,” “Discrepancy Agency ID Field Missing Attribution,” “Display Name is Blank or NULL,” “Service URN is Blank or NULL.”
What it checks: Whether the fields required by the applicable NENA data model and provisioning rules contain valid values.
The NGUID, or NENA Globally Unique ID, identifies individual records and must be populated and unique as required by the data model. Other fields, including the discrepancy agency (DiscrpAgID) and last-update date (DateUpdate), support data maintenance and discrepancy resolution.
Service boundaries include attributes such as the display name (DsplayName) and service URN (ServiceURN), which identifies the service associated with the boundary.
Road centerlines and address points also contain administrative place-name fields, represented in the current NENA data model through the A1–A5 structure.
Check the version first. NENA-STA-006.3-2026 introduced changes to the GIS data model, including the use of A1–A5 administrative fields and changes to the attribution required on individual layers.
A report that flags fields that aren’t part of the newer schema may still be evaluating data against an earlier version. That isn’t necessarily wrong if your state or NGCS provider still requires that version, but it’s important to understand which requirements you’re being evaluated against.
Why the count misleads: The report I’m looking at contains 8,999 community-field findings across 6,634 road centerlines. That looks catastrophic, but a single missing or improperly populated attribute can generate thousands of findings, particularly when the field is evaluated separately for the left and right sides of each road.
Similarly, missing state or administrative values across an entire feature class can generate a large number of findings that may be corrected through a relatively simple, controlled attribution update.
These rows can dominate the anomaly count without representing an equivalent amount of corrective work.
Why it matters: Not all attribution findings have the same operational consequences. Some may be straightforward data maintenance issues, while others, including missing or duplicate identifiers and invalid routing-related attributes, can prevent records from being accepted or correctly maintained during provisioning.
5. Legacy synchronization
Rule names: “ALI Not Reflected in AP,” “ALI Not Reflected in RCL,” “MSAG Not Reflected in RCL,” “MSAG Range Incomplete,” “ALI Address Number Invalid.”
What it checks: Whether the legacy ALI database and MSAG records can be reconciled with GIS address points and road centerlines.
Many states use a 98 percent synchronization benchmark during the transition to NG9-1-1, although the specific requirements and methods of measurement can vary.
Why the count misleads: On the report I’m looking at, these rows are all N/A because no ALI or MSAG extract was supplied.
That means the 82 percent figure at the top was calculated without evaluating this category of synchronization. The number isn’t necessarily wrong, but it doesn’t represent an assessment of every aspect of transition readiness.
Why it matters: During the transition, agencies may need to maintain consistency between their legacy addressing databases and the GIS data being prepared for NG9-1-1.
Once an agency has fully transitioned and no longer depends on those legacy systems, the synchronization requirements may change or eventually be retired.
That’s one reason not to build your entire long-term GIS maintenance workflow around legacy synchronization.
Why 82 percent isn’t a readiness number
The percentage at the top of the report may combine findings from several different categories into a single figure, depending on how the reporting system calculates compliance.
A missing state abbreviation on an EMS polygon and an overlap between two PSAP boundaries might each appear as a single anomaly. One may be a straightforward attribution correction. The other could affect emergency service coverage.
The operational significance isn’t the same.
The report may also tell you very little about the edge you share with your neighbor.
If the validation was performed against your data alone, your PSAP boundary could pass every local check and still fail to align with the neighboring county’s boundary.
That condition may only become apparent when the two datasets are evaluated together during regional aggregation, cross-jurisdictional validation, or NGCS provisioning.
And the percentage may have been calculated without evaluating categories your state considers important. Legacy synchronization rows marked N/A aren’t the same as successful checks.
So the useful interpretation of a compliance percentage is that it tells you how well your data satisfies the particular checks included in that report, using whatever scoring methodology the report applies.
It’s useful for tracking progress from one validation cycle to the next, provided the rules and methodology remain consistent.
It isn’t, by itself, a reliable measure of whether emergency calls will route correctly.
The better question is the one that matters operationally: Do the routing-related GIS layers provide accurate, consistent service coverage, contain the necessary attributes and identifiers, and align with neighboring jurisdictions?
If the answer is yes, a lower percentage may largely reflect outstanding attribution and data maintenance issues.
If the answer is no, a high percentage can provide a false sense of readiness.
The order to work the report
The spreadsheet may be sorted alphabetically by layer. Don’t work it that way.
The datasets and validation rules depend on one another, and correcting them out of order can create additional findings or require work to be repeated.
1. Provisioning boundary first.
This defines the geographic area you’re responsible for provisioning, and other datasets are evaluated in relation to it.
Make sure it aligns with the authoritative or mutually agreed boundary for that area before correcting the dependent layers.
In many cases, this alone can resolve a large number of “Extends Beyond” findings.
2. Service boundaries next: PSAP, then fire, law and EMS.
Resolve unintended gaps and overlaps by correcting the underlying shared boundaries rather than simply moving one side until the error disappears.
Review multipart geometries and islands to determine whether they represent legitimate service areas or actual discrepancies.
Confirm the required identifiers, display names, and service URNs.
Where a boundary is shared with another agency, this is the step that requires coordination. It’s also the step that can stretch timelines when neighboring agencies aren’t participating.
3. Road centerlines.
Split centerlines at required boundary crossings, correct digitized direction where appropriate, and resolve unintended address range overlaps.
Make sure the resulting segments retain the correct attribution and address ranges.
Do this after the boundaries are corrected because those boundaries determine where many of the splits need to occur.
4. Address points.
Verify that each address point is correctly located, associated with the appropriate road centerline where applicable, and attributed to the proper administrative and service areas.
Check address numbers, street names, ranges, and other location attributes for consistency.
Address points depend on the quality of both the boundaries and road network, which is why they come after those geometry corrections.
5. Attribution sweep.
Fill missing administrative values, agency identifiers, dates, and other required attributes across the appropriate layers.
This can close a large number of findings with relatively little work.
It’s also why I wouldn’t make it the first priority. Improving the compliance percentage by filling empty fields doesn’t necessarily resolve the geometry and coverage issues that matter most to emergency call routing.
6. Legacy synchronization, if your state still requires it.
Reconcile MSAG ranges and ALI records against the corrected road centerlines and address points, rather than working from datasets you know will be changing.
Boundaries, then roads, then address points, followed by the remaining attribution and synchronization work.
Readers of the six-month plan will recognize the sequence. It’s the same basic approach, applied to a single discrepancy report instead of an entire program.
Why the same rows come back
A discrepancy report is a snapshot of the data on the day it was generated.
By the time it reaches the coordinator, the data may already have changed.
Corrections are often made in a desktop GIS editor, the updated layers are exported and resubmitted, and another validation report arrives days or weeks later.
Anything changed in the meantime, including problems introduced by the corrections themselves, can appear as a new finding.
That cycle is one reason so many agencies feel they’re never finished.
The report isn’t necessarily the problem. The gap between where validation occurs and where the data is maintained is a big part of the problem.
GIVE was designed to help close that gap by bringing GIS integration, validation, and editing together in a collaborative data environment.
Instead of treating validation as a separate process that occurs only after data has been exported and submitted, GIVE allows agencies to identify and work through discrepancies within their editing and quality assurance workflows.
Boundary containment problems, gaps and overlaps, and road centerlines that cross administrative boundaries without the required segmentation can be identified and addressed through GIVE’s validation and editing tools.
Required attribution can be managed through configured domains, defaults, and editing controls, reducing the need to repeatedly correct the same missing values across large datasets.
Unique identifiers can be generated and validated as records are created or maintained, helping prevent duplication and other identifier-related discrepancies.
GIVE also incorporates PACT rule classifications to help agencies distinguish different types of validation findings and prioritize their corrective work.
And because neighboring agency data can be incorporated into the same collaborative environment, agencies can examine shared boundaries and identify inconsistencies that might not be apparent when working with their own data alone.
None of this makes the state’s or NGCS provider’s validation report unnecessary.
It changes how agencies prepare for that report.
Instead of waiting until the next provisioning cycle to discover problems, agencies can identify and address many discrepancies as part of their normal data maintenance process.
The objective isn’t simply to reduce the number of findings. It’s to reduce the number of recurring problems and the amount of work required to correct them.
If you’ve got a discrepancy report in hand and want a second opinion on what it’s really telling you, send it over.
We’ve read a lot of them.
Terms on your report
The GIVE glossary includes explanations of common NG9-1-1 GIS discrepancy report terminology and related NENA data model fields.
Keep it open next to your report. It can help translate unfamiliar validation terminology into something useful when you’re trying to determine what needs correcting and why.
#NG911 #GIS #PublicSafety #GISDataQuality #GISValidation
Brian Brady is COO and VP of Business Development at Gistic Research, Inc. Gistic has been developing collaborative GIS and data-quality solutions for public agencies since 2005. Brian writes regularly about NG9-1-1 GIS standards, data quality, collaboration, and the practical realities of moving from legacy GIS workflows into continuously maintained NG9-1-1 environments.