DEPLOYDatabase

Methodology

The operational context layer

By Ben Smith, Editor

DEPLOY is building a runtime data layer for physical AI systems. Most data APIs describe physical AI: who built it, what it costs, where it has been deployed. The operational context layer answers a different question. What does a physical AI system need to know right now to operate legally and safely at a given location?

What it returns

A single query to /v1/operational-context returns three layers of structured data:

  • Regulatory posture. Which regulations apply at this location for this form factor, walked up the full jurisdiction hierarchy from city to state to country. A sidewalk robot operating in San Francisco inherits San Francisco ordinances, California Vehicle Code provisions, and any applicable federal guidance. The walk stops at the first level that carries a definitive posture signal.
  • Active deployments. Which physical AI systems are confirmed operating at this location right now, drawn from the DEPLOY registry. Each entry carries the same verification posture the registry records: verified, company-claimed, or proposed.
  • Operational posture. A derived summary label computed from the regulatory and deployment layers. Values are regulated, permit_required, proposed_only, no_data, and mixed (when jurisdictions within the query area carry conflicting postures).

How to query it

The endpoint accepts either a location slug or GPS coordinates, combined with a form factor filter:

GET /v1/operational-context?location=san-francisco&form_factor=sidewalk
GET /v1/operational-context?lat=37.7749&lng=-122.4194&form_factor=av

A response looks like this:

{
  "location": {
    "slug": "san-francisco",
    "name": "San Francisco",
    "region": "California",
    "country": "United States"
  },
  "form_factor": "sidewalk",
  "regulations": [
    {
      "id": "...",
      "title": "San Francisco Permit Program for Delivery Robots",
      "jurisdiction": "san-francisco",
      "jurisdiction_level": "city",
      "posture": "permit_required",
      "effective_date": "2023-04-01",
      "source_url": "https://..."
    }
  ],
  "active_deployments": [
    {
      "id": "...",
      "model_slug": "coco-delivery-bot",
      "operator": "Coco",
      "verification_status": "verified",
      "deployment_date": "2022-06-01"
    }
  ],
  "operational_posture": "permit_required"
}

Who it is for

Three audiences query the operational context layer:

  • Physical AI systems at runtime. A robot or drone approaching a new zone can query before entering to determine whether it holds a valid permit, whether a competing system is already operating, and what the governing regulatory posture is. The answer shapes routing, speed limits, and whether human handoff is required.
  • Fleet operators planning expansion. An operator evaluating a new city needs to know the regulatory stack before committing to a permit application. The operational context layer surfaces that stack in a single call, with jurisdiction-level attribution so the operator knows which authority to contact.
  • Agent swarms coordinating physical systems. A software agent managing multiple physical AI systems across multiple locations needs location-aware context to route tasks correctly. The operational context layer is the interface between the software coordination layer and the physical regulatory world.

Data discipline

Regulatory data in the operational context layer is editorial and research-sourced. Each regulation record carries a source URL, a jurisdiction level, and a verification posture drawn from the same framework that governs the rest of the DEPLOY registry. A regulation labeled verified has been sourced from a primary regulatory document; one labeled reported has been sourced from secondary journalism and has not been independently cross-checked against the primary filing.

Regulations change. Permits expire. Ordinances are amended, appealed, or superseded. DEPLOY updates records when changes surface through its re-verification pipeline, but it does not guarantee real-time accuracy. Verify with the relevant regulatory authority before making operational decisions. The DEPLOY registry is a structured starting point, not a legal compliance system.

The broader verification framework that governs all DEPLOY data is documented at /methodology. The regulations index, with jurisdiction coverage and source attribution, is at /regulations.

What comes next

The current endpoint resolves by location slug or exact GPS coordinates. Several capabilities are in the roadmap:

  • Proximity resolution. Query by GPS coordinates and receive all regulations and deployments within a configurable radius, ranked by distance from the query point.
  • Geofencing zones. Named zones with explicit entry and exit rules, separate from jurisdiction boundaries. A port terminal, an airport perimeter, and a hospital campus each carry distinct operational rules that do not map cleanly to municipal boundaries.
  • Permit status by operator. Whether a specific operator holds an active permit at a location, surfaced directly in the response rather than requiring the caller to cross-reference the permit registry.
  • Real-time event overlays. Temporary restrictions such as parades, emergency declarations, and weather-based groundings overlaid on the base regulatory posture, with explicit expiry timestamps.

See also: regulations for the full jurisdiction index; methodology for how DEPLOY verifies every record in this layer.