Incidents and emergency patches

Section 11 of 22

Emergency work is a distinct route with preauthorized powers and shortened exposure to delay. It still requires evidence that the proposed fix addresses the incident and does not give its executor unrestricted release authority.

Bounty adjudication does not need to finish before containment. A report can demonstrate a serious defect even when its reporter's eligibility or award amount is disputed. The incident record and bounty record link to the same evidence but control different actions.

Step	Evaluation and authority	Action and branches
E01. Receive and establish urgency	Automated reproduction or targeted judgment under an incident policy. An unauthenticated assertion alone does not authorize arbitrary shutdown.	Identify the affected operation and evidence. A credible urgent condition moves to E02. Unconfirmed reports continue through F4 with bounded reproduction work.
E02. Contain	A preauthorized guardian or incident executor applies the narrow protective rule. Authenticate the action and record the incident.	Stop affected work or new credential issuance. Separately determine whether existing credentials need distrust or individual revocation. Missing capability enters F10 immediately. Continue unaffected services where the scope permits.
E03. Choose restoration path	Targeted decision by the incident authority. Check whether a predecessor is still approved, usable, and unaffected.	Restore that predecessor under an existing rollback permission, or keep the affected operation paused while producing a patch. Never restore a known-defective fallback merely to exit the pause.
E04. Authorize emergency work	Incident maintainer defines the bounded fix, resource budget, and any paid scope. Corpus authority establishes the demonstrated failure's expected result.	Link the work to the incident and authorize an emergency candidate. Broader feature changes return to F1. Funding limits still apply.
E05. Build and test	Full fixed checks where feasible, reproduction of the original defect, and targeted semantic and regression checks for the affected behavior. Evidence must identify the exact patch.	A passing result proceeds. Failure returns to the implementer. Missing required inference or runner evidence enters recovery. The incident authority cannot declare a missing required check successful.
E06. Authorize expedited promotion	Apply the emergency policy's scoped authority and any required signatures. Record which ordinary waiting requirements were shortened or deferred and why.	Permit only the identified patch and actions. A policy exception beyond predelegated authority requires the proper higher authority. If that authority is unavailable, remain contained.
E07. Deploy and verify	Authorized transaction and routing jobs, with confirmed state and live checks.	Restore only after the candidate is approved and the required checks confirm it is serving correctly. Partial activation remains an incident and can return to E02 or E03.
E08. Complete follow-up	Observe the fix, perform specifically deferred extended tests, notify affected users, and evaluate remedies.	Keep the incident open until required follow-up is complete or an explicit continuing restriction is recorded. A failed follow-up returns to containment. Record the final outcome and linked reward or refund obligations.

E05 must still test the demonstrated failure and the behaviors needed for a defensible restoration. The emergency policy can reduce a long public window or a broad attack-search budget. It should identify what may be deferred, the substitute evidence required now, and the deadline and consequence for missing follow-up.

A short emergency notice or challenge opportunity can be useful if urgency permits it. It cannot postpone the protective stop it is supposed to support. New contrary evidence remains actionable immediately after restoration. Do not wait for a post-release window to close before containing a demonstrated new failure.

The emergency authorization path must exist before the incident. If the same unavailable quorum is required for every ordinary and emergency action, describing the fix as urgent does not supply the missing permission. Governance must decide in advance which bounded powers survive that outage.

Protective actions

Action	Effect and required limit
Pause affected work	Stop the identified service or job class while unaffected reporting and recovery continue.
Stop new credential anchoring	Prevent new accepted records from the affected release or domain. Define existing-credential treatment separately.
Revoke an individual credential	Invalidate a specific credential under its granted authority and recorded reason. Use disposable identifiers when testing an irreversible action.
Distrust or revoke a release	Apply the defined effect to credentials associated with that release. Broader or irreversible effects need their own permission and notice rule.
Roll back production	Select an explicitly authorized, usable, unaffected predecessor and confirm actual routing.
Admit an emergency patch	Approve only the identified evaluated fix through the expedited permission. This is broader than permission to pause.

The incident record identifies an accountable coordinator, affected releases and credentials, containment times, permitted restoration, evidence access, and follow-up deadlines. Contact affected credential holders directly where contact information is available. A public status record should describe the impact even while exploit details remain private.

Retain enough build and test evidence to reproduce a defect against an older release. A fallback is usable only while its authorization, hosting, dependencies, and known behavior remain suitable. Check those conditions during ordinary operation so an emergency does not discover that the recorded fallback no longer runs.