> ## Documentation Index
> Fetch the complete documentation index at: https://docs.platform.nora.my/llms.txt
> Use this file to discover all available pages before exploring further.

# Improvement proposals

> Candidate fixes generated from the root cause — with diffs, predictions, and choices.

Once a root cause is known, Nora generates **proposals** — concrete changes that would address it. Usually 1-3 candidates per improvement. You pick which to simulate and which to ship.

## Anatomy of a proposal

Every proposal has:

* **A name** — short human summary ("Add refund synonym to retrieval keywords").
* **A lever** — which part of the system it changes (see [Levers](/reliable/optimization/levers)).
* **The diff** — exactly what would change, line-level.
* **A rationale** — why Nora thinks this addresses the root cause.
* **A prediction** — expected impact on the failing cluster and on holdout, based on similar past improvements.
* **A confidence** — how sure Nora is this will work.

The diff is the substance. Everything else is context.

## Example proposals

**For a retrieval-miss cluster**:

* P1: Add "money back" as a synonym to the retrieval preset's query expansion.
* P2: Boost the `refund-policy` tag by 1.3× in the preset.
* P3: Add a Rule to the Agent: "when the user asks about refunds, always look up the policy chunk first."

**For a prompt cluster**:

* P1: Add "Always cite the specific policy document" to the Agent role.
* P2: Change the Agent's tone instructions to be more explicit about disclaimers.

**For a data cluster**:

* P1: Ingest a new document with the missing information (surfaced as a note, not an auto-fix).

## Reviewing proposals

Proposals view shows all candidates side-by-side:

| Proposal | Lever            | Predicted improvement | Predicted cost delta | Predicted regression risk |
| -------- | ---------------- | --------------------- | -------------------- | ------------------------- |
| P1       | Retrieval preset | +12% cluster pass     | +\$0.001             | Low                       |
| P2       | Prompt           | +8% cluster pass      | 0                    | Medium                    |
| P3       | New rule         | +6% cluster pass      | 0                    | Low                       |

Click any proposal to see the full diff.

## Simulating

Click **Simulate** on any proposal to run it against the cluster + a broader dataset. Results feed back into the proposal card, replacing predictions with measured deltas.

You can simulate all proposals at once (comparison view — see [Before/after](/reliable/simulation/before-after)) or one at a time.

## Editing a proposal

Every proposal is editable before simulation. Common edits:

* Tighten the diff (remove pieces that Nora added that you disagree with).
* Change the target (apply to Agent A instead of Agent B).
* Modify wording (a prompt change Nora suggested but you'd word differently).

Edits are tracked so the audit trail shows what Nora proposed vs. what you shipped.

## Rejecting

Reject a proposal with a reason. Reasons help future proposal generation — Nora avoids similar proposals for similar clusters.

If you reject all proposals, the cluster stays open. You can:

* Diagnose again (maybe the root cause was wrong).
* Manually author a fix in Draft.
* Leave it — some problems aren't ripe to fix yet.

## The winning proposal

After simulation, the best-performing proposal is highlighted with a "recommended" badge. Usually the one with the highest holdout pass rate improvement and lowest regression count.

You can override — recommendation is a suggestion, not a decision. Especially useful when there's a tie or the differences are within noise.

## What happens after picking a winner

The chosen proposal moves to **Approval** (see [Approve & deploy](/reliable/optimization/approve)). Once approved, its diff is applied to Draft. Then you publish.