Why the result object decides what analytics can say verifiedcritical
The result is the job plus the attempt history — which means our analytics are limited by what we put into the job, not only by what the engine reports.
In detail
Most telemetry systems are read-only: you get what the engine chooses to tell you. Here half the object is what the sender put in, returned unchanged, so the quality of the analytics is a decision made at send time. That reframes several things. Grouping by campaign does not need a lookup table — put the campaign in the job. Attribution on a shared node does not need a convention — name the REST token. Warm-up verification does not need inference — compare the address asked for with the address in from. What the engine contributes is the part we could not know: the stage and outcome of each attempt, the codes and the receiver's own words, and three judgements it has already made — whether the failure was final (fatal), whether it concerned the message or the whole destination (individual), and whether the receiver was merely deferring (greylisted). Those three are better than anything we could derive from codes, and two of them Hub does not read yet. The gap is equally clear: nothing is published while a message is still retrying. A node with a large deferred backlog reports almost nothing, and the send log is the only witness.