Preview guide · Reviewed 20 September 2026
RESOURCE · SEND RECORDS
What a timed email record proves
A timestamp makes an event reviewable only when the event is named precisely. A record that says “sent at 07:00” may describe a local application action, a provider response or a receiving-server event. Those are different observations.
This is general administrative information, not individual immigration advice. The official-response stage follows the Home Office priority service guidance. The record format below is a suggested review method.
Local dispatch
An application log can show when it initiated a send operation. Preserve the timestamp, time zone, message identifier and approved package version. Name the event exactly: beginning an API call is different from receiving a successful response.
For timing-sensitive work, include clock uncertainty and the measurement definition. A small local scheduling delay does not show when a remote server received the message. Never turn a local millisecond figure into a recipient-arrival claim.
Provider acceptance
The mail provider may return a submission response and message ID. Preserve that evidence with its actual meaning. It can establish what the provider acknowledged; it cannot establish that the recipient server accepted the message, that anyone read it or that the request qualified for priority processing.
If a connection times out, the result may be unknown. Reconcile it before retrying. An unexamined retry can create a duplicate even though the application displayed an error.
Recipient receipt
A receiving-server delivery event or an explicit recipient confirmation can support a separate observation. State which evidence exists and what it covers. Server acceptance is different from human awareness. Absence of a bounce does not prove either.
In many cases the sender will not have authoritative receiving-server timing. The honest entry is “not evidenced”, with no estimate inserted to fill the gap.
Official priority acceptance
An official acceptance message and matching payment instructions are a separate stage. Store the evidence in the secure operational system, check its connection to the request and assign the next action.
The Home Office says to assume an unanswered request was unsuccessful. Record no official acceptance evidenced; that observation does not establish why it was unsuccessful or whether the receiving server received it. Do not label a provider acknowledgement as an awarded priority place.
Allocation and later outcomes
Priority admission is not allocation approval or a visa outcome. Payment, consideration and the eventual decision have their own evidence. A commercial fee trigger cannot change what any earlier technical event proves.
A compact event record contains event type, timestamp/time zone, source, evidence location and interpretation. A fictional row might read: “Provider acknowledgement / 07:00:02 BST / provider ID X7 / accepted for provider processing.” A later official response belongs on its own row.
Keep those distinctions visible in customer updates. They let a reviewer see what happened, what remains unknown and who owns the next action.
Check pilot availability, or explore the fictional demo. The demo sends no request and collects no information.
See how these evidence limits apply to our proposed undefined CoS priority request support.