Maintained pack truth
DaedalMap behaves like one maintained data system, not separate tools that happen to share files. Published packs, source membership, reference metadata, and release state are shared across Explore, Research, Ops, the agent lane, and the local runtime lane.
If a pack is published, every access pattern reads the same pack truth. The modes differ in workflow, access scope, and reasoning posture, not in what the same pack means.
Several access patterns, one data layer
Each mode has its own job. Explore handles broad map discovery. Research works inside a bounded corpus. Ops emphasizes live watch and recent operational state. Agents call the same maintained layer through MCP or HTTP. The local runtime gives researchers and technical teams a more controlled local access path over the same engine contract.
Those differences belong in interface, tool surface, and session behavior. They do not justify separate data semantics, separate geography handling, or separate pack meaning.
Deterministic runtime seam
After a mode chooses what to ask for, the runtime moves into one shared execution layer. That layer resolves packs, normalizes metrics and geography, validates request shape, and returns the shared display payload.
- Resolve the pack or source against the active catalog surface.
- Normalize requested metrics, geography tiers, and location ids.
- Validate access rules, row limits, and request shape.
- Execute against the canonical Parquet-backed pack data.
- Return rows plus the shared map/display payload contract.
That shared execution layer keeps the same pack request behaving the same way across modes.
Storage and execution
Pack data is stored as Parquet. The query engine is DuckDB with
httpfs support, so hosted deployments can read directly from
object storage while local deployments read from disk. Predicate pushdown
keeps reads narrow when filters are selective.
Hosted use and install-it-yourself deployments use the same catalog format and the same pack contract. The difference is which catalog is loaded and which storage path those deployments point to.
Shared geography and display
Every pack normalizes geography through loc_id and the
shared country crosswalk layer. The runtime preserves the requested
geography tier through query interpretation, execution, and geometry
loading instead of collapsing everything back to a source default.
The map side is shared too. Explore, Research, and Ops can emphasize different actions, but the same pack data still arrives in the same compact selection and display shape.
Discovery and agent access
Discovery endpoints such as GET /api/v1/catalog and
GET /api/v1/packs/{pack_id} expose the published pack layer
without executing queries. MCP sits on top of the same runtime. It does
not introduce a second data path or a second pack model.
Pack-specific MCP facades exist for discoverability. They still resolve into the same catalog, runtime helpers, access checks, and execution layer as direct HTTP calls.
Release and access boundaries
Packs move through build, QA, publish, and optional agent-facing release gates. A pack can be published for the human app before it is agent-ready, but there is still one underlying pack truth. Release state describes visibility and readiness, not a different data meaning.
The same split applies commercially. The engine is open. Upstream pack rights still depend on source terms. The maintained work - normalization, metadata, QA, packaging, preservation, and freshness - is the real value layer. Hosted Ops and agent access are paid service lanes, while the local runtime is the controlled research-oriented handoff.