> 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/run-deterministic-synthetic-delivery-checks.md). # Run deterministic synthetic delivery checks Run repeatable audio and video delivery checks without creating listener, billing, or money effects. Podigee Audio Video Ad Server can run a repeatable delivery check against a migration candidate or delivery profile. After the first mention, this article uses Podigee Ad Server for the product name. The check exercises approved audio, video, range, HLS, consent, geography, fallback, and tracking cases without changing what listeners receive or creating a paid result. Use this task before a migration cutover, after a connector change, or when a delivery profile needs proof. It is a verification run, not a listener test and not a Campaign delivery. ## Before you start * You have permission to run a synthetic delivery check. * The candidate release or delivery profile is available in a non-live environment. * You know the podcast, media, ad break, and targeting cases that must pass. * You have a clean baseline or an approved comparison run. * You know who reviews a failure and who can decide whether a difference is accepted. Do not use a synthetic check to report impressions, update Campaign delivery, or prove production revenue. It must have a zero-economic-effect marker. ## Choose the check profile Select the smallest approved profile that answers the question: * **Delivery smoke:** progressive audio, HLS, cache, and event checks. * **Platform smoke:** HLS and connected platform behavior. * **Full conformance:** all approved delivery fixtures for the candidate. Run the full profile when a migration or delivery authority change is being considered. Use a smoke profile for a focused correction or repeat check. ## Open the check task 1. Open **Monetization > Revenue jobs**. 2. Select **Reliability and support**. 3. Select **Run deterministic synthetic delivery checks**. 4. Select the candidate version or delivery profile. 5. Select the approved test profile and affected podcast or delivery scope. 6. Confirm the target environment is not live. 7. Confirm **Non-billable check**. 8. Select **Run checks**. Podigee stores the candidate, fixture profile, scope, and check request before the run starts. ![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 run When the run finishes, check: * Audio bytes, durations, formats, and progressive ranges. * HLS playlists, segments, interstitials, and video variants. * Consent, geography, targeting, frequency, fallback, and no-fill decisions. * Cache behavior and origin requests. * Tracking, analytics, and event receipts. * The candidate version, fixture profile, and exact run digest. * Billable events and commercial state changes. Both must be zero. Compare the result with the approved baseline. A difference is not safe because the media still plays. Check the decision, cache, event, and commercial evidence together. ## Decide the result * **Passed:** all required fixtures match the acceptance rules and the run has no economic effect. * **Passed with an accepted difference:** every difference has an approved reason, owner, and review record. * **Failed:** one or more required fixtures, evidence checks, or zero-effect checks failed. * **Unavailable:** the candidate or test runner could not complete. Keep the candidate inactive. Do not treat a failed or unavailable run as a cutover approval. ## If the run fails 1. Open the result and identify the first failed fixture. 2. Keep the candidate inactive. 3. Save the media, request, decision, event, and cache evidence for the failure. 4. Correct the candidate or delivery configuration. 5. Start a new run with a new candidate digest. Do not overwrite a failed run or edit its evidence. If the same fixture fails again, escalate it to the owner of the affected delivery surface. ## If Podigee blocks the check * **The profile is not approved:** select an available profile or ask the reliability owner to register the required fixture set. * **The candidate is live:** stop. Run the check against a non-live candidate. * **The non-billable marker is missing:** enable it before submitting. * **The candidate release is incomplete:** prepare the missing media, decision, or delivery artifact. * **The runner is unavailable:** keep the candidate inactive and retain the request for a later run. * **A commercial effect appears:** stop the run, investigate the boundary, and do not use its result for billing or cutover. ## Expected result You have a repeatable, inspectable result for the selected audio and video delivery cases. The candidate remains inactive until the result passes, and the run creates no billable event, paid delivery, or commercial state change. ## Next useful tasks Use [Plan a safe migration](/documentation/grow-and-monetize/monetization/plan-a-safe-migration.md) when the candidate is part of a migration. Use the parity comparison task after the synthetic run has a clean, reviewed result. --- # 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/run-deterministic-synthetic-delivery-checks.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.