States and outcomes

Copy

• Copy for LLM

  Copy page as Markdown for LLMs
• View as Markdown

  Open this page as Markdown
• Open in ChatGPT

  Get insights from ChatGPT
• Open in Claude

  Get insights from Claude
• Connect to Cursor

  Install MCP server on Cursor
• Connect to VS Code

  Install MCP server on VS Code

Namirial Notify tracks each communication or signature workflow through states and events, and typically assigns a final outcome when the process closes.

Understanding the difference between states, outcomes, and events helps you interpret transaction history, recipient actions, and affidavits correctly.

This page provides representative lifecycle terminology used across Namirial Notify services. Exact labels and transitions can vary by service, interface, API, and configuration.

For affidavit-generation rules and affidavit kinds, see Evidence and affidavits.

What is the difference?

• A state shows the current phase of the process.
• An event records something that happened during the process.
• An outcome shows the final result once the process is complete.
• An affidavit kind names the type of affidavit that certifies a specific event or summary and does not always match the state or outcome label.

In practice:

• states tell you where the transaction is
• events tell you what happened
• outcomes tell you how it ended

State, outcome, and timestamp fields

When you query a transaction, three kinds of fields tell you what has happened. Understanding how each behaves over time is essential if you reconcile status by polling instead of callbacks.

State changes while the transaction is live; outcome becomes final at closure

• State is updated as the transaction progresses. Failed records a recoverable processing or delivery failure; the platform may retry or advance to a later state. Closed is the final stage of the state machine and does not change afterwards.
• Outcome generally remains None while the transaction is active. When the state becomes Closed, the platform derives the final outcome from the milestones recorded during the transaction. The outcome is then fixed. Outcome: Failed is the final result when a failure was recorded and takes priority over successful milestones.

Do not treat State: Failed as a permanent failure or resubmit immediately. Wait for Closed and inspect the final Outcome; permanent failure is represented by Outcome: Failed.

Outcome priority when events conflict

Events can arrive close together or out of order. When the transaction closes and more than one outcome-like milestone has been recorded, Namirial Notify derives the final outcome by priority instead of only using arrival order.

For EviNotice, the effective priority is: Failed, Rejected, Accepted, Refused, Read, Received, Delivered, Sent, Certified, then None.

For EviMail, the effective priority is: Failed, Rejected, Accepted, Read, Delivered, Sent, Certified, then None.

For EviSMS, the effective priority is: Failed, Read, Delivered, Sent, Certified, then None.

This means a recorded higher-priority milestone can prevent a lower-priority milestone from becoming the final outcome, regardless of event arrival order. For example, a rejected notice remains rejected even if another technical event is recorded around the same time.

Timestamp fields tell you which states were reached

Each lifecycle milestone has a corresponding timestamp field (for example NewOn, ReadyOn, SentOn, DeliveredOn, ReadOn). A timestamp is set only if and when the platform records that milestone. If a milestone was not recorded, its timestamp is null or absent.

This makes timestamps the most reliable way to determine which milestones were recorded — even after a transaction has closed. To check whether a message was delivered, for example, check whether DeliveredOn has a value rather than relying on the current State or Outcome.

The fields available depend on the service:

Why delivery and read tracking can be incomplete

Delivery and read timestamps depend on the signals available for the service and channel. They can therefore be absent even when the communication reached the recipient.

The meaning of each timestamp is consistent across providers for a given channel. What can vary is signal availability: some providers report a delivery or read event while others do not. A missing timestamp means that the platform did not receive the corresponding signal, not that the field has a different provider-specific meaning.

EviNotice

• DeliveredOn is set from best-effort delivery signals reported by the recipient's mail infrastructure. These depend on the recipient's server and client configuration, which may block them, so DeliveredOn can be absent even when the notification email was delivered.
• ReceivedOn is set when the recipient clicks the notification link and reaches the hosted notice.
• ReadOn is set after the recipient completes any required identification or validation step and is shown the actual content. In the normal hosted-notice flow, ReceivedOn precedes ReadOn, but treat them as independently recorded milestones.

EviMail

• DeliveredOn is set when the platform receives a Delivery Status Notification (DSN) from the recipient's mail server. Many mail servers do not send a DSN, so a missing DeliveredOn does not mean the message was not delivered.
• ReadOn is set when the platform records a supported signal that the message was opened or read. The available signals depend on the recipient's mail client and how the content is accessed, so ReadOn is best-effort and may remain absent.

EviSMS

• SentOn is set when the telco operator accepts the message for routing, confirmed by a GSM/SMPP delivery receipt (DLR).
• DeliveredOn is set when a DLR confirms delivery to the recipient's terminal.
• ReadOn is set only for rich-channel (RCS) deliveries that report a read event. Plain SMS has no read receipt, so ReadOn stays absent for SMS-only delivery.

Affidavits are generated asynchronously

When a transaction reaches a state and its timestamp is set, the corresponding affidavit can take a few seconds or minutes to become available, because affidavits are generated asynchronously. A state timestamp can therefore be present before its affidavit is published. Affidavits for a transaction are expected to be available by the time it reaches Closed.

States

States describe the progression of a transaction from creation to closure.

Certified delivery services

Certified delivery services, including EviNotice, EviMail, and EviSMS, typically use the following states:

• Draft — the communication is saved but not yet sent.
• New or Submitted — the communication was admitted for certification and is waiting to be processed.
• Ready or Processed — the communication was processed and is ready to be sent.
• Dispatched — the platform completed its checks and accepted responsibility for the communication; it is not yet sent.
• Sent — transmission was confirmed by the remote system (for example, the recipient's mail server or the telco operator). Dispatched always precedes Sent.
• Delivered — the communication or notification reached the recipient.
• Received — for hosted-notice flows such as EviNotice, the recipient followed the notice link and reached the hosted notice flow before opening the content.
• Read — the recipient opened the content, where this milestone is supported and exposed as a status.
• Replied — for EviNotice, the recipient accepted or rejected the notice. Refusal closes the evidence with a Refused outcome instead of using Replied.
• Closed — tracking is complete and no further status changes are expected.
• Failed — a recoverable processing or delivery failure occurred. The platform may retry or advance to a later state.

Status names can vary slightly by service, screen, or API. For example, some views show Ready, while others show Processed; some use Sent, while others also show Dispatched.

The following diagrams show the normal evidence lifecycle for certified delivery services. They focus on persisted evidence states and final outcomes. Event-history screenshots are shown separately in the Events section.

Shared notification evidence lifecycle

EviNotice evidence lifecycle

EviMail evidence lifecycle

EviSMS evidence lifecycle

Event timeline examples from transaction history:

• EviNotice event timeline:
• EviMail event timeline:
• EviSMS event timeline:

Signature workflows

EviSign uses states such as:

• Draft — the signature request is prepared and can still be edited.
• Submitted — the request was admitted for processing.
• Processed — the content was certified and the signing workflow was prepared.
• Sent — signature requests were sent to recipients.
• Closed — the signature process reached its end.

Some source-defined EviSign states, such as Forwarded and Received, may appear in specific or legacy flows. The simplified lifecycle diagram focuses on the main source-backed progression used for documentation.

The following diagrams separate the overall EviSign evidence lifecycle from the per-signer or per-party lifecycle.

EviSign evidence lifecycle

EviSign signer party lifecycle

EviSign event timeline:

Postal delivery

EviPost uses states such as:

• Draft — the postal communication is saved but not yet sent.
• Submitted — the communication was admitted for postal processing.
• Processed — the communication was processed and prepared for dispatch.
• Dispatched — the request entered the postal workflow.
• Sent — the communication was handed to the postal operator.
• Delivered — the postal process reached the delivery stage, where this status is exposed.
• Closed — the postal process completed and no further tracking is expected.

Some interfaces may also show Issued as an intermediate status.

EviPost uses postal result states that represent alternative outcomes before closure. They should not be read as a strict sequence.

EviPost evidence lifecycle

Outcomes

Outcomes describe the final result of a transaction. The outcome usually starts as None and becomes final when the process reaches Closed.

Certified delivery outcomes

For services such as EviNotice, EviMail, and EviSMS, common outcomes can include:

• None — the process is still open and no final result exists yet.
• Certified — the content was certified, but the final delivery result is not yet confirmed.
• Sent — the communication was sent, but no later recipient event was confirmed.
• Delivered — the communication reached the recipient’s inbox, device, or access channel.
• Received — in hosted-notice flows such as EviNotice, the recipient reached the notice flow before reading the content.
• Read — the recipient opened the communication, where supported.
• Accepted — the recipient explicitly accepted the communication.
• Rejected — the recipient explicitly rejected the communication.
• Refused — in services that support explicit refusal before opening or reading, the recipient refused the communication.
• Failed — the process could not be completed because of an error.

Signature outcomes

For EviSign, common outcomes include:

• None — the signature process is still open.
• Signed — all required signatures were completed.
• Rejected — a signer rejected the document or workflow.
• Expired — the signing time limit was exceeded.
• Cancelled — the issuer cancelled the signature request.
• Failed — an error prevented normal completion.

Postal delivery outcomes

For EviPost, common outcomes include:

• None — the postal process is still active.
• Delivered — the postal communication was successfully delivered.
• Declined — the recipient refused acceptance of the postal communication.
• Rejected — the recipient rejected the postal communication.
• Cancelled — the issuer cancelled the request.
• Expired — delivery could not be completed within the service limits.
• Failed — an error prevented normal postal completion.

Events

Events are recorded facts that occur during the process. Not every event changes the state, but events provide the detailed history used to understand what happened and, in some cases, to generate affidavits.

This section uses representative event names for interpretation. Service-specific and affidavit-specific taxonomies can differ by configuration and are documented in:

• Services
• Evidence and affidavits

Common delivery events

For services such as EviNotice, EviMail, and EviSMS, representative event names can include:

• New — the communication was admitted for certification.
• Certified — the content was certified and prepared for sending.
• Retry — a temporary issue occurred and the system will try again.
• Submitted — the communication was submitted to the sending flow.
• Dispatched — the communication has left the initial preparation phase and has been handed to the service-specific sending process. The exact meaning depends on the service. For EviMail, Dispatched occurs before Sent; it means sending has been requested and the message is ready for the sender component.
• Sent — the recipient's server, operator, or delivery channel accepted the transmission.
• Delivered — the communication or notification reached the recipient.
• Received — in hosted-notice flows, the recipient reached the notice flow before opening the content.
• Read — the recipient opened the communication, where supported.
• Accepted — the recipient accepted the communication.
• Rejected — the recipient rejected the communication.
• Refused — the recipient explicitly refused the communication before opening or reading it, where that path is supported.
• Delayed — a delivery-status notification reported a temporary delivery delay.
• Relayed — a delivery-status notification reported that the message was relayed through another system.
• Expanded — a delivery-status notification reported that a distribution list or alias expanded the message to additional recipients.
• Failed — a failure event or failed attempt occurred. Some services may retry and later close with a final outcome. For EviMail, wait for Closed with a final Outcome before treating the communication as permanently failed.
• Expired — the tracking period ended.

Not every service exposes every event name in the same way. Technical DSN events such as Delayed, Relayed, and Expanded help explain email delivery processing and do not necessarily mean the final outcome has changed. Treat these names as interpretation anchors, then verify the exact labels shown in the transaction timeline.

Signature events

For EviSign, representative events include:

• Submitted — the document was admitted for processing.
• Processed — the document was certified and the signing workflow was prepared.
• Sent — the signature request was sent.
• FullySent — the request was sent to all signers.
• Delivered — a signer received the request.
• FullyDelivered — all signers received the request.
• Signed — a signer completed the signature.
• Rejected — the signer rejected the document or signature request.
• Declined — a signer withdrew from the process.
• Cancelled — the issuer cancelled the workflow.
• Expired — the signing time limit was exceeded.
• Closed — the signing process completed.

Depending on configuration, signer-level and workflow-level labels can both appear in history.

Postal delivery events

For EviPost, the event history can include steps such as:

• admission of the postal communication
• processing and certification of the content
• printing of the document
• enveloping or packaging
• dispatch to the postal operator
• delivery attempt or delivery failure
• delivery confirmation
• recipient refusal, where reported
• closure of the postal process

Postal event granularity depends on the selected service profile and on what the postal operator reports back.

How to read a transaction history

1. Check the state to understand the current phase of the transaction.
2. Review the events to see what happened during the process.
3. Check the outcome once the process is closed to confirm the final result.
4. Use the outcome and event history together when interpreting affidavits.

Related concepts

• The platform and the products
• Evidence and affidavits
• Archiving and retention