Record one verified real-world execution of a prepared outreach, or a factual CORRECTION of an earlier one. Never resolves or signals an Action. Absence of a bounce is not delivery proof.

Each item MUST identify its recipient by campaignTargetId OR by recipientAddress (at least one; both is fine). A recipientAddress-only row is first-class send evidence: it is stored as an execution target row with campaign_target_id null, it counts in effective state (counts.sent_confirmed_targets counts confirmed RECIPIENTS, identified by target id or normalized address) and in global recipient safety (a confirmed address-only send inside the duplicate window produces global_duplicate_recent_send and appears in prior_executions). Address-only rows do NOT create campaign_target_events and do NOT update campaign_targets.status, because those require a target; bounce or reply events for such a recipient need a campaign target or a person first. Addresses are compared on their normalized form (trimmed, lowercased); two rows for the same address in one execution collapse into one. Validation runs BEFORE any write: if an item carries neither a valid uuid campaignTargetId nor a usable recipientAddress, the call answers 400 with { error: "targets[<i>]: campaignTargetId or recipientAddress is required", invalid_targets: [{ index, reason }] } and NOTHING is written — no execution header is left behind. The literal string "undefined" is treated as an absent value. The response reports target_execution_rows and address_only_rows, plus sent_events: { attempted, written, error }. sent_events describes the per-recipient 'sent' event ledger write for confirmed id rows: it is idempotent per (campaign_target_id, external_source, external_message_id, event_type), and a failure is REPORTED, never fatal — the execution row and its recipient rows are already valid facts, so the call still answers 201 with sent_events.error set and the failure logged server-side.