Skip to main content
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).
  • 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: 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) 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). Once approved, its diff is applied to Draft. Then you publish.