DEPLOYDatabase

Documentation

DEPLOY API documentation

The verification framework as a callable surface. The registry publishes its discipline through three complementary channels; consumers compose them per the integration that fits.

Three surfaces, one corpus

  • MCP tool catalog: 20 tools across two surfaces. V1 carries five retrieval primitives (entity lookup, deployments by location or model, recent incidents). V2 carries fifteen framework-analysis tools (claim verification, aggregator drift detection, autonomy-boundary + brain-provider-architecture classification, methodology resolution, corrections journal access). The MCP server lives at /mcp; this catalog is the per-tool reference.
  • REST API at /v1/*: HTTP JSON endpoints for every entity type on the registry plus the public taxonomies, sagas, and methodology surfaces. Each entity detail response carries an additive framework_metadata block with the same verification posture, cap-flags, and within-cohort pair membership the methodology surface renders.
  • Operational context API: runtime endpoint for physical AI systems and agent swarms. Query regulatory posture, permit requirements, and confirmed active deployments for any location by slug or GPS coordinates. Designed to be called at runtime, not just for research.
  • JSON-LD with deploy: namespace: every entity page emits structured data under the schema.org graph plus DEPLOY's custom vocabulary at https://deploy.report/schema/v1/. The deploy: properties surface methodology metadata, autonomy-boundary classifications, brain-provider architectures, within-entity sagas, and funding-round graphs.

Framework reference

The discipline behind every tool, endpoint, and JSON-LD block is documented at four canonical references on the registry:

  • /methodology: the verified-vs-claimed rubric; what counts as verification.
  • /editorial-process: how the framework operates day-to-day. Lane discipline, audit-first cohort sync, four-tier layered verification.
  • /corrections: the public log of records changed since publication (append-only; same surface as the v2_list_corrections tool).
  • /funding and /conflicts: independence + relationship disclosure standing.

Integration patterns

Three common shapes drive integration choice:

  • Agentic AI assistants: connect via MCP at /mcp; the tools/list discovery flow returns all 20 tools with input schemas and framework-laden descriptions. Recommended starting point for an LLM that should verify claims before propagating.
  • Application integration + analytics: query the REST API at /v1/*. Authentication via Authorization: Bearer <token> against the public token surface. Every entity detail response carries framework_metadata for downstream verification framing.
  • Structured data ingestion: crawl entity pages directly; parse JSON-LD with deploy: namespace vocabulary. The custom vocabulary surfaces verification posture, cap-flags, and architectural classifications that schema.org alone cannot express.

Machine-readable mirror

Every docs page also ships a Markdown mirror at the same path with a .md suffix: /docs.md, /docs/mcp.md, /docs/v1.md, /docs/jsonld.md. Same content, agent-readable shape. The registry-wide manifest is /llms.txt.