Events and webhooks

The controlled pilot includes operational alerts for repeated dependency failures and recovery. These alerts are distinct from a general business-event subscription service.

What operators need to know

Operational alerts cover execution reconciliation and evidence delivery. They indicate degradation, continuing problems or recovery without exposing transaction details, credentials or raw internal errors.

Receivers must handle retries without treating the same alert as a new incident each time. Acknowledgement should mean the receiver has safely accepted the event. Delivery and escalation responsibilities must be agreed with the receiving team.

Health is more than process availability

A responding service does not establish that authorization, execution, reconciliation and evidence dependencies are all healthy. Operators must assess the relevant dependencies before allowing affected work to continue.

Current boundary

Generic alert and recovery behavior has controlled test evidence. A partner-owned production destination and on-call process still require acceptance. A stable outbound business-event webhook contract is not yet published.

Approved integrators receive version-matched payload schemas, receiver requirements, delivery semantics and health-field mappings for the agreed environment. See Source and documentation access.

V3 governance state

The V3 API reads pause, service exit, request revocation and committee configuration at a common canonical block before authorization or execution preparation. The console refreshes every 10 seconds. This state observer is distinct from historical event indexing and outbound alert delivery, which remain unfinished for the V3 governance path. See current implementation status.