Fixes and mitigations

Nova proposes two kinds of change, and you approve each one separately. Nothing changes until a person approves the exact change on the card.

	A mitigation	A fix
Purpose	Restore service while Nova keeps looking	Change what caused the incident
Example	Roll back to the last version that was healthy	Give the app a writable cache path
Offered	As soon as the first facts are known, and again once a cause is named if none was offered	Once a cause is confirmed
Appears	As its own question under Needs you, for example Roll back payments-api to v2.14.3?	In the result, as Let Nova fix it

For a Likely cause, Nova shows the steps as a runbook for a person to follow and does not offer to run them.

A mitigation's detail says what it is for: This should restore service while Nova keeps looking; it does not fix the cause.

What changed comes first. When the last change landed within two hours before the incident began, the first mitigation Nova offers is to take that change back, to the version before it, unless the reads argue against it: a data or schema migration, an earlier version that was not healthy either, or other apps on the cluster failing the same way. A mitigation is offered only when the reads show it will help and it can be undone.

What every change shows

• What it changes, and the exact change where there is one.
• Its risk (low, medium or high) and whether it can be undone, and how.
• The steps behind it.
• The deadline to decide, 15 minutes by default.
• Approval history: whether Nova has proposed this change for this app before, how often it was approved, and how often the app was healthy afterwards.

Nova builds each change from your connected skills' own actions, such as updating, rolling back or resyncing an app. It is checked with the skill before you see it, using the skill's own validation where there is one, and checked again before it runs. Nova does not invent commands.

Approve a change

1. Review the change on the card.

2. Approve it:

   • Console: Let Nova fix it for a fix, Approve for a mitigation. Someone who may not approve changes sees Only an admin can approve this change instead.
   • Terminal: when the approval opens in the conversation, select the change, press Enter to review it and Enter again to approve it. Esc hides it and /approve brings it back. From /investigations, press a on the investigation's card and do the same. When several fixes are offered, each is its own answer, named Let Nova followed by what it does.
   • API: answer with the action and option the card lists; see the API reference.
   • Slack (Enterprise): in the investigation's thread, only for a low-risk change and only if your organization allows it. Otherwise the button opens the console.

3. Nova applies exactly the option you approved, with the parameters you saw. If the change was revised after you saw it, your approval is refused and you review the new version.

4. Nova waits for your health-check window (5 minutes by default), then checks the app.

   • Healthy: the investigation ends Resolved.
   • Not healthy, or the change did not complete: Fix failed.
   • Nothing changed, for example only a preview ran: Fix held, no change.
   • Nova could not tell whether the app recovered: the fix stays applied and the incident waits with a person. It is never called resolved or failed on a guess, and a later Check health settles it.

   If the tool that made the change did not confirm it applied, the fix reads Fix sent, not confirmed, and Nova still checks the app when the window ends. If a resolved app later reads unhealthy, the incident opens again.

Reject or take it over

• Reject makes no change, and Nova does not propose that change again in this investigation. Over the API, add a reason to say why, for example "Rolling back instead". The card offers Reject on a mitigation. A fix is not rejected from the card: choose I'll fix it myself, let the approval expire, or send reject_fix over the API.
• I'll fix it myself hands the change to you. Nova changes nothing in that investigation, and the card reads You're fixing it (your teammates see A teammate is fixing it). In the terminal: I'll fix it myself in the investigation's answers, then Enter twice. While Nova is still investigating or applying a change, stop it first, then take it over.

When you take it over, Nova later asks once what fixed it, with its best guess filled in. Accept, correct or reject it; to correct it, add your words, for example "Raised the memory limit". Your answer is what the next investigation on that app learns from.

Rules that always apply

• Nothing runs without an explicit approval, whatever your Changes & Remediation rule says.
• Approved changes still run through your guardrails. A Blocked rule, the burst limit of 10 changes a minute, and Emergency stop apply to them.
• Emergency stop (on the Guardrails page in Settings, owners and admins) blocks every write across the organization at once. Nova keeps investigating; it just cannot change anything.
• Deletion is blocked by default. Destructive Actions stay blocked unless your organization changes that rule.
• Decide by the deadline. With no answer, the approval expires, nothing changes, and the card reads Approval expired. A late answer is refused.
• One answer wins. If two people answer at once, the first is applied and the others are told. Nothing runs twice.
• One change at a time. Nova does not offer a new change while the last one is being applied or checked.

Every answer is recorded with who gave it and when. See Guardrails and Approvals.

After the incident

When an investigation ends, Nova drafts a blameless postmortem from its record: a summary, the timeline, impact, the root cause with its evidence, the causes it tested, what went well, what could be improved (including what it could not check) and action items. It is completed once a fix or mitigation is verified. Changes are named by version and time, never by who made them.

Read it at the end of the investigation's record. Until a fix is verified it is marked Postmortem draft.

To share it, select Publish on the postmortem: pick a GitHub repository to file it as a GitHub issue, enter a Slack channel to post a summary, or both, then select Publish. Each target needs its skill connected, and the Nova app must be in the channel. Copy as Markdown, Download .md and PDF take it anywhere else.

Next

• Configure who may approve, and whether Slack approvals are allowed.