Reliability model

Durable-first, not transport-first

The database is the source of truth. Realtime channels are delivery mechanisms, not the record of what happened.

When a code is activated, SwiftCode first commits the change and a durable event to its database, together, in a single transaction — before it attempts to reach anyone. The alert lifecycle then flows in stages that are kept deliberately distinct:

Transport independence

Delivery infrastructure being unavailable never erases a critical alert.

• The alert is durable the moment the activation transaction commits — before any push, broker, or socket is contacted.
• If push notification delivery is unavailable, the alert remains durable and delivery is retried independently.
• If the optional message broker is unavailable, the alert remains durable; the broker is never the record of truth.
• If a realtime connection drops, the underlying incident still exists and is recoverable.
• If the presence cache is unavailable, the system fails safe — it does not suppress an alert because it is unsure whether someone is online.

Delivery visibility

Every recipient's delivery outcome is tracked — and transport acceptance is never confused with a person seeing the alert.

For each recipient, SwiftCode records whether delivery was attempted, whether the transport accepted it, whether it was rejected or failed, or whether it was intentionally skipped because the recipient was already connected in real time. These are separate, durable facts — not a single “delivered” flag.

Per-recipient delivery tracking is currently focused on push notifications; broadening per-recipient tracking across every transport is on the roadmap.

Explicit acknowledgement

Acknowledgement is a deliberate human action, recorded durably — never inferred from an alert simply arriving.

• Acknowledgement is triggered by an explicit responder action (for example, accepting or declining a dispatch), not by an alert being received or displayed.
• The acknowledgement is authenticated and scoped to the acknowledging staff member — a person can only acknowledge their own alert.
• Repeated or simultaneous acknowledgements are safe and do not create duplicate records.
• Acknowledgement records a distinct, auditable event and never overwrites the underlying delivery outcome.

Acknowledgement while offline is best-effort today; a durable offline acknowledgement queue is future work.

Reliable recovery

A dropped connection does not mean a missed alert.

Realtime connections are treated as delivery mechanisms that can fail. Clients keep track of how far they have caught up, and after a disconnect they ask the platform for anything they missed — so recovery does not depend on the original connection staying alive.

• Primary responder and command apps recover missed events by resynchronizing after reconnect and when returning to the foreground.
• The platform exposes the recovery interface these clients use.

Auditability

The system keeps an append-only history of what happened.

Critical state changes are recorded as durable, ordered events. This gives an after-the-fact record of when an incident was created, which recipients were selected, what each delivery attempt resulted in, and when a human explicitly acknowledged — without collapsing those distinct stages into one number.

Observability

Operators can see delivery pipeline health today; deeper timing insight is on the roadmap.

SwiftCode tracks delivery-stage timing from durable intent through transport acceptance, and measures human acknowledgement independently — so delivery latency and stranding are visible before they affect responders. Delivery latency is measured separately from human acknowledgement; transport acceptance is never treated as human receipt.