Finding a value versus checking one, and when to reach for QA Agent

Finding versus checking, in one table

QA Agent and Validate Email are different tools

Validate Email does one job. Give it an email column and it returns DELIVERABLE, CATCH_ALL, UNDELIVERABLE or UNKNOWN. QA Agent is the general one. You pick any column, say in plain words what you are checking, and it judges whether the value holds up against the rest of the row and, in standard mode, against the web. The rest of this lesson is about QA Agent.

A real check, end to end

You have sourced Hong Kong distributors and enriched a phone number for each, and before anyone calls you want to know the numbers really are Hong Kong numbers. Add a QA Agent column on the phone column. Validation purpose: verify that the phone number country code matches the company address country. Mode: lite, because the answer is already in the row and needs no web search. Custom rule: flag any phone number that does not start with +852. Every row comes back pass, warn or fail with its reasoning. Passes go to the call list, fails are cut, and warns are the rows somebody opens and reads.

Switch to standard when the claim needs proof from outside the row, for example whether the website you hold really belongs to the company named on the row. Standard searches the web and attaches the links it used, so whoever reads a warn can check the source rather than take the verdict on trust.

Setting up a QA Agent column

1. 1

   Choose the column to check

   Pick the single column whose value you want checked. The rest of the row is handed over as context automatically, so the agent can see whether a value is consistent with everything else you hold.

2. 2

   Say what you are checking and why

   This field is required and it is what makes the output useful. "Verify that the phone number country code matches the company address country" gives you a verdict you can act on. "Check this is right" does not.

3. 3

   Pick lite or standard

   Lite is a logic check on the row alone, 1 credit, no web search. Standard adds web search and evidence scraping for 2. Standard is the default choice; lite is for when the answer is already derivable from the row.

4. 4

   Add your own rules if you have them

   Custom rules are treated as authoritative, so this is where a house standard lives. "Flag any phone number that does not start with +852." "Flag if the email domain does not match the website domain."

5. 5

   Read the verdict, not just the status

   Every row comes back with pass, warn or fail, a confidence score, the reasoning, and links to what it actually looked at. The links are the point. A verdict you cannot check is just another opinion in a cell.

When a check earns its credit

Watch · 15 sec

• The claim goes into an email. Naming a fact that turns out to be wrong is worse than naming nothing.
• The claim gates spend. If a column decides who gets an expensive enrichment, a wrong value costs more than the check would have.
• The claim came from an inference rather than a source. Anything a tool concluded rather than read is worth checking.
• You are about to hand the list to someone else and you want an auditable trail behind it.

And when it does not: on a field you can eyeball, on a list you are about to cut anyway, or on anything where being wrong on a few rows has no consequence. QA Agent is charged on run, so pointing it at a badly targeted list costs the full price for nothing.

1. 6

   Run it on the narrow set

   The rows going into outreach, or the rows where the claim gates spend. Not the whole table.

2. 7

   Route on the three outcomes, do not collapse them

   Passes go forward. Fails get cut. Warns go to a person, and the confidence score plus the links are what that person reads.