Govern · Reliability contract
Retry and replay Govern work
Govern uses three different mechanisms for three different problems. They should not be treated as one generic retry button.
| Mechanism | Purpose | Side effects |
|---|---|---|
| Delivery retry | Recover from a temporary transport or downstream failure | May repeat a request with the same identity |
| Idempotent reconciliation | Make duplicate delivery converge on one record | Returns or updates the same logical record |
| Fixture replay | Re-evaluate a captured contract case | None; offline validation only |
Delivery and reconciliation identities
| Surface | Stable identity | Required behavior |
|---|---|---|
| Provider webhook | Provider, tenant, channel, and message IDs | The same event does not create a second turn |
| Host tool call | Correlation, causation, and idempotency IDs | Preserve the IDs across retry |
| Proposal sink | Proposal ID or proposal idempotency key | Create or return one host record |
| Lifecycle callback | Proposal and callback idempotency key | Record one lifecycle fact |
| Execution receipt | Permit and idempotency key | Return the existing receipt |
| Witness or reversal event | Organization and idempotency key | Return the existing evidence event |
Govern keeps a processing receipt for inbound provider webhooks, including provider identity, status, attempts, last error, and completion time. A proposal is also persisted before sink delivery, so a delivery failure does not erase the proposal.
Retry decisions
When the result is uncertain because of a timeout or transport failure, retry the same logical request with the same idempotency key. Do not generate a new key merely because the client did not receive the response.
Use the problem code, not only the HTTP status, to decide what to do:
| Result | Client action |
|---|---|
Transport failure or 5xx | Retry with the same key and bounded backoff |
401 unauthorized or invalid_signature | Repair authentication; do not blind retry |
404 *_not_found | Repair the referenced identity or ordering |
400 missing_*, invalid_* | Correct the contract payload |
409 idempotency_key_conflict | Stop; the key was reused with different content |
422 host_evidence_rejected | Inspect authority or evidence scope |
Tonetify does not currently publish one universal retry budget, backoff schedule, or dead-letter recovery contract for every Govern surface. The stable guarantee is duplicate convergence where an idempotency identity is documented.
Fixture replay is not production re-execution
The captured workflow fixture scenarios evaluate recorded JSON inputs against the current verifier and proof builders:
mix tonetify.governed_action.replayReplay is pure contract validation. It does not read the database, call a host, execute a mutation, issue a permit, create credentials, apply policy candidates, or retry a failed production job.
Fixture metadata may preserve authority evidence or a policy candidate for review. Replaying it does not create authority or promote a policy.
Current boundary
Captured Golden Loop evidence is useful as a replayable proof artifact, but it is not a public replay API or a production re-execution engine. A live permit-backed mutation and a published operational recovery policy remain productization work.