Monitoring and incident response
Persistent observations, incident changes and an explicit operator response process.
In this chapter
What the worker checks
The operations worker runs the protocol observer against reviewed contract and implementation identities. It checks the configured administrators, pauses, recovery flags and available module-specific cash and liability checks. It records observations in PostgreSQL and creates incidents for failed, inconsistent or unavailable observations. It cannot certify contract correctness or replace independent review.
Identical findings are deduplicated. A changed finding or resolution is saved atomically with an operator notification job. Missing or removed modules require attention instead of silently disappearing. Public readiness becomes unhealthy when observations are stale, an incident remains open, or a configured operator notification is delayed or has exhausted its retries.
Durable delivery and reconciliation
Operator webhooks are optional and must be configured separately. Delivery uses an HMAC signature, timestamp and stable event identifier. Jobs have a lease, bounded retries and a failed state after repeated failure. A receiver must verify the signature and deduplicate the identifier because delivery is at least once.
PostgreSQL holds service, incident and delivery state. The worker restarts without inventing a fresh healthy state. Chain balances and receipts remain authoritative for financial state. A database backup and restore procedure, uptime supervisor and monitored incident destination must be provided by the operator before activation.
Human control of incidents
The worker has no transaction signer and cannot pause, upgrade, recover funds or liquidate accounts. Either designated administrator can pause immediately. Both must approve the exact upgrade or recovery operation. Recovery can move all held assets, including assets backing users, and is not an insurance mechanism.
The operator should acknowledge the incident, preserve its observation block, verify the scope independently, pause affected new risk where appropriate, communicate the incident, reconcile balances and claims, and only then propose a reviewed repair or recovery. Resumption requires the established two-administrator procedure.
The report attestation key is a separate service credential used only for typed report messages. It must not be the funded deployment key. It does not give the worker permission to spend user tokens or send transactions.