# From spatial SQL to trusted maps: how GeoGridIQ is testing GeoSQL

> See how GeoGridIQ is testing GeoSQL, PostGIS, and map-in-the-loop review to validate spatial evidence before it can influence outage intelligence.

Canonical: https://geogridiq.com/blog/how-geogridiq-uses-geosql-map-in-the-loop/
Author: [Justin St-Laurent](https://geogridiq.com/about-author/), Founder and builder of GeoGridIQ
Published: 2026-07-29
Modified: 2026-07-29
Facts reviewed: 2026-07-29
Next review: 2026-10-29
Status: published
Section: Methods and data quality
Topics: GeoSQL, PostGIS, Geospatial data, Data quality, Map validation, Outage intelligence, Explainable AI

## Pilot in progress

Implementation status: PILOT_IN_PROGRESS

GeoSQL 0.31.0 is installed in an isolated project profile. Staging, numerical validation, self-hosted Dekart map rendering, runtime permission probes, and the governed evidence handoff have not yet produced verified pilot results.

## Article hero

[Diagram of a governed spatial quality-assurance flow from a PostGIS grid through GeoSQL validation and layered map review to a human approval gate; it does not show outage risk.](https://geogridiq.com/static/img/blog/how-geogridiq-uses-geosql-map-in-the-loop/hero.webp)

## Direct answer

GeoGridIQ is testing GeoSQL as an isolated geospatial data-engineering and map-QA assistant. The installed pilot profile can support PostGIS schema discovery, spatial SQL, numerical checks, and an optional map-feedback workflow. The staging database, Dekart map review, and governed evidence handoff have not yet been completed. GeoSQL does not generate forecasts, create labels, train models, or write to GeoGridIQ’s production database.

## Key takeaways

- GeoSQL assists a spatial-data workflow; it is not GeoGridIQ’s outage-prediction model.
- A valid SQL result can still be geographically wrong, so numerical checks and map review belong together.
- The first planned workflow focuses on reviewed Quebec grid and land/water evidence, exceptions, and historical-event geometry.
- Outputs remain evidence until governed review accepts them; the pilot cannot create labels, train or promote models, save risk, or publish forecasts.
- Possible later uses include weather-grid mapping, vegetation provenance, exposure QA, event geometry, and broader Canadian source-gap review.

## Why geography can fail even when a query runs

**The problem**

Database success is a narrow result: the syntax parsed, the referenced objects existed, and the engine returned rows. It does not establish that a coordinate reference system was interpreted correctly, that a municipality identifier joined to the intended region, or that a point represents anything more than a location. PostGIS distinguishes planar geometry from geodetic geography, and measurements inherit those choices. A query can therefore be computationally valid while its real-world meaning is wrong. Sources: [PostGIS Project - PostGIS 3.6 spatial data management](https://postgis.net/docs/manual-3.6/en/using_postgis_dbmanagement.html); [PostGIS Project - PostGIS 3.6 spatial queries](https://postgis.net/docs/manual-3.6/en/using_postgis_query.html).

Coastlines and coverage gaps make the problem especially visible. A partial coastal cell can be classified as entirely land, a water-only cell can inherit nearby evidence, overlaps can double-count area, and missing coverage can be silently converted to zero. Generalized boundaries or mixed source vintages add different failure modes. If location, coverage, time, or geometry is wrong, an upstream feature, evaluation set, or interpretation may be contaminated before a model sees it; that does not mean every defect changes a forecast. Sources: [PostGIS Project - ST_IsValid](https://postgis.net/docs/manual-3.6/en/ST_IsValid.html).

### Visual: Why matching row counts are not enough

Evidence class: Conceptual Illustration

A conceptual comparison shows how identical counts can conceal displaced geometry and why both numeric and visual controls are needed.

Caption: Conceptual illustration with invented counts; it is not GeoGridIQ pilot or production output.

| Review signal | Plausible but wrong | Corrected evidence state |
| --- | --- | --- |
| Row count | 240 rows returned | 240 rows returned |
| Map position | Grid appears shifted beyond the reviewed boundary | Grid aligns after CRS transformation review |
| Required control | Inspect SRID, extent, and control locations | Record transformation and rerun measures |
| Decision | Hold as unresolved evidence | Eligible for independent review—not automatically accepted |

## What GeoSQL is—and what it is not

**Terminology**

Here, GeoSQL means the open-source agent skill maintained in the dekart-xyz/geosql project. Its documented workflow helps an agent discover metadata, write engine-aware spatial SQL, consider query cost, validate quantities and geometry, and optionally use a Dekart-rendered map for feedback. The project documents PostGIS alongside other supported platforms. GeoGridIQ has installed package metadata version 0.31.0 in an isolated profile, but installation is not evidence that the full workflow has run. Sources: [Dekart XYZ - GeoSQL repository and workflow documentation](https://github.com/dekart-xyz/geosql); [Dekart XYZ - GeoSQL project metadata](https://github.com/dekart-xyz/geosql/blob/main/pyproject.toml); [GeoGridIQ - GeoSQL pilot status and governance audit](https://geogridiq.com/outage-prediction/).

GeoSQL is neither a source of authoritative geography nor a replacement for PostGIS, GIS expertise, or operational review. Dekart is the optional analysis-map harness; it is not GeoGridIQ’s customer-facing map. MapLibre remains a separate product visualization concern. Most importantly, GeoSQL is not an outage model, a service-territory authority, an autonomous production writer, or permission to bypass licences, privacy, temporal lineage, and approval. It accelerates work that qualified people still have to examine. Sources: [Dekart XYZ - GeoSQL repository and workflow documentation](https://github.com/dekart-xyz/geosql); [Dekart - Dekart repository and SQL-map documentation](https://github.com/dekart-xyz/dekart).

### Visual: What each component does

Evidence class: Conceptual Illustration

Five separate roles prevent an analysis assistant or QA map from being mistaken for the production prediction system.

Caption: Conceptual architecture; documented tool capabilities do not prove completion of GeoGridIQ’s pilot.

- Storage + query: PostgreSQL/PostGIS. Stores spatial types and executes spatial queries.
- Agent skill: GeoSQL. Guides discovery, SQL, validation, and optional map feedback.
- QA harness: Dekart. Can render SQL results for analysis review; pilot runtime is not yet validated.
- Product map: MapLibre. Separate GeoGridIQ customer-facing visualization concern.
- Decision gate: GeoGridIQ governance. Determines whether evidence may move downstream.

Visual sources: [Dekart XYZ - GeoSQL repository and workflow documentation](https://github.com/dekart-xyz/geosql); [Dekart - Dekart repository and SQL-map documentation](https://github.com/dekart-xyz/dekart); [PostGIS Project - PostGIS 3.6 spatial data management](https://postgis.net/docs/manual-3.6/en/using_postgis_dbmanagement.html); [GeoGridIQ - GeoSQL pilot status and governance audit](https://geogridiq.com/outage-prediction/).

## GeoGridIQ’s existing spatial foundation remains authoritative

**System boundary**

The pilot is being designed beside GeoGridIQ’s existing spatial and model-governance controls, not as a replacement layer. PostgreSQL/PostGIS can store and query points, lines, polygons, and spatial indexes; GeoGridIQ’s governed workflow separately tracks the role and time of inputs, regional eligibility, and model-release status. A geometry that is useful for display is not automatically suitable for measurement, training, or a legal-territory claim. Sources: [PostGIS Project - PostGIS 3.6 spatial data management](https://postgis.net/docs/manual-3.6/en/using_postgis_dbmanagement.html); [GeoGridIQ - Protected-artifact safety and runtime availability audit](https://geogridiq.com/outage-prediction/).

That separation also protects the public product. A temporary QA map may show simplified, sanitized, or intentionally synthetic geometry so reviewers can find defects. It must not be presented as a live risk surface or silently flow into product mapping. Likewise, improving an upstream spatial evidence package does not reactivate a suspended model, certify a forecast horizon, or publish a prediction. The downstream prediction pipeline keeps its own eligibility, temporal-safety, evaluation, and promotion gates. Sources: [GeoGridIQ - Protected-artifact safety and runtime availability audit](https://geogridiq.com/outage-prediction/). Continue: [How outage prediction works](https://geogridiq.com/blog/how-outage-prediction-works/); [Why forecast accountability matters](https://geogridiq.com/blog/forecast-accountability-outage-prediction/).

## The map-in-the-loop workflow

**Proposed controlled loop**

A controlled run begins with an official or otherwise governed source contract: role, licence, retrieval date, version, URL, and checksum. A reviewed copy is loaded into isolated staging, where the actual schema and coordinate reference system are inspected before SQL is written. Bounded predicates and spatial indexes can reduce candidate pairs before exact spatial tests, while counts, area, length, extent, validity, duplicates, and coverage provide independent numerical signals. Sources: [PostGIS Project - PostGIS 3.6 spatial queries](https://postgis.net/docs/manual-3.6/en/using_postgis_query.html); [Dekart XYZ - GeoSQL repository and workflow documentation](https://github.com/dekart-xyz/geosql).

The same result is then rendered as a review map. A person checks known regions, boundaries, coastlines, exceptions, and event clusters; corrections become versioned transformations rather than undocumented edits. The query and measurements run again, and the package records SQL identity, source identity, metrics, maps, limitations, and unresolved cases. A plausible map cannot replace numerical tests, and clean metrics cannot replace geographic inspection. Both signals must agree before independent governance can consider the evidence. Sources: [Dekart XYZ - GeoSQL repository and workflow documentation](https://github.com/dekart-xyz/geosql); [Dekart - Dekart repository and SQL-map documentation](https://github.com/dekart-xyz/dekart).

### Visual: A bounded map-in-the-loop review

Evidence class: Conceptual Illustration

Each iteration pairs reproducible measurements with map inspection, then stops at a human checkpoint before evidence leaves staging.

Caption: Conceptual workflow based on official tool documentation; GeoGridIQ has not completed this end-to-end pilot loop.

- 01: Discover. Inspect real schema, types, source role, and CRS.
- 02: Query. Write bounded, index-aware spatial SQL.
- 03: Measure. Check count, area, length, extent, validity, and coverage.
- 04: Render. Build a local or self-hosted analysis map.
- 05: Inspect. Review coastlines, boundaries, exceptions, and anomalies.
- 06: Correct. Version the transformation and rerun both checks.
- Gate: Human review. Package, reject, or return unresolved evidence.

Visual sources: [Dekart XYZ - GeoSQL repository and workflow documentation](https://github.com/dekart-xyz/geosql); [PostGIS Project - PostGIS 3.6 spatial queries](https://postgis.net/docs/manual-3.6/en/using_postgis_query.html); [Dekart - Dekart repository and SQL-map documentation](https://github.com/dekart-xyz/dekart).

## What we are testing first

**Pilot in progress**

The first planned controlled workflow focuses on Quebec grid and serviced-land evidence QA. It asks which reviewed cells are wholly or partly inside the governed geography; which portions are land, mixed land and water, open water, or unavailable; and where reviewed distribution-presence evidence or documented exceptions exist. It also asks whether verified historical event points map to expected cells without treating a point as a territory polygon. Sources: [GeoGridIQ - GeoSQL pilot status and governance audit](https://geogridiq.com/outage-prediction/).

This is a prepared test scope, not a completed result. Source-registry and map definitions exist, but the staging run, database validation artifacts, map renders, reviewer decisions, and governed handoff package are absent as of July 29, 2026. Accordingly, this article publishes no whole-cell or partial-cell result counts and makes no official service-territory assertion. Future results should distinguish complete, partial, contradictory, unavailable, and manual-review evidence instead of collapsing unknown coverage into zero. Sources: [GeoGridIQ - GeoSQL pilot status and governance audit](https://geogridiq.com/outage-prediction/).

### Visual: Quebec pilot review layers

Evidence class: Schematic Not Surveyed

A deliberately generalized layer stack explains the planned review questions without showing service territory, private data, or outage risk.

Caption: Schematic, not surveyed. This illustration explains proposed review layers and is not an official service-territory or outage-risk map.

- Layer 1: Reviewed boundary. Governed geographic role and version
- Layer 2: Grid relation. Whole, partial, outside, or unresolved
- Layer 3: Land / water. Land, mixed, water, or unavailable evidence
- Layer 4: Presence + exceptions. Supporting evidence, not legal territory
- Layer 5: Event points. Verified locations checked against expected cells
- State: Review outcome. Complete, partial, contradictory, unavailable, or manual review

Visual sources: [GeoGridIQ - GeoSQL pilot status and governance audit](https://geogridiq.com/outage-prediction/).

## Mistakes a map can help expose

**Conceptual examples**

A coordinate reference system error can displace features offshore even while row counts remain stable. Confusing ST_SetSRID with ST_Transform is one concrete route to that failure: one assigns a reference-system identifier, while the other changes coordinates. A wrong join key can place the expected number of records in unrelated cells. In both cases, the map supplies an anomaly signal, not a diagnosis; the reviewer must inspect the transformation, identifiers, extents, and known control locations. Sources: [PostGIS Project - ST_Transform](https://postgis.net/docs/manual-3.6/en/ST_Transform.html); [PostGIS Project - PostGIS 3.6 spatial queries](https://postgis.net/docs/manual-3.6/en/using_postgis_query.html).

Other mistakes are semantic. A coastal cell can be forced into a single land-or-water category when it should remain partial. A municipality or distributor point can be expanded into an unsupported service polygon. Structural validity checks may accept a well-formed polygon that represents the wrong concept. The examples below are original conceptual mini-maps, not before-and-after production data; each pairs the visible clue with the additional control needed before changing an evidence state. Sources: [PostGIS Project - ST_IsValid](https://postgis.net/docs/manual-3.6/en/ST_IsValid.html).

### Visual: Four errors that can survive a successful query

Evidence class: Conceptual Illustration

Each conceptual card pairs a misleading numerical signal with a map clue and the control needed to resolve it.

Caption: Original conceptual examples; no card represents GeoGridIQ production data or a completed pilot result.

- CRS mismatch: Count looks stable; features shift. Check SRID, transform, extent, and reviewed control locations.
- Wrong join key: Row total looks plausible; cells are unrelated. Audit key uniqueness, unmatched rows, and known-region samples.
- Partial coastal cell: One category hides mixed coverage. Measure intersections and preserve partial or unavailable states.
- Point as territory: A location becomes an unsupported area. Keep evidence roles distinct; require an authoritative territory source.

Visual sources: [PostGIS Project - ST_Transform](https://postgis.net/docs/manual-3.6/en/ST_Transform.html); [PostGIS Project - ST_IsValid](https://postgis.net/docs/manual-3.6/en/ST_IsValid.html).

## How evidence moves toward outage intelligence

**No direct write**

The exploration zone can discover a source, stage a reviewed copy, write SQL, measure coverage, render a map, and document unresolved findings. It cannot confer authority. A human gate separates that work from the governed application zone, where reviewers decide whether the source role is acceptable, geometry and coverage are fit for a stated use, and a candidate feature is eligible. The pilot has no direct write path into GeoGridIQ production data. Sources: [GeoGridIQ - GeoSQL pilot status and governance audit](https://geogridiq.com/outage-prediction/).

If evidence survives that review, separate processes still test temporal leakage, model behaviour, and promotion criteria before trusted predictions could be generated. GeoSQL does not create positive or negative outage labels, select cells for training, train or promote a model, save risk, or release a public forecast. This boundary matters because faster investigation should not become faster propagation of an unsupported geographic assumption. Sources: [GeoGridIQ - Protected-artifact safety and runtime availability audit](https://geogridiq.com/outage-prediction/); [GeoGridIQ - GeoSQL pilot status and governance audit](https://geogridiq.com/outage-prediction/). Continue: [Forecast accountability and temporal safety](https://geogridiq.com/blog/forecast-accountability-outage-prediction/).

### Visual: The human gate between exploration and application

Evidence class: Conceptual Illustration

The pilot can prepare evidence, but only independent review can allow an accepted input to enter later feature and model processes.

Caption: Conceptual governance boundary. The installed pilot has not produced or handed off an accepted evidence package.

- QA: Explore. Discover sources and inspect schemas.
- QA: Stage + validate. Run SQL, measures, maps, and document unknowns.
- STOP: Human approval gate. No direct write; accept, reject, or return evidence.
- Governed: Source + feature review. Check authority, coverage, eligibility, and temporal safety.
- Separate: Model evaluation. Training, testing, and promotion use their own controls.
- Conditional: Prediction release. Only a separately trusted, approved process may publish.

Visual sources: [GeoGridIQ - GeoSQL pilot status and governance audit](https://geogridiq.com/outage-prediction/); [GeoGridIQ - Protected-artifact safety and runtime availability audit](https://geogridiq.com/outage-prediction/).

## How GeoGridIQ may expand the workflow

**Status, not promises**

Current foundation, pilot work, planned uses, and prohibited actions must not be blended into one product claim. The current foundation includes spatial querying and existing governance controls. The installed GeoSQL profile and configured map-QA design remain under evaluation. A self-hosted Dekart stage is planned in the pilot design but has not completed runtime validation, so it is not described as operational. Sources: [GeoGridIQ - GeoSQL pilot status and governance audit](https://geogridiq.com/outage-prediction/); [Dekart - Docker self-hosting guide](https://dekart.xyz/docs/self-hosting/docker/).

Subject to source, licence, privacy, and validation review, later work may cover municipal or cooperative exceptions, ECCC forecast-grid mapping, vegetation-source provenance, static exposure context, historical-event geometry, future grid design, Canada-wide gap analysis, and repeatable regression maps after source updates. These are planned investigations without delivery dates. Production labels, automated training or promotion, dispatch, cause determination, direct data mutation, and ungated forecast release remain outside the workflow. Sources: [GeoGridIQ - GeoSQL pilot status and governance audit](https://geogridiq.com/outage-prediction/). Continue: [NDVI and utility vegetation monitoring](https://geogridiq.com/blog/ndvi-utility-vegetation-monitoring/); [Understanding critical infrastructure risk](https://geogridiq.com/blog/understanding-critical-infrastructure-risk/).

### Visual: Current, pilot, planned, and not-authorized capabilities

Evidence class: Planned Capability

A semantic status table prevents configured or proposed work from being read as a live production capability.

Caption: Status grid generated from the July 29, 2026 claim review; no delivery dates or pilot results are implied.

| Capability | Verified status | Meaning as of July 29, 2026 |
| --- | --- | --- |
| PostGIS spatial queries | Current foundation | Existing spatial capability; not created by GeoSQL |
| Isolated GeoSQL profile | Pilot / installed | Version 0.31.0 installed; end-to-end workflow incomplete |
| Map feedback through self-hosted Dekart | Pilot / configured | Planned stage has not completed runtime validation |
| Quebec grid and serviced-land QA | Pilot / prepared | Review questions defined; no accepted result package |
| Weather-grid, vegetation, exposure, and event QA | Planned | Subject to source, privacy, licence, and validation review |
| Production labels, training, promotion, and release | Not authorized | Always governed through separate processes |

Visual sources: [GeoGridIQ - GeoSQL pilot status and governance audit](https://geogridiq.com/outage-prediction/); [GeoGridIQ - Protected-artifact safety and runtime availability audit](https://geogridiq.com/outage-prediction/).

## Security, privacy, and controlled access

**Controlled pilot principles**

The public design principle is isolation. Local or self-hosted tooling is preferred for the controlled pilot; any applicable application access is intended to be read-only, and allowed writes belong only in isolated staging. Official Dekart guidance also recommends a dedicated read-only database user and TLS, but those controls depend on deployment configuration. GeoGridIQ’s runtime denial probes have not yet run, so this article describes intended restrictions rather than claiming runtime proof. Sources: [Dekart - Docker self-hosting guide](https://dekart.xyz/docs/self-hosting/docker/); [Dekart - Postgres and PostGIS connection guide](https://dekart.xyz/docs/usage/postgres-connection/); [GeoGridIQ - GeoSQL pilot status and governance audit](https://geogridiq.com/outage-prediction/).

Credentials must not be embedded in content or maps. Customer addresses, crew locations, billing and authentication data, private identifiers, and sensitive infrastructure locations are outside the public article workflow. Rendering a map does not authorize sharing it; source licences and permitted uses require review, and any external data transfer needs a separate decision. GeoSQL’s documented telemetry opt-out is relevant configuration information, not proof that every connected workflow has zero external transfer or zero risk. Sources: [Dekart XYZ - GeoSQL repository and workflow documentation](https://github.com/dekart-xyz/geosql); [GeoGridIQ - GeoSQL pilot status and governance audit](https://geogridiq.com/outage-prediction/).

## What this workflow cannot prove

**Limits**

Visual plausibility is not correctness. A valid geometry can represent the wrong concept; infrastructure presence is not legal service territory; and a municipality boundary is not automatically a utility boundary. Even an official source can be incomplete, generalized, stale, or unsuitable for a new role. A map can reveal displacement or surprising coverage, but it cannot establish licence, authority, completeness, or temporal fitness on its own. Sources: [PostGIS Project - ST_IsValid](https://postgis.net/docs/manual-3.6/en/ST_IsValid.html).

The reverse is also true: numerical tests do not replace a map. Neither form of QA establishes forecast accuracy, guarantees that an outage will be predicted or prevented, or proves an operational benefit. The GeoSQL pilot is one upstream evidence-control experiment. Human review, documented limitations, independent governance, and downstream model evaluation remain required even if the workflow later becomes repeatable. Sources: [GeoGridIQ - Protected-artifact safety and runtime availability audit](https://geogridiq.com/outage-prediction/); [GeoGridIQ - GeoSQL pilot status and governance audit](https://geogridiq.com/outage-prediction/).

## Practical value for utility operations

**Operational relevance**

The credible value is procedural rather than a promised return on investment. Schema-aware exploration can reduce time spent guessing field names; versioned spatial SQL can make joins easier to reproduce; and paired metrics and maps can surface geometry or coverage defects earlier. Reviewers can see which cells remain contradictory or unavailable instead of receiving a single opaque output. Before-and-after maps can also make a source update easier to explain. Sources: [Dekart XYZ - GeoSQL repository and workflow documentation](https://github.com/dekart-xyz/geosql).

A shared evidence package gives GIS, data engineering, machine-learning, and operations specialists a concrete object to challenge: the source contract, query, measurements, map, limitations, and unresolved cases. That can improve technical communication and provenance before any feature reaches a model. GeoGridIQ is not claiming percentage savings, forecast improvement, reduced restoration time, or outage prevention; such claims would require a measured, reviewed deployment study that does not yet exist. Sources: [GeoGridIQ - GeoSQL pilot status and governance audit](https://geogridiq.com/outage-prediction/).

## Faster investigation is useful only when evidence stays reviewable

**Conclusion**

GeoSQL may help GeoGridIQ move more efficiently through spatial investigation, but the objective is not to let an agent decide what the grid means. The objective is to combine source contracts, reproducible SQL, numerical validation, accessible maps, provenance, and human judgment. The installation is a starting point; the staging run, map review, permission checks, evidence packaging, and independent acceptance still have to be completed and documented. Sources: [GeoGridIQ - GeoSQL pilot status and governance audit](https://geogridiq.com/outage-prediction/).

If those gates work as intended, better spatial evidence may move safely toward GeoGridIQ’s wider outage-intelligence workflow. If a source role, transformation, map, or permission boundary fails review, the evidence should stop. That fail-closed outcome is part of trustworthy data engineering—not a failed forecast. Sources: [GeoGridIQ - Protected-artifact safety and runtime availability audit](https://geogridiq.com/outage-prediction/). Continue: [Explore the GeoGridIQ Knowledge Hub](https://geogridiq.com/knowledge-hub/).

## Additional visual explanations

### Visual: From spatial records to a reviewed evidence package

Evidence class: Conceptual Illustration

The proposed pilot keeps query assistance, map review, human approval, and governed application decisions visibly separate.

Caption: Conceptual pilot flow. GeoSQL 0.31.0 is installed, but staging, map rendering, and governed handoff have not completed.

- 01: PostGIS. Governed spatial copy in isolated staging
- 02: GeoSQL. Schema discovery and bounded spatial SQL
- 03: Checks. Counts, area, extent, validity, and coverage
- 04: Map review. Layered inspection of boundaries and anomalies
- 05: Human gate. Accept, reject, or return unresolved evidence
- 06: Evidence. Versioned package; no automatic production write

## Limitations and responsible use

- Visual plausibility is not proof of correctness, and a structurally valid geometry may represent the wrong concept.
- Infrastructure or distribution-presence evidence is not necessarily legal service territory, and a municipality boundary is not a utility boundary.
- Official sources may be incomplete, generalized, stale, or unsuitable for a proposed role; unavailable coverage must not be converted to zero.
- Map QA does not replace numerical tests, and numerical tests do not replace map QA.
- GeoSQL output does not establish forecast accuracy or guarantee that an outage will be predicted, prevented, or restored faster.
- The installed profile is not a completed pilot: staging, rendering, runtime permission probes, and governed handoff remain unverified.
- Human review and GeoGridIQ’s provenance, temporal-safety, model-evaluation, and release controls remain authoritative.

## Frequently asked questions

### What is GeoSQL?

GeoSQL is an open-source agent skill for geospatial data work. It can guide schema discovery, spatial SQL, numerical and geometry checks, and optional map feedback across documented platforms including PostGIS; its output still requires qualified review.

### Is GeoSQL the model that predicts power outages?

No, GeoSQL is not GeoGridIQ’s outage-prediction model. It is being tested as an upstream spatial data-engineering and QA assistant with no authority to create labels, train or promote models, save risk, or publish forecasts.

### Why does GeoGridIQ need a map if the SQL query already ran?

GeoGridIQ needs a map because a successful query can still return geographically implausible results. Visual review can expose displacement, wrong joins, coastal classification errors, overlaps, or unsupported evidence roles that row counts alone may hide.

### Does GeoSQL write to GeoGridIQ’s production database?

No, the GeoSQL pilot has no authority to write to GeoGridIQ’s production database. Its design limits permitted writes to isolated staging, and runtime permission probes still need to be executed before that restriction can be described as runtime-validated.

### How is GeoGridIQ using GeoSQL today?

Today, GeoGridIQ has installed GeoSQL 0.31.0 in an isolated project profile and prepared a controlled map-QA pilot. Staging, numerical validation, Dekart rendering, permission probes, and governed evidence handoff have not yet produced verified results.

### What does GeoGridIQ plan to use GeoSQL for next?

Next, GeoGridIQ plans to validate the controlled Quebec workflow before considering broader uses. Possible later work includes weather-grid mapping, vegetation provenance, exposure context, historical-event geometry, and source-gap analysis, each subject to review.

### Can GeoSQL determine an electric utility’s official service territory?

No, GeoSQL cannot determine an electric utility’s official service territory by itself. It can help query and compare reviewed evidence, but only a source authoritative for that legal or operational role can support a territory claim.

### Does map-in-the-loop validation guarantee the data is correct?

No, map-in-the-loop validation does not guarantee that data is correct. A plausible map may use the wrong concept or stale source, while numerical tests can miss geographic anomalies; source review, both forms of QA, and human judgment remain necessary.

### What happens after GeoSQL produces an evidence package?

After GeoSQL produces an evidence package, independent governance must accept, reject, or return it for more work. Accepted evidence still faces source-role, geometry, coverage, feature-eligibility, temporal-safety, model-evaluation, and release gates.

## Sources and methodology

Source facts were reviewed on 2026-07-29. Mutable sources may change after that date.

- [GGI_GEOSQL_STATUS] [GeoSQL pilot status and governance audit](https://geogridiq.com/outage-prediction/) - GeoGridIQ; reproducible internal evidence; published or updated 2026-07-29; reviewed 2026-07-29; living source. GeoSQL 0.31.0 is installed in an isolated project profile; staging, map rendering, runtime permission probes, and governed handoff remain incomplete.
- [GGI_MODEL_STATUS] [Protected-artifact safety and runtime availability audit](https://geogridiq.com/outage-prediction/) - GeoGridIQ; reproducible internal evidence; reviewed 2026-07-26. Root HANDOFF.md and exact runtime audit, 2026-07-26
- [GEOSQL_REPO] [GeoSQL repository and workflow documentation](https://github.com/dekart-xyz/geosql) - Dekart XYZ; primary project documentation; reviewed 2026-07-29; living source. Capabilities are project-documented; they do not establish GeoGridIQ pilot completion.
- [GEOSQL_METADATA] [GeoSQL project metadata](https://github.com/dekart-xyz/geosql/blob/main/pyproject.toml) - Dekart XYZ; primary project metadata; published or updated 0.31.0 metadata reviewed 2026-07-29; reviewed 2026-07-29; living source. The repository has no tagged GitHub release; 0.31.0 is package metadata, not a release claim.
- [GEOSQL_LICENSE] [GeoSQL MIT License](https://github.com/dekart-xyz/geosql/blob/main/LICENSE) - Dekart XYZ; primary licence; published or updated 2026; reviewed 2026-07-29.
- [DEKART_REPO] [Dekart repository and SQL-map documentation](https://github.com/dekart-xyz/dekart) - Dekart; primary project documentation; reviewed 2026-07-29; living source. Documented capability does not establish that GeoGridIQ has completed a Dekart runtime validation.
- [DEKART_DOCKER] [Docker self-hosting guide](https://dekart.xyz/docs/self-hosting/docker/) - Dekart; primary deployment documentation; reviewed 2026-07-29; living source.
- [DEKART_POSTGRES] [Postgres and PostGIS connection guide](https://dekart.xyz/docs/usage/postgres-connection/) - Dekart; primary connection documentation; reviewed 2026-07-29; living source. Read-only access is a deployment permission choice, not an inherent guarantee.
- [DEKART_LICENSE] [Dekart self-hosted editions and licensing](https://dekart.xyz/self-hosted/) - Dekart; primary licence documentation; reviewed 2026-07-29; living source. The current open-source edition is AGPL-3.0-or-later; commercial licensing is separate.
- [POSTGIS_DATA_MODEL] [PostGIS 3.6 spatial data management](https://postgis.net/docs/manual-3.6/en/using_postgis_dbmanagement.html) - PostGIS Project; primary technical documentation; published or updated 2026-06-08; reviewed 2026-07-29.
- [POSTGIS_QUERIES] [PostGIS 3.6 spatial queries](https://postgis.net/docs/manual-3.6/en/using_postgis_query.html) - PostGIS Project; primary technical documentation; published or updated 2026-06-08; reviewed 2026-07-29. An indexed or successful query is not proof that its source, CRS, join, or interpretation is correct.
- [POSTGIS_VALIDITY] [ST_IsValid](https://postgis.net/docs/manual-3.6/en/ST_IsValid.html) - PostGIS Project; primary function documentation; published or updated 2026-06-08; reviewed 2026-07-29. Structural validity does not establish semantic correctness or operational fitness.
- [POSTGIS_TRANSFORM] [ST_Transform](https://postgis.net/docs/manual-3.6/en/ST_Transform.html) - PostGIS Project; primary function documentation; published or updated 2026-06-08; reviewed 2026-07-29.

## Related GeoGridIQ articles

- [How outage prediction works: data, models, and trust gates](https://geogridiq.com/blog/how-outage-prediction-works/)
- [Forecast accountability: validating outage predictions before trust](https://geogridiq.com/blog/forecast-accountability-outage-prediction/)
- [NDVI for utility vegetation monitoring](https://geogridiq.com/blog/ndvi-utility-vegetation-monitoring/)
- [Understanding critical infrastructure risk during power outages](https://geogridiq.com/blog/understanding-critical-infrastructure-risk/)

## See how spatial evidence fits into outage-risk evaluation

GeoSQL is one upstream QA experiment. Explore the wider GeoGridIQ methodology and the separate controls used to evaluate forecasts.

- [Explore how GeoGridIQ evaluates outage risk](https://geogridiq.com/outage-prediction/)
- [Read why forecast accountability matters](https://geogridiq.com/blog/forecast-accountability-outage-prediction/)