FGDC makes address identity more than a portal text field

An address carries authority, structure, and purpose

FGDC's objectives reach beyond formatting a mailing label. The standard describes elements that compose an address, classifications for different address types, attributes such as identifiers and coordinates, a local address reference system, quality tests, and exchange models. It also recognizes that different business purposes and sources can require different record complexity.

For permitting, the immediate consequence is that applicant-entered text should not silently become the authoritative property identity. The system should retain the submitted value, normalized components, source, address authority, address identifier, aliases, coordinates where used, quality result, correction history, and the relationships to parcels, structures, projects, service areas, and jurisdiction.

Address, parcel, structure, and jurisdiction remain separate

A postal address can help locate a place without determining parcel ownership, legal description, structure identity, municipal boundary, zoning district, flood status, utility service, or permitting authority. Those objects may come from different official systems and change on different schedules. One successful geocode cannot reconcile them.

A civic platform should represent those relationships explicitly and preserve conflicts. When two sources disagree, the workflow needs the observation dates, authoritative owner for each object, review role, temporary treatment, affected applications or inspections, and eventual correction. A cleaner display is not evidence that the underlying public records agree.

The implementation test follows a change across open records

Start with one address used by an application, parcel, structure, inspection, fee, notice, and public-status page. Change a street name, unit, alias, coordinate, or assignment. The demonstration should show which authoritative record changed, which relationships were affected, which historical documents remain unchanged, and which open workflows require review.

Then export and re-import the record through an integration. The exchange should preserve identifiers, element meaning, source, quality state, effective period, corrections, and rejected values without flattening everything back into one string. Migration counts alone do not establish that people can retrieve the same property and decision history.

The standard does not decide a permit location

FGDC provides a technical and administrative address-data framework. It does not establish that an address exists in a local authoritative system, corresponds to a legal parcel or occupied structure, lies within a jurisdiction, or is sufficient for zoning, code, emergency, service, inspection, or permit decisions.

Civic Permit Review uses the standard to test data provenance and exchange. Local law, address authority, land records, GIS, adopted policy, agency practice, and qualified staff determine the controlling record for each civic function. Software can preserve those decisions; it cannot assume them from a standardized address.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Civic Permit Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.