Transit ops wants live bus locations for the resident agent while service-policy PDFs remain in the vector store. How should knowledge access be architected?

Transit operations need two different knowledge tempos for a resident agent: live bus locations change continuously, while service-policy PDFs change infrequently. The correct architecture feeds live open-data APIs for bus locations while keeping policy PDFs in the vector store for retrieval. Real-time APIs preserve currency for “where is my bus?” questions; vector retrieval preserves authoritative, citable policy language for fares, accessibility rules, and service changes that are not appropriate to bake into ephemeral GPS streams.

Embedding yesterday’s bus GPS dumps and treating them as forever-current fails because yesterday’s coordinates are not today’s service; stale embeddings create confidently wrong ETAs. Putting policy PDFs on a public USB drive and skipping APIs and retrieval entirely fails as both a security and an architecture answer—USB distribution is not a governed knowledge path and abandons live feeds. Deleting the vector store so every answer comes only from real-time GPS pings fails because location telemetry cannot answer policy questions and leaves the agent without the municipal rulebook.

Exam caveat: hybrid knowledge access means routing by question type and freshness requirements. Do not embed high-churn telemetry into the same long-lived vector index used for ordinances; do not expect open-data GPS alone to authorize fare or ADA guidance.

Operational check: for a sample transit query set, confirm location questions hit the live API with acceptable latency and policy questions retrieve the correct PDF passages with citations; alert when API freshness lags or when policy index versions drift from the published effective date.