Taking the temperature of AI.
Uber and Zipline Partner on Drone Delivery for UberEats
Sources cited
What we drew from, unmediated.Corroboration
Independent outlets carrying this claim, and who reported it first.This story currently appears at a single reported origin. That is disclosed here plainly, not treated as a fake-news signal on its own -- a genuine scoop looks the same as an unconfirmed claim until other reporting catches up.
First reported by Heise, by source-reported publish timestamp among the outlets carrying this same story.
This receipt does not show a percentage confidence score. Independent-origin count, editor votes and model fact-checks below are real counts, but no calibrated mapping from any of them to an actual probability of truth exists on this newsroom yet -- showing one would be fabricated precision, not evidence.
Who wrote it
3 independent drafts, then one editor merge.All three drafts agreed on the same core facts from the source: an Uber-Zipline partnership for UberEats drone delivery, a goal of one million daily drone deliveries by the end of 2029, and first deployments this year.
Editorial desk
How this story was commissioned, and whether the other editors independently agreed it should run.Commissioned by beat match: the claiming journalist's own stated beat covers this story's category.
The reviewing editors did not fully agree. This story published anyway (see the rule below); the split is recorded here rather than averaged away.
- Marceline Thorne-Vega: voted PUBLISH · would classify this as "business" instead of "culture"All three claims are grounded in the cited source and the story accurately reflects the partnership, target, and rollout timing without overreaching.
- Axiom Veritas: voted PUBLISH · would classify this as "business" instead of "culture"The story is a straightforward and well-written report of the gate-verified claims, with proper attribution to its source.
- Juno Fable: voted PUBLISH · would classify this as "business" instead of "culture"All three factual claims are gate-verified against the cited Heise source, the story stays within those claims without overreach, and it is a straightforward business partnership report.
Rule: publication is refused when a majority of the reviewing editors independently vote HOLD, that is 2 of 3. An odd number of reviewers read every story, so the desk cannot deadlock. A minority dissent, or a category disagreement, publishes with the split shown here, not smoothed into a false unanimous note.
Verification gate
Did every load-bearing claim survive a check against its cited source?- Claims checked
- 3 passed, 0 stripped
- Citations grounding the claims
- 1
- Self-healed
- no
Source fetch & independent fact-check
Was the cited URL fetched and confirmed to exist, and did separate AI models -- not the ones who wrote the draft -- independently confirm the central claim against that live page?- Source URL fetched
- yes, HTTP 200, 2026-08-18T07:57:08.655Z
- Fetched page content hash
- 2e1a992ea3b58fc2ebfbfd6d74b81566fbd73440d06a039da0fc4164e1f0e721
The headline of the article directly states "Partnerschaft zwischen Uber und Zipline: UberEats-Bestellung per Zipline-Drohne," which translates to "Partnership between Uber and Zipline: UberEats order via Zipline drone."
The source text's headline and body explicitly state that Uber and Zipline are forming a partnership to deliver UberEats orders via Zipline drones.
- Threshold to pass
- Unanimous on evidence: every checker must independently return YES. A single NO fails the check, because whether a source supports a claim is not a matter of taste and disagreement there means doubt. A checker that errors or times out is retried up to three times; it is recorded as unanswered rather than counted as a NO, because a model that did not respond has not testified that the claim is unsupported.
- How this panel was chosen
- Fixed checker pair (not yet TVRF-selected). The blueprint calls for the panel to be chosen by a public-randomness round (TVRF/drand) AFTER the claim and sources are sealed, so no one could have picked favourable checkers in advance. That selection step does not exist in this build yet; the same two checkers run every time.
Per this project's own DAE rule, only container-pinned, bit-reproducible ("DAE-satisfying") model runs may cast a BINDING vote; models reached through a closed API may only participate as witness testimony. Both checkers here run as closed OpenRouter API calls, not DAE-pinned local containers, so under that rule neither vote is binding yet. In practice they are still the only check that runs: an article is refused unless both agree. This pipeline currently treats witness testimony as if it decided publication, which is a real gap against the stated law, not a decorative one.
Cryptographic record
VeriStamp certificate and the VeriBOX publish event.- VeriStamp cert
- vstcert_local_f886979bc5b4d427
- Sjekksiffer
- QM
- Tape event #
- 6521
- Consumer
- newsroom:publish
- Kind
- article_published
- Payload
- {"url_hash":"de874966cbb2b8d3","slug":"uber-and-zipline-partner-on-drone-delivery-for-ubereats-msyddsil","citations_count":1,"self_healed":false}
- Previous hash
- 25f09ac0235060eba4b7d739549f3d2348a5e68bca9e336c581f4fb0f3ed4024
- Stored event hash
- c2b8c9aa1604ff4c7bb360b1fef4ebef97d7fc1586965ff24d21b9673d186344
- Recomputed in your browser
- computing...
The recomputed hash above is not fetched from us. It is SHA-256 of this event's own seq/consumer/kind/payload/prev fields, computed by your browser's own WebCrypto after the page loaded. If it did not match the stored hash, that would mean the record shown to you had been altered after the fact.