DaedalMap DaedalMap
Docs / How It Works

Maintained evidence.
Shared geography.

DaedalMap turns scattered source data into maintained geographic evidence. Explore, Research, and Ops are different ways to use the same pack layer: visual discovery, slower bounded analysis, and fresh live watch context.

The evidence layer

DaedalMap behaves like one maintained evidence system, not separate tools that happen to share files. Packs carry source membership, reference metadata, provenance, coverage, release state, and runtime behavior.

The product value is the maintained layer: sources found, cleaned, normalized, versioned, tested, kept fresh where needed, and made easy to ask questions of.

Three human modes

Each mode has its own posture. Explore handles broad map discovery: "what can I see?" Research works inside a bounded corpus: "what does this evidence show?" Ops emphasizes live watch and recent state: "what changed, and which source says what?"

Agents and local installs are access paths over the same maintained layer. They stay findable in docs, but the main public product story is Explore, Research, and Ops.

Runtime path

After a user asks a question, the runtime follows the same basic path across modes.

  1. Resolve the pack, source, or live feed against the active surface.
  2. Normalize requested metrics, geography tiers, and loc_id values.
  3. Validate access rules, row limits, and request shape.
  4. Execute against the canonical Parquet-backed pack data.
  5. Return rows, source context, and the shared map/display payload.

That shared path keeps the same pack request behaving the same way across Explore, Research, Ops, and builder access.

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. The geometry spine owns hierarchy, boundaries, parent chains, centroids, bboxes, and side-chain overlaps, so data rows do not have to carry duplicate geography logic.

The map side is shared too. Explore, Research, and Ops emphasize different actions, but the same maintained geography keeps the display, filtering, source trail, and handoff paths aligned.

Source trail and machine access

Source-backed answers need visible limits. Pack pages, source metadata, coverage notes, licenses, examples, and Agent Catalog discovery all exist so a user or agent can see what evidence was available before trusting an answer.

MCP and HTTP APIs sit on top of the same maintained layer. They are machine access paths for developers and agents, not a separate data product with separate truth.

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.