A rider can ask, spmc po to uyanguren? and expect a useful answer. That sentence does not contain a route ID, a stop ID, or a precise coordinate. It needs place resolution, route knowledge, direction, and a decision about whether the requested journey can be served. The passenger-language research records this kind of short, mixed-language query as evidence of how people ask for transit help, not as route authority.

Davao Transit is built around that gap between a rider's question and the data that can answer it. A bus route has ordered stops and directional variants. A jeepney route may arrive as a reviewed line and landmark description rather than a formal stop sequence. A vehicle report is an observation with a timestamp, not a promise that the bus is still there. The system keeps those kinds of information separate because treating them as one map would create connections the data does not support.

The following map answers one question: which part of the product owns each kind of transit knowledge?

The catalog owns static route identity, stops, geometry, and the topology that is safe to compile. The planner turns that topology into a local search problem. The tracker reads a separate online observation path. The assistant only interprets language and dispatches a deterministic product action. It does not become a second routing engine.

That separation also gives the app two different operating modes. Work that changes slowly can travel with the web app. The planner image is a content-addressed .wayplan asset described by planner-image.json; Workbox includes both in its precache. The browser verifies the image and mounts it in a dedicated worker before it accepts a planning request. Route bundles and manifests have their own cache rules, and React Query plus saved activity use the browser's navigate-davao IndexedDB database. These are separate stores with separate failure and clearing behavior.

Work that depends on the outside world stays online. Place search calls a configured provider. The public API serves vehicle snapshots and derived intelligence. The assistant sends the rider's message to POST /api/ai/chat to extract an intent. Once an intent comes back, the browser performs the transit operation against its local bundles, its planner worker, or the public vehicle endpoint. A failed model request should not make the static route catalog disappear, and a failed collector request should not invalidate an already verified planner image.

There is an important current limitation in that last sentence. The browser currently sends liveBusArrivals: [] when it asks the planner worker to plan a trip. Live vehicle evidence is therefore not attached to the current browser planner result. The tracker and intelligence views can still query the API, but the route search itself remains based on the mounted static planner image.

A useful reading order

Use these pages in order to follow a rider request from language to transit result:

The current sources for the browser lifecycle are the Workbox configuration, the planner transport, and the trip worker. The public boundary is assembled in the API app.