When the Ad Schema Comes Back Empty: A Prompt That Skips a Row

A skip instruction has three moving parts. Write them separately, then assemble.

1. A fixed sentinel. Choose one exact JSON object that can only mean "no row." It must be syntactically distinct from a legitimate extraction, so a validator can branch on it without heuristics. Keep the key set small and frozen.

{"status":"skip","reason":"<reason_code>","missing":["price"],"confidence":0.0}

2. A confidence threshold. Ask the model to report a confidence for the whole row, not per field, and give it a number below which it must skip. Thresholds are only meaningful if you calibrate them, and calibration requires reviewed samples. Start with a value you can defend, then adjust using your own reviewer verdicts rather than a rule of thumb copied from a blog.

3. A reason code from a closed list. Closed lists are what make the skip data countable. If the model may invent a reason string, you get three hundred spellings of "missing price" and no way to group them. Compare this to the field-extraction discipline used in bulk copy analysis, where each ad is broken into fixed enumerated fields with an explicit unknown value and models are told not to invent values the ad clustering walkthrough.

A practical starting list:

The distinction between blocked_or_empty and missing_required is the single most useful split in the table. One is an infrastructure problem, the other is a modeling problem, and they route to different people.

Write the skip rule as a hard constraint with a negative example. Models follow rules best when the forbidden output is shown next to the required one. The Perplexity agent prompt guide makes the same point in a different context: put role, formatting and grounding rules in the instructions parameter and keep hard constraints out of prose where a request parameter can enforce them the Perplexity prompt guide. Your equivalent of a request parameter is a schema-validated response format, which should reject anything that is not a valid extraction or a valid sentinel.

A minimal prompt block:

You extract ad creative from one landing page.

Required fields: headline, body, cta_text, price, destination_url.
Every required field must be supported by text visible on the page.

Rules:
1. If any required field cannot be supported by visible text,
   return exactly:
   {"status":"skip","reason":"<code>","missing":[...],"confidence":0.0}
   and nothing else.
2. reason must be one of: missing_required, low_confidence,
   ambiguous_value, blocked_or_empty, schema_gap, off_domain.
3. If your overall confidence is below 0.7, skip with
   reason "low_confidence".
4. Never guess a price, discount, or URL. Never return an empty
   string for a required field. Never return an empty object.

Forbidden: {"headline":"","price":null}
Required when price is absent: {"status":"skip","reason":"missing_required","missing":["price"],"confidence":0.0}

Three details matter more than they look. First, "supported by text visible on the page" gives the reviewer something to check against. Second, the forbidden example is the exact failure you have probably already seen in production. Third, rule 3 puts the threshold in the prompt rather than in a post-processing step, so skips are labeled with the reason the model itself believed, which turns out to be more diagnostic than a post-hoc score.

Validate the sentinel in code, not just in the prompt:

SKIP = {"status": "skip"}

def classify(raw: dict, schema_required: set[str]) -> str:
    if raw.get("status") == "skip":
        return "human"
    if not schema_required.issubset(raw.keys()):
        return "human"
    if any(raw[k] in (None, "", []) for k in schema_required):
        return "human"
    return "accept"

Returning human for a malformed non-sentinel output is deliberate. A response that is neither a valid extraction nor a valid skip is a fourth state the prompt did not anticipate, and it belongs in the same queue, tagged separately.

Most extraction pipelines have two branches: auto-accept above threshold, auto-reject below it. That ladder has a hole. Auto-reject silently discards a row that a human could resolve in seconds, and it destroys the evidence that something changed on the page.

The three-branch ladder fixes the hole:

The decision rule for where a case lands is not confidence alone. Ask one question: can a person with the page in front of them produce the correct row in under a minute? If yes, route to human. If no, because the page is gone or the ad was pulled, auto-reject and count it. Getting this wrong is how a review queue fills with unresolvable items and reviewers stop trusting it.

Human review as a formal step is not unusual in extraction systems. Appian's extraction documentation describes a user reconciliation task as part of the extraction process, where a person manually confirms the data was extracted correctly the Appian extraction docs. The same docs advise giving the model a lot of context, comparing prompt design to onboarding a new employee with examples and guidelines the Appian extraction docs. That framing is useful for the skip instruction too: a reviewer needs the model's examples of what "missing" looks like, not just the word.

The skip record is the product of this whole design. Log enough at the skip point that a reviewer can act without opening a terminal, and that an engineer can debug without asking the reviewer what they saw.

For the reviewer: the source URL, the reason code, the list of missing fields, a screenshot or the fetched HTML, the model's raw output, and the ad identifier. That is a complete worklist entry.

For the engineer: the extractor build, the prompt hash, the selector version, the HTTP status and final URL after redirects, and the byte size of the fetched HTML. The last two catch the most common silent failure, which is a redirect to a consent page that returns 200 and no ad.

The pydantic human review documentation offers a pattern worth copying: an annotation queue gives reviewers a curated list of runs to inspect one after another rather than asking them to find runs manually, and tagging verdicts with labels such as tool error or hallucination helps reviewers find related cases the Logfire human review guide. Your reason codes are those tags. Keep the queue sorted by reason code and by frequency, not by arrival time, so reviewers see runs of similar problems and get faster at them.

One caution from the same source: comments on reviewed runs can contain user data and should be treated like other production data the Logfire human review guide. Ad copy and page HTML can include personal data in testimonials and review widgets. Store the fetched HTML under the same retention rules as any other scraped content.

Suppose a batch of 10,000 ad URLs and landing pages. The extractor returns 7,400 clean rows, 2,100 skips, and 500 malformed outputs that get queued as well. That is a 26 percent human rate, which sounds alarming until you break it down by reason code:

Read this table and the priority is obvious. The single largest bucket is one selector family, and fixing it removes about 11.5 percent of the batch from the queue. The schema_gap bucket is small but the most strategically interesting, because each entry is a promise the model cannot express. Schema.org's Offer type carries dozens of properties for exactly this reason, including availability windows, advance booking requirements and delivery methods the Schema.org Offer type. If your schema has three price fields and the market uses twelve, the gap bucket is telling you where to extend.

Two derived rates are worth putting on a dashboard: skips per 1,000 URLs (tracks extractor health over time) and human resolution rate within 24 hours (tracks whether the queue is actually working). The first moving up without a corresponding rise in blocked_or_empty almost always means a source site changed its markup.

Google's own guidance on structured data is a useful reminder that machine-readable claims about a page should be validated rather than assumed, and it points to the Rich Results Test and the Schema Markup Validator as the tools for checking markup Google Search Central on structured data. Apply the same logic to your extracted rows: validate before you score.

Extraction at ad-library scale means a lot of calls across a lot of pages, and the temptation is to standardize on one model and one prompt. The skip instruction argues for the opposite in one narrow respect: you want the freedom to swap extractors and compare skip rates. If the sentinel and reason codes are frozen, an A/B between two models becomes a comparison of reason-code distributions, which is a far more useful signal than an aggregate accuracy number.

If you are running several extractors and a reviewer queue, Quanta Inference puts text, image and embedding models behind one OpenAI-compatible API key, which keeps the model swap a config change rather than a re-integration.

And when the skip data starts pointing at schema decisions rather than selectors, that is an analysis job. Quanta Experts reads your context and hands back finished deliverables, which suits the "read three months of skip records and tell me what to change" task better than another dashboard.

Run through this on the prompt, the validator and the queue before the next batch.

The last row is the one teams skip. A single skip rate is a mood. A skip rate broken out by reason code is a work plan, and it is the only part of this pipeline that gets cheaper to run each month.