====== 15.9 Exception-Handling Requirements ====== [[fxdemo:04-part:15-phase-0-developer-handbook-requirements:start | Go To Phase 0 Developer Handbook Requirements ]] The Developer Handbook must define exception-handling patterns for Phase 0 implementation artifacts. Exception-handling requirements must identify: - Processing boundaries where implementation [[dido:99_annexes:annex-b-terms-and-definitions:f:financial_node|Nodes]] capture exceptions - Required exception context - Node or participant identity - Correlation identifiers - Affected logical interaction where available - Affected [[dido:99_annexes:annex-b-terms-and-definitions:d:dds|DDS]] Topic or generated type where available - Timestamp - Exception type or error category - Processing outcome - Retry or recovery expectation - Health-reporting effect - Audit/provenance effect - Control-plane effect where applicable Operational exceptions must support Health and Observability when they describe node condition, degradation, failure, warning, or recovery. Exceptions that affect logical processing, lineage, replay, reconstruction, release, or [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]] must support Audit and Provenance. Exceptions that require retry, pause, resume, restart, or recovery coordination must support Control Plane interaction. Exception handling must not hide processing failures. An implementation artifact must either handle the exception according to the approved pattern or report the failure through the appropriate logging, status, audit/provenance, or control mechanism. ---- © 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.