# How DEPLOY operates

By Ben Smith, Editor

The methodology page at [/methodology](/methodology.md) 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:

- **Registry-ingest lane.** Scaffolds new registry-side records: Model entities, Company / Manufacturer, Brain, ModelBrain wiring, Operator, Deployment, Incident, Regulation. Backfills fields on existing records. Owns the structural data layer.
- **Consumer-build lane.** Owns the consumer surface (deploy.report): /price + /service routes, consumer listings, capability claims, multimedia ingestion for the consumer property. AEO-targeted content with user-language H1s + framework-language depth in body.
- **News-pub lane.** Owns the editorial publication (news.deploy.report): explainers, signals, methodology editorial, coverage of regulatory + lifecycle events. Cross-links into registry entities by canonical slug.
- **Rover-surface lane.** Owns the registry surface infrastructure (registry.deploy.report): entity pages, render components, MCP server, REST API, JSON-LD, methodology + transparency pages.
- **Acquisition lane.** Multimedia provenance + license-clean attribution + image / video ingest with the three-tier license policy (permissive / restrictive / unknown). Ensures every published media asset has documented provenance.

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 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.

## 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.
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.
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. 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:

- **Verified greater than claimed.** When the framework can record a claim or stay silent, the framework stays silent unless verification is on file. A shorter verified record beats a longer record padded with claims.
- **Restraint IS the product.** Cap-flag absence on a high-confidence record + transparent under-target on coverage targets + honest empty results on framework analysis tools are the editorial differentiators. The framework refuses to pad.
- **No em dashes in DEPLOY-authored prose.** Editorial-rule enforced mechanically via pre-commit hook. Em dashes read as AI-generated; the framework opts for the punctuation that fits the context.
- **HTTP status-code integrity.** 404 means not found; 500 means actual server error. Downstream consumers depend on status-code reliability for branching. Never conflate.
- **Media-license discipline.** Media assets must be blob-hosted or platform-embed; manufacturer-CDN hotlinks are rejected at three layers (pre-commit hook, service chokepoint, prod audit script).
- **Append-only on trust-bearing data.** Incidents, status events, verifications, permissions are append-only. Current state derives from the event log; the log is the source of truth.

## See also

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

_Canonical URL: /editorial-process. JSON-LD and HTML version: [/editorial-process](/editorial-process)._