> For the complete documentation index, see [llms.txt](https://docs.podigee.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.podigee.com/documentation/grow-and-monetize/monetization/compare-shadow-decisions-and-prove-parity.md). # Compare shadow decisions and prove parity Compare a live baseline with a candidate release and prove that shadow work has no paid effect. Podigee Audio Video Ad Server can compare a current delivery baseline with a different candidate release before a cutover. After the first mention, this article uses Podigee Ad Server for the product name. Shadow comparison lets you inspect the candidate without changing listener delivery, Campaign economics, or billing. Use this task after the candidate passes its synthetic delivery checks. The comparison must use two different, exact releases. It is not a production switch and it cannot create an impression, a paid delivery, or a financial event. ## Before you start * You have permission to run a shadow comparison. * The current delivery baseline is healthy and identified by its exact version. * The candidate release is prepared, available, and identified by its exact version. * The candidate has passed the required synthetic delivery checks. * You know the sample profile, sample limit, acceptance rules, and parity reviewer. Do not compare a candidate to itself. Do not run the comparison when the baseline or candidate has changed after it was selected. ## Open the comparison task 1. Open **Monetization > Revenue jobs**. 2. Select **Reliability and support**. 3. Select **Compare shadow decisions**. 4. In **Baseline release**, select the current delivery release. 5. In **Candidate release**, select the different release to compare. 6. Select the approved comparison profile and sample limit. 7. Confirm **Zero economic effect**. 8. Select **Run comparison**. Podigee stores both release references and their exact digests before it starts. It stops the task if the releases are the same, missing, or changed. ![The current One Podigee Integrations page shows Cedar Vale Stories in shadow mode, the existing delivery safety notice, the recheck control, and the safe-switch checklist.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-420a27a5d3c2ed105bfe4b6aad2788ec3863ea1c%2Fdoc-monetization-055-shadow-checks.png?alt=media) *Use shadow mode to prepare and verify delivery while the existing podcast stays live.* ## Review the comparison Review the baseline and candidate together: * Candidate and baseline release identifiers and digests. * The comparison profile and sample limit. * Audio and video media results, including HLS and progressive delivery when in scope. * Decision reasons, targeting, frequency, pacing, fallback, and no-fill outcomes. * Cache, origin, tracker, analytics, and event evidence. * Campaign delivery, booked value, billing, and money effects. * The comparison digest and result state. An output that looks correct in the player is not enough. A parity result must explain any media, decision, event, or commercial difference. ## Decide whether parity is proven * **Parity proven:** the required sample matches the acceptance rules and the comparison has zero economic effect. * **Accepted difference:** each difference has a documented reason, owner, scope, and approval. It must not hide a listener, delivery, billing, or measurement risk. * **Parity blocked:** one or more required results differ without an approved explanation. * **Comparison unavailable:** the run could not complete or its evidence is incomplete. Only a proven or explicitly accepted result can proceed to a cutover review. A blocked or unavailable comparison keeps the current delivery authority in place. ## Confirm the zero-economic boundary The result must show: * **Zero economic effect**. * **0 billable events created**. * No Campaign delivery, reservation, invoice, or money state change. * A comparison digest that can be matched to the two selected release versions. If any paid or commercial effect appears, stop the migration and report the boundary failure. Do not use the result to approve a cutover. ## If the comparison fails 1. Keep the current delivery authority live. 2. Open the first failed difference and identify its affected surface. 3. Preserve the baseline, candidate, request sample, media, decision, event, cache, and money evidence. 4. Correct the candidate or record an approved, bounded difference. 5. Run a new comparison with a new candidate digest. Do not overwrite a failed comparison or change its evidence after the result is recorded. ## If Podigee blocks the comparison * **The releases are the same:** select a different candidate release. * **A release changed:** select the current exact version and rerun the synthetic checks first. * **The candidate is missing:** prepare and verify the candidate before comparison. * **The profile is not approved:** choose an available comparison profile or ask the reliability owner to define one. * **The zero-effect boundary is missing:** enable it before submission. * **A paid event appears:** stop, preserve evidence, and escalate the boundary violation. ## Expected result You have an evidence-backed comparison between two exact releases. The current delivery remains live, the candidate stays inactive, and the comparison creates no paid delivery or financial effect. The result is ready for a separate cutover decision only when parity is proven or every difference is explicitly accepted. ## Next useful tasks Use [Run deterministic synthetic delivery checks](/documentation/grow-and-monetize/monetization/run-deterministic-synthetic-delivery-checks.md) when the candidate itself has not passed its delivery fixtures. Use [Plan a safe migration](/documentation/grow-and-monetize/monetization/plan-a-safe-migration.md) when the source scope or rollback boundary must change. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.podigee.com/documentation/grow-and-monetize/monetization/compare-shadow-decisions-and-prove-parity.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.