Proof Integrity for GenAI Advertising

Traditional display advertising assumes a browser page, a publisher page view, and a chain of familiar measurement tools. GenAI advertising breaks those assumptions. A single user session can include multiple prompt-response turns, streaming UI, custom render surfaces, long-lived tabs, and application side effects that do not map cleanly to the old concept of a page impression. If an SSP is going to buy this inventory with confidence, it needs a way to answer three narrow questions for any billed event: was the slot actually rendered, did it satisfy the measurement rule for the format, and can the publisher and platform both reproduce that conclusion later.

wavebird treats those questions as a proof problem rather than a reporting problem. A dashboard chart is useful, but it is not enough. A proof system has to preserve the sequence of facts that transformed a creative decision into a billable line item. That sequence must survive retries, UI churn, batching, and post hoc investigation. For that reason, wavebird stores a chain of validated facts rather than a single mutable counter. The system records the decision context, the rendered event, the viewability or playback milestone, and the final billable state as discrete server-observed steps tied together by cryptographic context.

The design target is pragmatic. SSP partners do not need to trust a black box or reverse-engineer a UI replay. They need a compact packet that explains why an impression entered settlement. That packet must be small enough to export, deterministic enough to recompute, and stable enough that an auditor can verify it after the billing window has closed. This is the reason wavebird combines signed asset tokens, server-side event validation, hash-linked ledger records, signed snapshots, and Merkle aggregation at the billing-window level.

wavebird models impression integrity as an ordered beacon chain. The first anchor is the decision packet: a slot id, the creative decision metadata, the applicable billing rule, and the normalized policy context for the request. When the SDK mounts the creative, it emits a rendered beacon. That beacon does not claim the impression is billable; it claims only that the SDK instantiated the approved creative in a concrete slot with a concrete decision context.

The second phase is format-specific evidence. For banner and native, the relevant question is whether the creative crossed the configured viewability threshold for the required minimum duration. For clip, the question is whether playback reached the required completed state or playback-duration threshold defined by the billing rule. Those states are emitted as visibility or playback beacons, again tied to the original decision and rendered context.

A terminal billable determination is produced only after the server verifies that the required event sequence exists and that the rule attached to the slot has been satisfied. In other words, billability is not a client claim. The client can report observations. The server is responsible for applying the rule set, rejecting incomplete chains, and producing the final proofable terminal. This distinction matters because it gives the SSP a stable enforcement point and it reduces the chance that a modified client can self-assert inventory quality.

Each step carries enough data to link backward. That backward link is essential. A visibility beacon is meaningless if it cannot be associated with the exact rendered event and the exact decision packet that created the slot. By encoding prior context into subsequent server-side proof records, wavebird makes event splicing materially harder. A copied visibility event cannot be moved onto a different slot without failing proof validation or recomputation.

The hot path uses signed asset tokens to authorize placements and server-side validation to decide whether observed beacon events belong to the expected placement, decision and billing-rule context. The client reports observations. The server verifies the required event sequence, writes the result into the proof ledger, and keeps the event chain bound to the original decision context.

The important detail is that ledger entries are not treated as isolated counters. They incorporate the proof context that came before them: slot identifiers, decision identifiers, prior event hashes, and the rule version used for billing evaluation. This makes the ledger chain cumulative. If a later verifier recomputes the chain from the first decision anchor through the terminal billable event, any missing or altered step changes the derived hashes and breaks the verification flow.

HMAC-based validation is a platform-integrity mechanism and is not independently publicly verifiable without access to verification material or a trusted verification service. Where RSA-signed snapshots and public keys are published, snapshot signatures can be independently verified. Merkle inclusion can be recomputed from disclosed proof packets and the relevant shared or published root.

A single impression proof is useful for dispute handling, but settlement requires a window-level view. A partner needs to know that the billed set for a day, week, or month was fixed at close, not assembled retroactively from mutable logs. wavebird therefore computes a deterministic leaf for every billable candidate inside a billing window. That leaf includes the canonical impression proof payload, its terminal proof hash, the pricing context needed for settlement, and the identifiers required to scope the record to the correct partner and workspace.

Those leaves are sorted deterministically and aggregated into a Merkle tree. The resulting root becomes the compact representation of the closed proof set for that window. If any record is added, removed, or modified, the root changes. This gives wavebird a cheap integrity anchor that can be communicated to an SSP or auditor without shipping the entire raw window at once.

Deterministic ordering matters as much as hashing. Without stable ordering rules, the same leaf set could produce different trees on different systems. wavebird therefore fixes the leaf shape and leaf order for each window. A partner that receives the exported leaves and the shared or published root can reproduce the tree independently and compare the result byte-for-byte.

The Merkle root is the sharing or publication artifact. It is the compact commitment to the closed proof set for a billing window. In reconciliation terms, it marks the moment at which wavebird stops treating the proof set as an open operational stream and starts treating it as a stable accounting input. The shared or published root can be embedded in partner exports, billing packets, or audit records. The exact distribution channel is less important than the property it delivers: once the root has been shared, later changes to the proof set become externally detectable.

This sharing posture is especially important for GenAI inventory because much of the measurement context originates in application-level behavior rather than classic page telemetry. Partners need assurance that the platform did not simply summarize internal logs after the fact. A shared or published root provides that assurance in a form that is both compact and verifiable. It says: this was the leaf set we considered billable for this billing window at close.

Root sharing is not the same thing as public disclosure. The root reveals no prompt content and no user content. It is an integrity anchor. The underlying leaf packets can remain subject to partner scope, confidentiality controls, product tier, partner integration, and dispute-driven disclosure. That separation lets wavebird improve audit confidence without expanding the privacy surface.

Verification starts with an impression packet. That packet contains the canonical leaf payload, the event chain needed to recompute the terminal proof hash, and the Merkle proof for that leaf. An SSP or auditor first validates the disclosed event chain. This means checking the canonical payload shape, recomputing disclosed hashes in sequence, and confirming that the terminal event is consistent with the billing rule for the format and rule version attached to the slot.

Once the chain is validated, the verifier computes the leaf hash and walks the Merkle proof using the provided sibling hashes. The result should be the shared or published billing-window root. If it is not, the packet is either malformed or it does not belong to the billed proof set. If it does match, the verifier can conclude two things: first, the impression packet is internally coherent, and second, it was included in the committed proof set for that billing window.

That flow is intentionally narrow. The verifier does not need access to unrelated impressions, raw prompt data, or mutable runtime databases. It needs a leaf packet, a Merkle proof, and the shared or published root. The platform can therefore support third-party verification without turning the SSP into a privileged viewer of the entire operational system.

For SSPs, the practical implication is that wavebird inventory can be reconciled on two levels. At the aggregate level, the partner can compare counts, payouts, and the shared or published Merkle root for the billing window. At the dispute level, the partner can inspect a single impression packet without having to request access to unrelated traffic. This is useful when a discrepancy is isolated to a subset of placements, a specific wrapper, or a small number of settlement lines.

The model also makes incident handling more disciplined. If wavebird identifies a bug in a measurement path, the affected leaf packets can be scoped and audited against the closed root commitments. That is a materially better operational posture than relying on mutable counters or re-derived billing summaries with no independent anchor.

This proof model does not claim that cryptography can replace all trust. It does not prove that a human watched the ad, that the creative was persuasive, or that fraud can never occur. It proves something narrower and more useful for settlement: the platform observed a specific event chain and committed that chain into a closed proof set whose integrity can be checked later.

It is also not a privacy-bypass system. The design intentionally avoids disclosing raw prompt text as part of proof verification. Proof integrity is achieved by signing operational facts and anchoring them with Merkle commitments, not by exporting more user data to partners. That distinction matters because GenAI monetization only works long term if the proof layer strengthens auditability without eroding the firewall boundary.

This whitepaper describes wavebird's proof-integrity design and current implementation direction. It is not a warranty, audit certification, or representation that every integration exposes every verification artifact.

Finally, this paper does not describe a public blockchain publication model, a third-party measurement SDK, or an on-device attestation scheme. Those may be future extensions, but they are outside the scope of the current system. The current system is designed to give SSPs and auditors a reproducible, privacy-bounded path from impression evidence to billing confidence.