Regenerate remediations

Regenerating a remediation re-runs today’s fix engine on the same failure the remediation was drafted from, and produces a fresh proposal. The old one isn’t thrown away — it’s archived and marked superseded, linked to its replacement, and fully restorable. You get the new engine’s thinking without losing any history.

A remediation is only ever as good as the engine and the evidence it was drafted from. When either improves, the proposals already sitting in your backlog are stale — they reflect an older read of the same failure. Regenerating is how you pull them forward.

At a glance


Where	The Regenerate action on a remediation’s detail page (the ⋯ menu), and on an Issue / failure-mode card next to View fix. A Regenerate all button sits in the Failure Modes page header
What it does	Drafts a new remediation from the same cluster / failure mode; archives the previous one as superseded (never deletes it)
Needs	The same evidence the original used (a cluster or failure mode). An LLM connection (Settings → Connections) for a richer, specific proposal — it degrades gracefully without one, exactly like the first generation
Scope	Project-scoped — you can only regenerate fixes in the project you’re in

When to regenerate

Regenerate when the proposal is stale even though the failure hasn’t changed. The common cases:

The fix engine improved. Neens ships better grounding, classification, and artifact drafting over time. An old proposal may have mislabeled where a failure lives — calling a downstream outage an agent prompt problem, say — and the current engine gets it right. Regenerating lets you see the new logic take action on a failure you already have on file.
Detection / classification changed. If your failure-mode taxonomy or clustering has been re-curated, the evidence behind a remediation may now classify differently. A fresh draft reflects the corrected picture.
New failing traces arrived. The original was drafted from the sessions available then. When more examples of the same failure have since landed, regenerating re-reads the enlarged evidence — often sharpening the likely cause, the reach, and the proposed change.

Regenerating is not for editing a fix by hand or for moving it through the loop — use the normal simulate → apply → verify flow for that. Reach for Regenerate only when you want the engine to re-draft the proposal from scratch.

Regenerate a single remediation

You can regenerate one fix from two places: its own detail page, or the Issue / failure-mode card it came from.

Open the remediation

Go to Fix → Remediations and open the fix you want to refresh (/remediations/{id}).

Choose Regenerate

Open the header’s overflow ⋯ menu and click Regenerate. Because this archives the current proposal, Neens asks you to confirm first.

Review the fresh proposal

Neens drafts a new remediation from the same evidence and takes you straight to it. It opens with a Regenerated from a previous proposal banner and a before/after diff against the one it replaced.

Nothing is generated silently. A single regenerate runs right away and returns the new fix. The old one is archived in the same step — you’ll always end up looking at the replacement, with a link back to what it superseded.

Regenerate all open fixes

When an engine change is broad, refreshing fixes one by one is tedious. The Failure Modes page header has a Regenerate all button that re-drafts every open remediation in the project in one go — the proposals still in play (proposed / accepted), not ones you’ve already archived.

Click Regenerate all

It’s in the Failure Modes page header. Neens tells you how many open fixes will be regenerated and asks you to confirm — this archives each current proposal and replaces it.

Let it run

On a production workspace the batch runs in the background so you can keep working; a large backlog doesn’t block the page. A per-run cap keeps a single bulk request bounded, so if your backlog is very large you may run it more than once.

Review the results

When it finishes you get a toast with the count regenerated. Each refreshed Issue now links to its new fix, and every new fix carries the before/after diff against its predecessor, so you can scan what actually changed.

Safe to re-run. A bulk regenerate skips anything that was already archived or superseded earlier in the same pass, so a fix is never regenerated twice in one click — and re-running it after more traces arrive simply supersedes the current proposals with fresher ones.

The before/after diff

A regenerated remediation knows which proposal it replaced, so it can show you exactly what the new engine decided differently. The Regenerated from a previous proposal banner sits at the top of the fresh fix, and below it a before/after diff compares the old proposal against the new one:

Compared	Why it matters
Type	The remediation type — e.g. a `prompt_change` that became an `infra_advisory`
Root cause / failure locus	Where the failure lives — the single biggest thing a better engine tends to correct
Actionability	Whether it’s actionable, advisory, or non-actionable — i.e. whether your team ships it or routes it to a service owner
Summary	The one-line description of the failure and the fix
Artifact	The concrete change — the prompt before/after, the diff, or the advisory text

Read it as a receipt of what the new engine changed its mind about. If the locus flipped from “your agent” to “a downstream service”, that’s the headline — and it usually flips the actionability and the type with it.

What happens to the old proposal

This is the important part: nothing is deleted. When you regenerate, the previous remediation is:

Archived — moved to the archived work state so it drops out of your active backlog, exactly like any other archived fix.
Marked superseded — stamped with a link to its replacement and the time it was superseded. Open an archived, superseded remediation and you’ll see a Superseded by a newer proposal link to its successor.
Kept intact — its proof status and everything it earned are preserved. An already-applied or verified fix keeps its status and its history — the pull request, the commit, and the verification run stay attached. Regenerating never detaches the proof from a fix you already shipped; it simply drafts a new proposal alongside it.

Because the old proposal is preserved and restorable, regenerating is safe on a fix in any state — proposed, accepted, applied, verified, closed, or regressed. If the fresh proposal turns out to be worse, you haven’t lost the original.

⚠️

Superseding doesn’t un-ship anything. Archiving the old proposal is a bookkeeping move in Neens — it does not touch your codebase or roll back a change you already deployed. If you’d already applied the old fix, that change is still live in your agent; the archived record just stops competing for attention in your backlog. Work the new proposal through simulate → apply → verify on its own merits.

Walkthrough: a ticket failure that was never a prompt problem

Here’s the case regeneration is built for.

The original proposal

Weeks ago, a cluster of failing create_ticket sessions produced a remediation. The engine of the day read “ticket creation keeps failing” and drafted a prompt_change — a rewrite of the agent’s system prompt telling it to be more careful when filing tickets. It’s been sitting in your backlog as Proposed ever since, and no amount of rewording has made the failure go away.

Regenerate it

You open the remediation, click ⋯ → Regenerate, and confirm.

The new engine re-reads the evidence

The current engine looks at the actual evidence in the failing sessions — and finds that ~94% of them fail with HTTP 503 "connection pool exhausted" returned by the create_ticket tool’s own backend. That’s a downstream service outage, not an agent defect. No prompt rewrite can bring a service back up.

So instead of another prompt edit, it drafts an infra_advisory: the failure locus is downstream unavailable, the actionability is advisory, and the proposal names the owning service and recommends the resilience change that would actually help (bounded backoff with jitter, a circuit breaker, an idempotency key).

Read the diff

The before/after diff makes the correction obvious at a glance:

	Old proposal	New proposal
Type	`prompt_change`	`infra_advisory`
Failure locus	Agent reasoning	Downstream unavailable
Actionability	Actionable	Advisory
Artifact	A system-prompt rewrite	An advisory naming the ticket service owner + a resilience recommendation

Route it correctly

The old prompt_change is archived and marked superseded — still there if you want it, one click away via the Superseded by a newer proposal link. You route the advisory to whoever owns the ticket service, which is where the fix actually lives. You stopped polishing a prompt for a problem a prompt was never going to solve.

Remediations — the full fix loop and how proposals are generated in the first place
Issues and failure modes — where the evidence behind a fix comes from
Fix outcomes — measuring whether a shipped fix actually reduced the failure
Eval-verified PR — let Neens open a proven pull request for an actionable fix

Remediations Fix bundles