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 signed 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 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 per-step HMAC signing with 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 every subsequent signature, wavebird makes event splicing materially harder. A copied visibility event cannot be moved onto a different slot without failing signature checks or proof recomputation.

The unit of trust in the proof system is the signed event payload. wavebird uses HMAC signing because it is operationally simple, fast enough for hot paths, and deterministic across services that share the same active signer ring. For each proof step, the platform canonicalizes the relevant payload fields, binds them to a signer identifier and timestamp, and produces an HMAC over that canonical string. The signed record is then persisted with the event metadata.

The important detail is that the HMAC input is not just the event itself. It also incorporates the proof context that came before it: slot identifiers, decision identifiers, prior event hashes, and the rule version used for billing evaluation. This makes the signature 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 is not being used here as a public transparency primitive. It is being used as a platform-integrity primitive. The public or partner-facing transparency primitive comes later, when window-level Merkle roots are published. That split is deliberate. Per-event signatures prove that the platform saw a coherent sequence of facts. Published Merkle roots prove that the platform cannot quietly rewrite the set of billable candidates after the billing window closes without changing the published anchor.

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 signed 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 published root can reproduce the tree independently and compare the result byte-for-byte.

The Merkle root is the 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 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 publication 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 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.

Publication 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, 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 signed event chain needed to recompute the terminal proof hash, and the Merkle proof for that leaf. An SSP or auditor first validates the event chain locally. This means checking the canonical payload shape, recomputing the HMAC inputs 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 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 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 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, signed 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.

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.