What you hold, and which check can see it
The contract, the XML in the email, and the URL in the line item are three objects.
| What you hold | What to open | What it can tell you | What it cannot tell you |
|---|---|---|---|
| A VAST document | Validator | Whether Verification nodes are present and consistent | Whether the vendor scored this impression |
| A live tag URL | Tester | The response that URL returns now, including media and trackers | The chain of hops if the first response is a wrapper |
| A wrapper URL | Inspector | Each hop, and which hop dropped a node | The IVT rate either firm will publish next week |
A verification manager is the person who chose the firm. The choice shows up in this site's other notes as DoubleVerify or IAS or HUMAN or Pixalate, and the notes stop at the published figures. The job that starts after the contract is quieter: the tag that will actually serve has to carry that firm's node, or the quarterly rate and the campaign report are about different inventories. You usually do not compile anything. You have an email, a tag sheet, and a line item.
vastlint is the check on the document, not on the firm. Paste the XML into the validator when trafficking sent you the file. Paste the URL into the tester when the line item only has a request. Open the inspector when that request returns a wrapper, because the node can sit on the first hop and be gone on the inline the player plays. None of those three calls the vendor. A present node is a structure. A score is a later event from a host that answered.
What present means
VAST 4 puts verification under AdVerifications, as Verification entries with a vendor, resources, and parameters. Older tags sometimes hide the same intent in an Extension. The validator's job is whether that structure is consistent with the version the tag declares: the container is allowed to hold Verification, the vendor identifier is not duplicated, the resource URLs are well formed. A duplicated vendor identifier is a structural fault. Two different vendors in two entries can both be legitimate, which is the case when the plan really is IAS and DoubleVerify together.
Present does not mean the URL will answer. A Verification entry that still names Moat is a host Oracle stopped operating on September 30, 2024. The element can be well formed and still point at a service that will not score the impression. vastlint will not look up the business status of a vendor string. You bring the end-of-life list. The check brings the fact that the string is in the file.
Present on the file in the email is not present on the inline. Wrapper chains exist so each hop can add or drop markup. If you were shown the buyer's original XML and the line item requests a different URL, you have not yet seen the document the player parses. That is the inspector's job: walk the hops and see which response still contains the node.
What you still cannot sign off
You cannot sign off the invalid-traffic rate. A protected campaign under 1 percent, an open-auction share of 19 percent, and a named mobile cluster with a click multiple are studies of other logs. They do not become this campaign's result because the node is present. They also do not become a failure because the node is present and the firms later disagree. Disagreement on sophisticated invalid traffic is allowed by the MRC addendum. Disagreement because one node never arrived is a trafficking defect, and that is the defect this check is for.
You cannot sign off playback. A tag can carry a correct verification block and a MediaFile the television will not select. Device QA is a later pass, and it is a different page. Mixing them produces the launch-week story where verification looked fine in a browser and the completion never fired on the set.
You cannot sign off that both firms saw the impression when the plan was to run both. Count the entries after the chain resolves. One node means one log. The spreadsheet that lists two vendors is not evidence.
Get VAST spec updates, platform guides, and release notes in your inbox.
A workable pass before you reply to trafficking
Ask for both artifacts: the XML they intend, and the URL the ad server will call. If they can only send one, say which one you checked. Run that artifact. If the URL's first response is a Wrapper, do not stop. Inspect until the inline, or until the chain breaks. Then write the reply as a list of nodes found, nodes missing, and hosts you already know are dead. Leave the fraud rate out of that reply. It is not knowable from the file.
If this is a one-off tag in a thread, the website is the whole tool. If the same class of tag ships every week from a repo, the check belongs in CI so the email is not the control. If a server sees the response before the player, the check belongs in that process. Those are different seats, and they are the next note.
Reply in these columns
- XML checked, URL checked, or both. Say which.
- Verification entries found after the chain, by vendor string.
- Entries required by the contract and absent.
- A host you know is retired, such as Moat after September 30, 2024, still sitting in a well-formed element.
- Anything about IVT rate, viewability, or suitability: not in this pass. The node has to exist before those reports can.
Paste the tag trafficking will actually serve
XML opens the validator. A live tag URL opens the tester. Nothing is stored. This does not call DoubleVerify, IAS, HUMAN, or Pixalate.
Sources
What a missing or emptied verification node does to the measurement.
How verification resources sit in the tag when the framework is OMID.
The gap that is a missing node, and the gap that is a real difference in sophisticated detection.
When a one-off paste should become CI or an in-process check.