Normalized output

The normalized block next to result, which jobs carry fixed field names, the email status vocabulary, and how verdict differs from outcome.

Every provider answers in its own shape. On a handful of jobs, a completed run can also carry normalized, a fixed-field reading of that same answer, next to result.

Shape

{
  "job": "people.email.verify",
  "endpointId": "icypeas-email-verify",
  "fields": { "email": "jane.doe@example.com", "status": "valid", "deliverable": true },
  "missing": [],
  "ambiguous": [],
  "unmapped": [],
  "providerValues": { "status": "VALID" },
  "verdict": "hit",
  "verdictReason": null,
  "mapVerified": true
}

• fields always holds every field of the job, null for one that was not found.
• missing lists fields whose path found nothing in the answer; unmapped is the subset of those with no path defined at all.
• ambiguous lists fields the provider did answer, whose value did not translate to a known one.
• providerValues keeps the provider’s own word for each translated field.
• verdict is the extractor’s own read of the answer: hit, weak, miss, rejected or skipped. It can differ from the run’s own outcome (see below).
• mapVerified is true only when the field map has been checked against saved provider answers and every checked path matched.

Jobs and fields

endpointId inside the block is the endpoint whose answer is in result: the route’s hit, else the last attempt that missed, else the endpoint you asked for.

Email status vocabulary

status (verify) and check (find) use: valid, invalid, catch_all, risky, unknown. A provider word the table does not recognize lands as unknown and appears in ambiguous. deliverable is set only when the provider has a field that reports deliverability itself. looot never derives it from status.

Worked example, job:people.email.find on jane.doe@example.com at example.com:

{ "job": "people.email.find", "fields": { "email": "jane.doe@example.com", "check": "valid" } }

When it is absent

normalized is absent, never null, when:

• the run did not complete,
• the endpoint that answered has no stored field map for its job,
• the run asked for a non-raw output mode, or
• there is no saved answer to read.

It only appears on a run whose gateway has this turned on; treat it as optional on every job, not only the ones without a map yet.

verdict vs outcome

verdict is a second, independent read of the same answer, and the two can disagree by design. Known cases: a catch-all verify answer reads verdict: "hit" while outcome reads weak; an Icypeas not_sure reads verdict: "unknown" (a miss) while outcome reads hit. Neither field ever rewrites the other, and neither changes which provider fallback tries next or what you were charged. Use outcome for money and routing questions, verdict for a second opinion on the answer’s field-level content.