What 'verified' means at DEPLOY: The framework behind every signal, registry entity, and consumer page

"Verified" is a category term that means different things in different sources. A manufacturer's press release uses it for announcements the company itself has decided to make. Trade press sometimes uses it for claims an industry analyst has confirmed by talking to the manufacturer. Catalog databases use it for records that successfully ingested without validation errors. Each of these is a defensible internal meaning, and each of them produces a different artifact when a reader encounters the word on a page.

DEPLOY operates the word with a specific operational discipline. The discipline is what this page defines. Operators evaluating an autonomous-systems claim need to know which meaning a given source is using before they can evaluate the claim itself. The verified-vs-claimed framework is the structural test DEPLOY applies; everything that surfaces on a signal page, a registry entity, or a consumer overview operates against the constructs defined below.

Verified versus claimed at DEPLOY

DEPLOY treats an assertion as verified when it anchors to a counterparty other than the maker. A regulator filing, a customer of record disclosing the relationship on the customer's own surface, an independent auditor's record, or a multi-source primary record (more on what counts as a source under "Source discipline" below). The verification posture is what an operator can act on without re-running the maker's narrative; it is what a regulator, a customer, or an auditor has already confirmed against an external surface.

DEPLOY treats an assertion as claimed when it appears in maker communication, marketing material, investor decks, or self-reported disclosure without independent confirmation. Claimed assertions are editorially meaningful. DEPLOY publishes signal coverage of claim events (a maker's product announcement, a price-projection statement, a capability demonstration) because the claim is itself an editorially significant artifact. The signal frames the claim as claim, not as verified. The signal then surfaces whatever verification anchors are available to date and names the gaps where verification anchors are absent.

The boundary between verified and claimed is structural, not adversarial. A maker honestly operating a verified supervised-autonomy commercial pilot has nothing to lose by DEPLOY distinguishing supervised pilots from humanless commercial. A maker over-claiming on the hedge does. The framework's editorial position is operator-utility; makers benefit when their assertions are framed accurately relative to the verification anchor each assertion clears.

Operating envelope precision

Verification happens inside an operating envelope. A route, a facility, a load type, a weather regime, a regulatory framework, a time horizon. The envelope is itself part of what gets verified. A driverless run that cleared on an interstate corridor under FMCSA's commercial motor vehicle framework is a different artifact than a driverless run that cleared on a private industrial road under an operator-controlled framework, even when both are described in maker communications as "commercial driverless." The two clear different verification surfaces; they are not editorially equivalent.

DEPLOY names the envelope when surfacing a verified assertion. The reader sees not just "verified" but "verified within this envelope," and the envelope is published as part of the assertion. Threshold-clearing in one envelope does not automatically transfer to another; a maker that has cleared on-highway over-the-road verification has not by that fact cleared off-highway industrial verification, and the framework treats the two as distinct postures requiring distinct evidence. The framework's worked example for envelope precision lives at /methodology/operating-envelope-precision, which walks three commercial autonomous-freight deployments at three structurally distinct envelopes.

Cap-flag as trust signal

When evidence is genuinely absent (no counterparty disclosure, no regulator filing, no independent confirmation), DEPLOY flags the absence rather than estimating a plausible value. The cap-flag is the published artifact that says "verifiable evidence on this field is not present at the verification threshold DEPLOY operates." It is a transparent record of where DEPLOY stops asserting.

A cap-flag triggers on three conditions. Evidence absence: no source exists that meets DEPLOY's source-discipline threshold for the field in question. Evidence weakness: a single source exists but cannot be corroborated against an independent function. Evidence contradiction: multiple sources disagree in ways that cannot be reconciled against the maker's published record. In each case, the cap-flag names the gap; the gap itself is the verifiable artifact.

The cap-flag does not mean "we don't know" in a generic sense. It means specifically that verifiable evidence is absent at the verification threshold DEPLOY operates. Marketing-driven sources typically fill the gap with a plausible-sounding number, an industry-analyst estimate, or a maker-disclosed projection treated as fact. DEPLOY flags the absence and lets the absence be the published record. The trust-signal mechanism is that transparent absence is more credible than marketing-driven plausible numbers; the operator reading a cap-flagged field knows where DEPLOY's verification stops, which is itself useful information for downstream evaluation.

The cap-flag operates cross-cuttingly across the surfaces DEPLOY publishes. Deployment status (active, paused, ended, or cap-flagged where status cannot be verified). Capability claims (deployed-capability evidence, demo-only capability, or cap-flagged where capability evidence is absent). Pricing claims (available pricing, projected pricing, or cap-flagged where pricing evidence is absent). Regulatory coverage (regulator-filed scope, or cap-flagged where regulatory scope is absent). Incident attribution (counterparty-confirmed attribution, or cap-flagged where attribution is contested). The same construct operates everywhere DEPLOY surfaces an editorial assertion; the cap-flag is the consistent honesty-of-completeness marker.

Source discipline

Primary sources are DEPLOY's verification anchor. Regulator filings (NHTSA, FMCSA, CPUC, SEC, and equivalent jurisdiction-specific bodies) anchor regulatory and safety assertions. Counterparty disclosure (a customer's press release confirming a deployment relationship, a customer's earnings-call disclosure naming a contracted volume) anchors customer-of-record assertions. Audit records (independent auditor reports, independent third-party investigations, regulator-commissioned inquiry findings) anchor incident, recall, and safety-record assertions. Direct maker disclosure counts as primary source only when it has been audit-checked against an independent confirmation; an uncorroborated maker statement is claim, not verification.

Tier-1 news independent verification provides the multi-source corroboration that distinguishes verified assertions from single-source claims. Bloomberg, the Wall Street Journal, Reuters, the Financial Times, the New York Times, IEEE Spectrum, FreightWaves, and equivalent outlets with documented editorial verification practices function as independent verifiers because they apply their own source-discipline standards upstream of DEPLOY's citation. When a trade-press outlet reports a deployment claim, the outlet's reporting reflects multi-source verification work that DEPLOY cites as part of the verification surface.

DEPLOY's foundational signals require at least three distinct editorial functions in the source set. Not three outlets, three functions. The functions are typically: announcement (the originating record of the event), independent confirmation (an outlet or independent observer confirming the announcement against an external surface), and regulatory or counterparty disclosure (a regulator filing or a customer-of-record confirmation). Three functions test the narrative against external surfaces; one or two functions risk replicating the maker's narrative without independent test. Three is the threshold below which DEPLOY operates the signal as a responsive piece (a coverage piece that documents the event without anchoring a foundational framework angle), not as a foundational signal that anchors framework discrimination.

The source-discipline thresholds are floors, not forcing functions. When a foundational signal sits at the three-function threshold and the available editorial surfaces would only add lateral coverage rather than additional independent verification, DEPLOY accepts the threshold count as editorial discipline rather than padding the source set with mechanically-compliant but editorially-redundant additions. Transparent under-target with explicit reason is the brand-position signal.

How DEPLOY differs from marketing-driven sources

Marketing-driven sources optimize for completeness, narrative momentum, and access to maker communications. They publish what makers say, formatted for readability, on the cadence the maker chooses. Their value to readers is that the reader encounters the maker's announcement quickly and in context. Their structural cost is that they do not, by design, discriminate between verified and claimed assertions; the same vocabulary ("autonomous," "commercial," "deployed," "scaled") flows through them without being partitioned into the verification postures it actually anchors.

DEPLOY optimizes for verifiable assertion and transparent absence. Each assertion that surfaces on a DEPLOY page is either anchored to a verification source the reader can act on, or it is named explicitly as claim, or it is cap-flagged as evidence-absent. The structural cost of this discipline is that DEPLOY publishes less than a marketing-driven source covering the same category; the structural value is that what DEPLOY publishes is operator- utility, not vocabulary replication. An operator evaluating where humanoid robots actually shift cost-per-unit math today encounters a different artifact on DEPLOY's coverage than on marketing-driven coverage, because the framework partitions the claim space into verification postures the operator can evaluate against.

The framework is adversarial to vocabulary collapse, not to makers. A maker honestly operating a verified supervised-autonomy commercial pilot is editorially rewarded by DEPLOY's framework, because the framework names the maker's verification posture accurately; adjacent makers over-claiming on the hedge do not get to borrow validity from the honest maker's editorial treatment. The recursive application is that DEPLOY's own editorial discipline operates on DEPLOY's own corpus. When a foundational signal sits at the source-discipline floor with no editorially-central additions available, the signal accepts the floor rather than padding. When a field's verification evidence is absent, the field cap-flags rather than estimates. Operating the framework recursively on DEPLOY's own surfaces is the credibility mechanism.

Where to go next

The methodology cluster operates downstream of this page. The verification-framework piece walks the four verification anchors operators apply to evaluate any maker's commercial-deployment claim. The operating-envelope precision piece works through three autonomous-freight deployments at three structurally distinct envelopes. The contrast-cases piece names how the framework treats adjacent verification postures that share marketing vocabulary but anchor editorially distinct claims. Each downstream piece applies the constructs this page defines; the verified-vs-claimed framework canon catalogs the specific verification postures the framework has surfaced across DEPLOY's foundational signal corpus to date.

Operators evaluating a specific maker or category can start at the registry property (registry.deploy.report) for the structured-data view of verified entities, deployments, regulations, and incidents. Named registry cuts (verified humanoid companies, verified robotaxis, verified delivery robots, verified incidents) surface category-specific cuts of the structured data. DEPLOY's consumer surfaces will provide entity-level overviews for operators evaluating availability, pricing, capability, and safety questions at the entity layer; the methodology constructs defined on this page govern what surfaces there as verified, claimed, or cap-flagged.