Variable: IDENTIFIER_UPDATE_DENIAL_REASONS
constIDENTIFIER_UPDATE_DENIAL_REASONS: readonly ["document-mismatch","agent-refused","host-unverified"]
Defined in: packages/contracts/src/schemas/audit-issuance.ts:184
Why an update did not happen, on an identifier.update record with outcome denied
(plan 3a, the ruling on a failed update gate):
document-mismatch: what the agent signed for the new version was not the document that was previewed, so nothing was stored or written (D3.3). A defect in the platform, never the caller's doing;agent-refused: the agent would not generate the update's keys or sign its entry;host-unverified: the identifier's delegated host no longer resolves to this deployment's edge. The control rule runs at every publication, an update's included, so a DNS record changed since the first publication stops the update that follows it (ruling 6a after the first real cycle). The caller is answeredidentifier.host_unverified, and the published version goes on being served: the check guards what is written next, never what is already there.
Whichever it was, the identifier is still the identifier it was: it stays published,
the keys it lives by are untouched, and what the attempt generated is destroyed as
unpublished (an identifier.key-discard record follows when the agent confirms).
That is the difference from a first publication, whose failure is final and is an
identifier.publish record. A failed update writes this record alone and nothing
under identifier.publish (ruling 23 of the wave 3 hand-out). The list only widens,
and new reasons go at the end.