Application of the Canon
Advertising provenance and independent verification
Evidence on advertising context, declared placement rules and delivery, for advertisers, platforms, creators and regulators. Start with the evidence architecture. Keep record duties aligned between platforms and advertisers. Make verification independent and reproducible.
Runnable demo today. Not a hosted integration, and no claim of independent commercial certification.
Orthogonal claims
Different promises need different evidence
If the promise is contextual
The question is where the ad appeared relative to the content it invoked. Check placement records, the declared context the platform used, the content session evidence, and any correction trail once a placement claim is disputed.
If the promise is audience targeting
The question is whether the recipient matched the declared criteria. Check the declared signal and the decision rationale record, and only infer what the platform disclosed. This page does not claim to verify attention, cookies or identity, and nothing here listens for ambient clues. The declared signal is on the record.
The race weekend sequence
One story across Friday, Saturday and Sunday
A sequential sponsor campaign is a real, working pattern. Ford described using Apple TV’s sequential advertising to progress a micro-docuseries from Friday practice through the Sunday Grand Prix. The assurance question that follows is specific and answerable: did the approved creative run in the agreed race-weekend context and sequence, and what evidence can a separate party check?
A signed placement decision declares the creative, the slot and the context rule before any impression. The decision predates delivery.
Delivery records carry the frame order and session context. Declared placement is checked against the sequence contract, not taken on faith.
A viewer taps during the race. The click, the merchant landing and the billing proposal each become records a separate party can check, including later corrections.
The demonstrator below shows that Sunday tap in full: one viewer, one ad, one billing question, and everything needed for anyone to rerun the checks.
The synthetic demonstrator
One tap, and a record you can check
Steve, a fictional viewer, sees a fictional racing shoe in a fictional feed during a race weekend. He taps. If a charge follows, it shows. If the charge is wrong, the correction shows too, and the original wrong record stays visible.
Steve sees the creative
One tap, one impression link
Landing record, not a sale claim
What Loop declares on the record
Anyone can rerun the verifier
Policy checked, corrections kept
The signed placement decision predates both the impression and the click, so delivery can be checked against what was declared in advance, not reconstructed afterward.
Loads one embedded frame from this same origin. Or open the demonstration directly.
Everything inside the frame is fictional: Kuma Shoes, Apex Racing, Loop, the viewer Steve, and the demo keys. It is not connected to or endorsed by any real race series, platform or shoe brand.
Same click, different evidence
Six scenarios, real verdicts
Each scenario recomputes the checks live in your browser. Nothing is preset. A signed record whose signature is valid can still fail policy, and a correction never erases the invalid original.
| Input | Integrity | Policy | Coverage | Decision |
|---|---|---|---|---|
| Clean signed declaration, allowed context, current policy, full set and charge at the agreed rate | Pass | Pass | Complete | Accepted |
| Tampered declaration | Fail | Not reached | Complete | Rejected |
| Signed overcharge above the agreed rate | Pass | Fail | Complete | Rejected |
| Missing decision | Pass on available records | Not reached | Incomplete | Unverifiable |
| Stale policy superseded before flight | Pass | Fail | Complete | Rejected |
| Valid correction | Pass | Pass after corrected charge | Complete | Accepted, with the original invalid proposal kept on the record |
The edge of the evidence
Check the claim without overstating the proof
What the code checks
Signature validity against pinned demo keys, record hashes, cross-record links, policy version, allowed declared context, fixed-clock freshness, and the charge against an agreed integer-cent rate.
What the record does not settle
That a real person tapped, that the platform actually used its declared placement reason, that a sale happened, or that advertising caused incremental revenue. A tap cannot prove why an earlier ad was selected.
Independent code, simulated trust
The verifier reruns separately. In this demo Hive controls the source roles, events and keys, so this is not independent commercial certification. Real deployment would need authenticated sources, governance, privacy controls and independent key custody. Hashes and signatures do not establish that a source told the truth.
Composition
An application of the Canon, not a new primitive
Every behaviour above is built from receipt types already published in the Canon. The placement decision is an authority record. Impressions and the tap are observation records. The billing proposal, its rejection and the corrected charge are the Morning After pattern, and the correction reaches anyone who recorded reliance on the invalid proposal without resending privileged data through correction-only continuity. The demonstrator uses demo RSA keys in its own format; that is not Hive’s production receipt format, and nothing here defines one.
How this reaches buyers
Two routes to adoption, chosen by whoever starts
A buyer defines a completeness test
Pick one buyer with a defined requirement. Let them write what a sufficient record would contain and what evidence would make it closeable. Hive then runs the evidence against the buyer’s own workflow.
A verification service premium
If a provider wants to add signed provenance as a premium verification layer, Hive supplies the evidence layer and the provider keeps its existing integration path. The provider can declare placements with provenance fields and run a checkable completeness route.
Buyer rubric
| Ask | Why |
|---|---|
| Declare which records close a disputed placement and which evidence types are mandatory | Rubrics without required fields devolve into soft claims |
| Treat the written correction as part of the same record family | A correction notice is not a separate truth, it continues the original commitment |
| Set the completeness criteria before any agent answer counts | A threshold defined later is not a safeguard |
| Decide whether the final word is a single authority answer or an attestable workflow | Only then can deficient answers be flagged honestly |
| Remember that an honest no-receipt answer is valid evidence | Absent signed records should be readable, not smoothed over |
| Design for future auditing even when today’s trust is full | Short-term record shortcuts are hard to walk back |
| Accept that buyer-side privacy rules still apply to the platform | Provenance does not entitle new surveillance of viewers |
Data handling. The demonstrator runs entirely in your browser from static files. Records stay inside one fictional organization today; in a real procurement, evidence from live data sharing would be evaluated against the privacy requirements that apply. This page records an anonymous visit count, like every Hive page.
Test it against one of your own campaigns
Pick one campaign and one disputed placement. Agree the success criteria first, then run the same checks on synthetic records shaped like yours.