​

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.