DEPLOYThe reference layer for physical AI

Editorial process

How DEPLOY operates

By Ben Smith, Editor

The methodology page at /methodology documents what DEPLOY records and how it represents the data. This page documents how that discipline operates day-to-day: the multi-agent lane structure, the audit-first habit, the layered verification cluster, and the standing rules that govern every commit on the registry.

Multi-agent lane discipline

DEPLOY operates as a small editorial team augmented by specialized AI agents, each working in a lane with explicit scope boundaries. Five lanes coordinate through editorial dispatch rather than ad-hoc handoff:

Lane discipline is strict: a task that crosses lanes stops and flags for editorial coordination rather than guessing across the boundary. Cross-lane state changes (entity slug renames, schema evolution, framework typed-const edits) propagate via coordinated PR with framework-discipline review at submission, not silent overwrites.

The lanes share the same canonical entity graph. A robot model ingested by the registry-ingest lane is the same canonical Model the consumer-build lane cites on a /price page, the same entity the news-pub lane writes an explainer about, the same slug the rover-surface MCP server returns from v2.verify_claim.

Audit-first cohort sync

Substantial scope-defining campaigns audit before executing. Before ingesting a new cohort, before scaling a methodology surface, before running a large-batch backfill, the operating lane reads the current state (live entity counts, slug existence, source-quality posture, drift-pattern coverage) and publishes the audit data as first-wave targets. Discovering scope mid-work is the failure mode the audit-first discipline prevents.

The discipline pairs with the chief-of-staff dispatch model: dispatches occasionally carry framing assumptions that don’t match current codebase reality (the V1 MCP had 5 tools, not 11; the framework_metadata substrate did not include reviewer attribution at row granularity). The operating agent surfaces the discrepancy + proposes scope refinement before executing. Verifying done-state against deploy state, not just narrative, is part of the same pattern.

Slug-audit verification operates at finer granularity: before treating any entity as net-new, the operating agent checks whether the slug already exists in the registry. The Walker S3 check is the canonical example (the entity doesn’t exist; treating it as net-new would have polluted the cohort).

Four-tier layered verification discipline

DEPLOY’s framework discipline operates on DEPLOY’s own work, not just on the registry data. Four verification layers, at distinct architectural granularities, catch errors type checks alone cannot:

  1. Type checking + data-layer regression suite. The first line: tsc --noEmit + a regression suite at scripts/check-v2-framework-regressions.ts covers shape validity + helper logic + cross-reference integrity of the framework typed-const. Catches: malformed types, broken slug references, unit-level helper bugs.
  2. Local Next.js build. The second line: next build runs Webpack’s production compilation + Next.js page-data collection. Catches: circular-import temporal-dead-zone errors that type checks miss because they exercise runtime module evaluation order rather than type validity. Banked from the V2 MCP Phase 1A C2 production incident where every deploy C2 through C10 failed at page-data collection with a webpack-renamed TDZ error; tsc passed throughout.
  3. Rendered-surface verification on canonical examples. The third line: render the methodology surface on a canonical worked example pair (RingConn-vs-Happy Ring), check the output against expected role semantics, iterate before scaling. Catches: cross-reference role-anchoring semantics that only the rendered surface reveals. Banked from Phase 1A.5a where the drift-subject-vs-anchor distinction surfaced only when Happy Ring rendered as “claimed-not-cleared” on a known-FDA-cleared entity. tsc + regression suite passed; the rendered surface caught the data-model bug.
  4. Edit-success verification on multi-file workstreams. The fourth line: when applying tooled Edit operations across a multi-file workstream (typed-const + barrel re-export + dispatcher wiring + tool registration), explicitly verify each file landed before declaring the change ready. Catches: silent-Edit-failure where a stale file-context returns “File has not been read yet” and the change appears applied but is not. Banked from v0.2 E2 ship where the autonomy-boundary dispatcher wiring slipped through: the tool file landed but the registry entries did not, so tools/list never exposed the tools. Build passed because unused modules compile trivially. Verified by grep-counting expected symbols in each touched file before committing.

Each layer catches what the previous layer misses. The four- tier discipline IS the verification authority position operating recursively: DEPLOY’s framework verifies the physical-AI sector; DEPLOY’s discipline cluster verifies DEPLOY’s framework.

Per-commit cadence + framework-laden response

Editorial work ships in small per-commit batches. One entity per commit when ingesting; one tool per commit when shipping MCP surface; one transparency page per commit when shipping editorial-discipline documentation. The cadence keeps each change auditable + reviewable + revertible. The git log is the first-class editorial change log.

Framework-laden response discipline: every MCP tool response, every entity-page render, every JSON-LD block carries framework signals beyond the structured data block. Verified-vs-claimed framing in narrative descriptions. Cap-flag context preserved alongside data. Source attribution with verification-depth signals. Aggregator drift patterns acknowledged where relevant. The framework signals don’t get stripped for cleaner data shape; they ARE the data shape downstream consumers absorb.

Cross-property coherence

DEPLOY publishes from three URL apexes: registry.deploy.report (this property; the registry), deploy.report (consumer surface), news.deploy.report (editorial publication). The properties share the same canonical entity graph + the same framework typed-const + the same source- quality tier classifier. A reader cross-checking RingConn across the three properties sees the same verification posture, the same cap-flags, the same canonical worked example pair membership.

Canonical-URL discipline avoids fragmenting the credibility signal: methodology is canonical here (registry); the other properties cross-link rather than mirror. Corrections journal is canonical here (registry-side append-only data is the source of truth). Editorial process is property-specific because workflows differ materially across the three lanes.

Standing rules

A small set of rules apply to every commit on every lane. They’re documented as standing rules (not per-feature guidance) because the discipline they encode is load-bearing across the framework:

See also

Methodology for the framework rubric; corrections for the public log of records changed since publication; funding + independence for the operational independence + sustainability position; conflicts of interest for the relationship-disclosure procedure; about DEPLOY for the masthead; glossary for the strict definitions used across the registry.

Machine-readable: this page as markdown.