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:
- 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. The lane this page lives in.
- 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 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:
- Type checking + data-layer regression suite. The first line:
tsc --noEmit+ a regression suite atscripts/check-v2-framework-regressions.tscovers shape validity + helper logic + cross-reference integrity of the framework typed-const. Catches: malformed types, broken slug references, unit-level helper bugs. - Local Next.js build. The second line:
next buildruns 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. - 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.
- 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:
- 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 (
scripts/check-em-dashes.ts). Em dashes read as AI-generated; the framework opts for the punctuation that fits the context (colon, period, comma, parens, semicolon). - HTTP status-code integrity. 404 means not found; 500 means actual server error. Downstream consumers (crawlers, agents, monitoring) 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 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.