> ## Documentation Index
> Fetch the complete documentation index at: https://developers.govworx.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Reliability and delivery identity

> How GovWorx handles retries, duplicates, and ambiguous delivery outcomes.

# Reliability and delivery identity

GovWorx does not promise exactly-once delivery. A network failure can occur after CAD applies an
update but before GovWorx receives its acknowledgement. Retrying protects against lost updates;
CAD must therefore handle a repeated delivery safely.

## Delivery identity

Every GovWorx update has a stable delivery identifier. A permitted retry uses the same identifier
and exact request body. The timestamp and signature change.

CAD acknowledges a repeated delivery without applying the update a second time. The same identifier
with a different body is a conflict.

## Recommended implementation

The GovWorx best-practice baseline is to make the delivery record and business update durably
consistent before acknowledging success. A CAD can do that in one transaction, or retain a pending
state that lets a retry safely finish or recover the update after a failure.

GovWorx does not require a particular duplicate-handling design. The connector profile matches the
CAD's available capability and records its operational tradeoffs. When a CAD cannot safely
deduplicate a business action, GovWorx uses the `non_idempotent` compatibility profile and does not
automatically retry an attempt that may have reached CAD.

## Baseline reliability

The baseline profile is `durable_idempotent`. CAD retains each delivery identifier and a digest of
its body through the connector's retry horizon. GovWorx can retry a network failure, `429`, or
`5xx` response until the delivery expires. Retries use exponential backoff with jitter and honor
`Retry-After`.

## Compatibility profiles

Some CAD systems cannot retain delivery identity for the full retry horizon. A connector profile
can select a constrained reliability mode:

* `bounded_deduplication`: CAD retains recent delivery identifiers in a bounded cache. GovWorx
  limits retries to the declared bound.
* `non_idempotent`: CAD cannot safely deduplicate the business action. If an attempt may have
  reached CAD, GovWorx does not retry automatically. The outcome requires reconciliation.

The connector profile records the selected mode and its operational tradeoffs.

## CAD to GovWorx

A timed-out incident-event submission is ambiguous: GovWorx may have stored the event even though
CAD did not receive a response. A byte-identical resubmission returns the same `submissionId`,
but the identifier does not by itself prove that the underlying event was applied once.

Treat an ambiguous submission according to the replay rules for the connection. Do not assume it
either succeeded or failed.

## What each listener does

Each authorized listener receives, acknowledges, retries, and reconciles deliveries
independently. A failure at one listener does not affect the delivery outcome at another.