How it works

Watch one request travel through PlaceRouter.

Target architecture · enterprise request

"Provide current operating conditions for 4,000 locations, with under 15-minute freshness and source provenance."

  1. 01 · The request

    A system asks.

    One requirement, thousands of locations. No provider named.

  2. 02 · Understand

    PlaceRouter works out what is being asked.

    Fields. Locations. A freshness limit. A provenance requirement.

  3. 03 · Find sources

    Candidate sources appear.

    Five could hold parts of the answer. None has all of it, everywhere.

  4. 04 · Compare

    PlaceRouter evaluates them.

    Freshness, reliability, coverage, authority.

  5. 05 · Route

    The right routes light up.

    Four sources carry the request. The historical model stays as fallback.

  6. 06 · Assemble

    The answer assembles field by field.

    Speed from the commercial feed. Closures from the authority. Visibility from the weather network. Surface from the sensors.

  7. 07 · Answer

    One answer, with provenance.

    Every value carries its source, timestamp and confidence.

Under the hood

What happened under the hood?

Seven stages ran behind that journey. The last one feeds the next request. Which stages are research, which are architecture, and which are future capability is stated below.

  1. 01ResolveWork out which real-world entities the request refers to.
  2. 02DiscoverFind the systems that could hold the answer.
  3. 03EvaluateScore each route on freshness, reliability, coverage, authority, cost and rights.
  4. 04RouteSelect one source, or a combination, per field.
  5. 05ReconcileWhen sources disagree, weigh the evidence.
  6. 06ReturnSend back structured information with provenance.
  7. 07LearnRecord how each source performed, for next time.
resolving entitiesArchitecture
The routing decision can vary by

sourcefieldlocationtimehardware classfreshnesscontext

Not all of these are implemented universally. Hardware-class and freshness effects are measured in current research; location and time dependence are architecture; the rest are direction.

Entity resolution

The physical world doesn't have a primary key.

A provider ID, a sensor ID, an infrastructure ID, a facility name, a business ID and a pair of coordinates can all be one real-world entity. PlaceRouter needs to know when they are.

  • Provider ID
  • Sensor ID
  • Infrastructure ID
  • Facility name
  • Coordinates
Same entityone identity

Under the hood

Identity resolution is part of the long-term architecture: a graph of how identifiers, addresses and coordinates relate to real entities and to the networks, buildings and places around them. It is not a complete global graph today. It is being built requirement by requirement, and some information, such as weather observations or traffic conditions, has geographic, time or asset context rather than a single place.

provider idsensor idfacilitycoordinatesasset idone entitynetworkbuildingnearby places
Source intelligence

Every request teaches the router more about how sources behave.

Source performance changes across geography, time and context. PlaceRouter is designed to learn which sources perform best for which information, and to learn it per domain.

  • Which weather source is freshest at this station
  • Which air-quality calibration transfers by hardware class
  • How much accuracy a transit feed loses per minute of delay
  • Which authority to trust for road closures in this state
  • Which source to fall back to when the primary fails
request route result learn better route

AI can reason.
PlaceRouter connects it to the world.

Want the journey run against your own information requirement? That is an Intelligence Pilot.

Work with us →