Methodology
Cap-flag as trust signal
Cap-flag is the published verification state. Transparent under-target with a stated reason. Recursive across every surface, including our own attribution layer.
What cap-flag is
A cap-flag is a published artifact. It is the field on a record that says: verifiable evidence on this claim is not present at the verification threshold we operate. The cap-flag is visible. The reader sees the absence; the reader sees the reason; the reader sees what would have to surface to remove the cap-flag.
Cap-flag is not a hedge. We do not use cap-flag to soften a claim we are uncertain about. We use cap-flag to name a specific evidence gap on a claim that would otherwise read as more certain than the evidence supports.
Cap-flag is not a footnote. The cap-flag carries the same editorial weight as the rest of the record. A reader who stops at the cap-flag has read the substantive state of the field; the underlying claim is the partial state of evidence alongside.
The three triggers
A cap-flag fires on three conditions.
Evidence absent. No source meeting the verification threshold exists for the claim. The claim may be reported elsewhere; no primary source resolves it at the depth we operate.
Evidence weak. A single source exists but cannot be corroborated against an independent source at the verification threshold. The claim is preserved with the source attribution; the cap-flag names the missing corroboration.
Evidence contradicted. Multiple sources disagree in ways that do not reconcile against any maker, regulator, or counterparty surface. The cap-flag names the contradiction; the underlying sources stay visible on the record.
Transparent under-target with a stated reason
When a foundational signal sits at the source-discipline threshold and the available editorial surfaces would only add lateral coverage rather than additional independent verification, we accept the threshold count as editorial discipline rather than pad the source set with mechanically- compliant but editorially-redundant additions.
The transparent under-target is the brand signal. A publication that pads a thin source set to meet a stated threshold loses the discipline that the threshold encoded. The cap-flag at under-target with the stated reason preserves the discipline and surfaces the reasoning. The reader sees why the signal is under-target; the reader can evaluate the reasoning against the signal's substantive content.
Honesty as strength, not coverage as strength
A maker-driven publication optimizes for coverage. The maker said the thing; the publication publishes the thing. The coverage builds momentum and reader velocity. The structural cost is that the publication does not discriminate between verified and claimed assertions; the same vocabulary flows through coverage at every verification posture.
A discipline-driven publication optimizes for verifiable assertion plus transparent absence. Each assertion is either anchored at a verification source the reader can act on, or named explicitly as claim, or cap-flagged as evidence- absent. The publication publishes less than a maker-driven source covering the same category. The publication's structural value is that what it publishes is operator- utility, not vocabulary replication.
The honest-absence is the operator-utility output. The reader looking at a cap-flagged field knows where the verification stops. The cap-flag is itself useful for downstream evaluation. The reader can decide whether to act on the partial evidence; the reader can decide whether to wait for the cap-flag to resolve; the reader can decide whether the absence itself is editorial signal.
Worked examples
Phase 3 Dim 1 actuarial substrate carries 128 null entries on the deployment exposure_hours column at honest-absence cap-flag. The 128 deployments do not have publicly disclosed exposure-hours data; we do not estimate. The null is the verified state for those 128 records. The verification posture is honest-absence at full-substrate scale; coverage- completeness would require fabricating exposure-hour estimates that no primary source supports.
Stryker Q3 2024 revenue of $16,159M anchors the SEC- verified-figure-with-narrower-precision cap-flag pattern. The nine-month Q1-Q3 revenue is verified at SEC 10-Q depth. The full-year 2024 figure has not yet surfaced at the authoring date. We use the SEC-verified narrower-precision nine-month figure rather than extrapolating to a fabricated full-year figure. The cap-flag is explicit: revenue is nine-month per the Q3 10-Q; full-year not captured at authoring; verified-vs-claimed at sub-fiscal-period granularity.
Boston Dynamics standalone revenue is honest-absence cap- flagged. Boston Dynamics is a Hyundai subsidiary; standalone revenue is not separately disclosed; we record null with the cap-flag note. The counterparty-risk classification at low is verified at parent-backing depth; the standalone revenue stays honest-absence. Two facts on the same record at different posture levels both surfaced explicitly.
Apptronik, Figure AI, and 1X Technologies all carry honest- absence on cash_runway_months across the Phase 3 Dim 2 substrate. None of the three publicly discloses cash runway. The cash_runway_basis stays null per the validator-aware discipline (no basis when no figure exists). The verified state is honest-absence at full-population scale; aggregator coverage frequently estimates these figures from funding announcements, which is fabrication at the runway-class- extrapolation depth.
The recursive application reaches the publication's own JSON-LD attribution layer. Person Ben Smith on /about previously held empty sameAs because no publicly- verifiable profile URL was on record. The empty array was the verified state for the field; the discipline did not allow inferring or fabricating sameAs URLs to fill a schema.org enrichment slot. The recursive application: if we will not fabricate evidence on subjects, we will not fabricate evidence on ourselves either.
The Apptronik Apollo per-deployment throughput is cap- flagged at evidence-absent across Mercedes-Benz, GXO, and Jabil pilots. The contracts are verified; the per-deployment throughput data is not yet published. The cap-flag is the honest verification state; we do not estimate throughput from announcement-stage funding or contract-value framing.
Cap-flag operates across every surface
The same cap-flag construct operates across the editorial coverage layer (signal pages, framework-in-action narratives, methodology pillars), the registry layer (entity records, deployment records, incident records, regulatory_filing records, patent records), the consumer layer (pricing pages, service-availability pages), and the publication's own attribution layer (JSON-LD Person and NewsMediaOrganization nodes, sameAs enrichment, methodology metadata fields).
The cross-surface uniformity is the credibility mechanism. A cap-flag on a registry record surfaces a cap-flag on the consumer page that draws from the record, surfaces a cap- flag in the news editorial coverage that references the record, surfaces a cap-flag in any state-change notification that fires on the record. Coverage of a cap-flagged claim does not silently upgrade the claim to verified on a downstream surface; the cap-flag flows through.
The framework applies to us
If we ship a record without a cap-flag where the evidence should have surfaced one, we add the cap-flag. If we ship a cap-flag where the evidence does in fact resolve, we remove the cap-flag and record the verification path. The posture moves only when the evidence moves.
The cap-flag history is preserved. When a cap-flag is removed because primary-source evidence resolved, the prior cap-flag state stays in the record's source history. A reader can see what we held cap-flagged when, and what the resolution looked like. The same discipline that surfaces cap-flagged claims surfaces their resolution paths.
The correction is logged at /corrections when a cap-flag is added or removed in response to a primary-source disclosure. The original state and the updated state both stay visible.
Where to go next
The methodology canon: /methodology/what-verified-means for the core verified-vs-claimed framework, /methodology/verification-posture for the per-claim posture taxonomy that cap-flag operates alongside, /methodology/contrast-cases for cases that look verified but resolve at a different claim posture under the framework.
The applied work: registry.deploy.report for the canonical entity records with cap-flag markers per claim; the consumer property deploy.report for the pricing and service pages where cap-flags surface in the consumer view.
Continue reading
- What verified means at DEPLOY → the core framework: verified versus claimed, operating envelope, cap-flag as trust signal, source discipline.
- How DEPLOY assigns verification posture → per-claim posture taxonomy that cap-flag operates alongside; the 8 source-quality tiers and 4 confidence tiers.
- Contrast cases in DEPLOY’s framework → worked examples that look verified at surface read but resolve at a different claim posture under the framework.
- Corrections journal → cap-flag adds and removes are logged here; original state and updated state both preserved.