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 audit-first habit, the layered verification cluster, the codification restraint, and the standing rules that govern every commit on the registry.
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 editor 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.
Slug-audit verification operates at finer granularity: before treating any entity as net-new, the editor 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).
Layered verification discipline
DEPLOY’s framework discipline operates on DEPLOY’s own work, not just on the registry data. Multiple verification layers, at distinct architectural granularities, catch errors type checks alone cannot:
- Type checking + data-layer regression suite. The first line:
tsc --noEmitplus a regression suite that covers shape validity, helper logic, and cross-reference integrity of the framework typed- const. Catches malformed types, broken references, and unit- level helper bugs. - Local build. The second line: a full production compile runs 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.
- Rendered-surface verification on canonical examples. The third line: render the methodology surface on a canonical worked example pair, check the output against expected role semantics, iterate before scaling. Catches cross-reference role-anchoring semantics that only the rendered surface reveals.
- Multi-file edit verification. The fourth line: when applying changes across a multi-file workstream (typed-const + barrel re-export + dispatcher wiring + tool registration), explicitly verify each file landed before declaring the change ready. Verified by grep-counting expected symbols in each touched file before committing.
- Loop-closing surface verification. The fifth line: after a registry-side data change responds to a verification finding, confirm the fix on rendered surfaces across every consuming property (HTML, markdown mirror, JSON-LD) before declaring the loop closed. Catches partial- fix state where the data layer is correct but a consuming surface still renders the prior state.
Each layer catches what the previous layer misses. The discipline IS the verification authority position operating recursively: DEPLOY’s framework verifies the physical-AI sector; DEPLOY’s discipline cluster verifies DEPLOY’s framework.
Skeleton-first surface design
Surface code ships ahead of data via honest-absence skeleton and auto-emit on data arrival. Entity-page blocks return null when no data exists; renders populate as the editorial corpus expands. The structural surface is in place at every entity type before the verified records that fill it arrive, so new records reach readers, crawlers, and downstream consumers immediately and consistently.
Companion auto-sync: documentation surfaces iterate typed- const reference data so new endpoints, new tools, and new vocabulary populate the documentation pages automatically as the underlying registry grows.
Codification restraint
Architectural patterns and framework angles do not get codified from a single observed instance. The discipline: one instance is anecdote; two instances are coincidence; three instances are a pattern. Codification (canonical-anchor entity or surface artifact) waits for the third instance.
The cost of premature codification compounds: surface artifacts inherit the pattern as canonical before the pattern itself has shown it survives generalization. Restraint at the codification layer protects the surface from artifacts that would later embarrass the 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 callable surface; one transparency page per commit when shipping editorial-discipline documentation. The cadence keeps each change auditable, reviewable, and revertible. The git log is the first-class editorial change log.
Framework-laden response discipline: every callable-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), and news.deploy.report (editorial publication). The properties share the same canonical entity graph and the same framework rubric. A reader cross-checking an entity across the three properties sees the same verification posture, the same cap-flags, and 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. The corrections journal is canonical here (the append-only data is the source of truth).
Standing rules
A small set of rules apply to every commit. 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, and honest empty results on framework analysis tools are the editorial differentiators. The framework refuses to pad.
- 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 hosted on the registry’s own storage or via 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, and 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.