Skip to content
Notes October 2026 Intelstav Labs

A local service business operates across physical geography, not a collection of URLs. Its customers describe destinations through neighbourhood names, settlements, landmarks and everyday local expressions. A website can publish information about those places, but publication is not a prerequisite for recognising them.

This distinction shaped the geographic intelligence architecture developed around TaxiGO, a taxi service operating from Veliko Tarnovo, Bulgaria. The engineering question was straightforward: how can a service recognise additional destinations, evaluate geographic evidence and select an appropriate operational action without manufacturing a landing page for every place?

The work extends the separation between technical recognition and administrative authority discussed in When Google Believes the Code but Does Not Yet Trust It Administratively.

A Destination Is Not a Page

A destination has geographic identity. A webpage has editorial identity. They may refer to the same real-world place, but they are not interchangeable records.

TaxiGO maintains public service resources, including its Veliko Tarnovo service hub. Additional destinations can exist within a structured knowledge registry without acquiring their own WordPress posts, canonical URLs or sitemap entries.

This boundary is deliberate. Geographic recognition answers whether the system understands a destination. Editorial publishing answers whether that destination deserves an independently useful public document.

Destination Resolution and Geographic Evidence

Destination resolution begins with a human expression, not a coordinate pair. A query may contain an abbreviated locality name, a landmark or an ambiguous commercial destination. Textual similarity identifies candidates; it does not certify their geographic identity.

Administrative affiliation and spatial proximity are also different forms of evidence. A settlement outside the municipality may remain geographically close to the service origin. A familiar name may identify several distant places.

The resolver therefore separates candidate recognition, entity identification, coordinate certification and service eligibility. Each stage must preserve uncertainty rather than silently converting incomplete evidence into an authoritative service decision.

Virtual POIs Without Virtual Pages

A virtual point of interest is an internal knowledge record for a real-world destination. It is not a fabricated location, a synthetic business listing or an automatically generated webpage.

Landmarks, institutions, hotels and localities can be represented as geographic entities even when no dedicated public URL exists. The knowledge layer stores destination identity and supporting evidence; the publishing layer determines which subjects justify independent editorial content.

This distinction allows geographic coverage to evolve without multiplying near-identical landing pages. A newly recognised destination does not automatically enter the sitemap, acquire a canonical URL or become eligible for search indexing.

The governing principle is simple: geographic knowledge may support a service decision without becoming a publishing instruction.

Spatial Geometry Is Not Road Routing

Once an entity has certified coordinates, geographic separation can be calculated consistently. The TaxiGO model uses the Haversine formula with a mean Earth radius of 6,371.0088 kilometres to estimate the great-circle distance between the service origin and destination.

That measurement supports geographic classification. It does not establish road distance, driving time, route accessibility or transport price. Terrain, road networks, restrictions and traffic belong to a separate routing model.

Keeping those concepts separate prevents an approximate straight-line measurement from being presented as operational certainty. A destination may be geographically close yet require a substantially longer road journey.

The geometry layer therefore provides bounded spatial evidence, not navigation. Its output can inform service policy, but cannot replace dispatcher judgement or verified road-routing information.

Geographic Scope and Service Eligibility

Geographic classification describes where a destination lies relative to the service origin. Service eligibility answers a different question: what operational response is justified by the available evidence and business policy?

The TaxiGO model uses four geographic bands, calculated from certified coordinates:

Geographic scope Distance
URBAN 0–10 km
NEARBY_LOCALITY Above 10–30 km
REGIONAL Above 30–50 km
OUT_OF_LOCAL_SCOPE Above 50 km

Operational policy applies a separate classification:

Service policy Distance
TAXI Up to 30 km
EXTENDED_LOCAL Above 30–50 km
DISPATCH_CONFIRMATION Above 50 km

These thresholds are geographic policy inputs, not road-distance estimates, journey-time guarantees or fare calculations. A destination beyond 50 kilometres is not automatically rejected or converted into a predefined transfer route. It may require dispatcher confirmation before any service commitment.

Coordinate Certification and Dispatcher Authority

A recognised destination is not automatically an actionable destination. Eligibility requires numeric latitude and longitude and an explicit route_coordinate_certified value of YES.

Where that evidence is absent, the system must preserve an unresolved state rather than infer service eligibility from a name match. This protects the operational layer from incomplete or ambiguous geographic records.

For journeys requiring confirmation, the dispatcher remains the operational authority. Geographic classification can inform that decision, but it cannot independently establish road accessibility, vehicle availability, journey duration or price.

The distinction is essential: evidence determines what the system can establish; policy determines what action it may recommend; the dispatcher confirms what the service can actually provide.

Separating Knowledge, Publishing and Action

The geographic model is useful only when its responsibilities remain explicit. The knowledge layer identifies destinations and maintains supporting evidence. The spatial layer evaluates coordinates and geometry. The policy layer determines eligibility. The action layer presents the appropriate operational response.

Publishing is a separate responsibility. Public documents require editorial purpose, canonical ownership and coherent information architecture. Recognising another destination must not automatically create another indexable page.

This separation follows the engineering principle explored in One Owner, Consistent Signals: each responsibility should have a defined owner, and downstream systems should consume consistent evidence rather than reconstruct competing versions of the same fact.

The resulting decision path is deliberately compact:

Human intent → Destination resolution → Geographic evidence → Spatial classification → Service policy → Operational action.

Each transition has a distinct meaning. A successful text match does not certify coordinates. Certified coordinates do not establish road distance. Geographic classification does not guarantee service availability. An operational action does not require a new public URL.

What the Architecture Actually Proves

The TaxiGO implementation demonstrates that a local service website can maintain a structured model of operational geography without publishing a dedicated landing page for every recognised destination.

It establishes a separation between destination identity, spatial evidence, service eligibility and public information architecture. That separation supports controlled expansion of geographic knowledge while preserving editorial governance over canonical pages.

It does not prove that every possible destination resolves correctly, that straight-line distance replaces road routing or that virtual POIs independently improve Google rankings. Those conclusions would require separate evidence.

The engineering result is more precise: geographic coverage can be modelled as operational knowledge rather than expressed exclusively through a growing inventory of URLs.

A local service system should understand where a customer wants to go, establish what the available evidence supports and present the appropriate next action. Its website should publish useful documents about that service—not manufacture a document for every place the system can recognise.

Start a project

Build a system designed to last.

Tell us what you are building. We will help structure the technical path before execution begins.