Review and approve a Self-Learning proposal
Proposals are the AI’s concrete suggestions for fixing a recurring issue — a system-prompt edit, a knowledge article draft, a routing tweak. They land in Staged Changes and don’t take effect until you approve them.
Before you start
- Full access to Self-Learning. Limited or feedback-only access can view Feedback Groups and the Audit Log, but not Staged Changes.
- At least one proposal in the queue. If there aren’t any yet, your stack hasn’t received enough feedback to generate proposals — flag a few responses first.
Steps
- Open Settings → Self-Learning and click the Staged Changes tab.
- Each row in the queue is one proposal. The row shows the proposal type (prompt edit, KB article, handbook article, routing update, temperature adjustment), the specialist or stack it targets, and a one-line summary of what would change.
- Click a proposal to expand it. You’ll see:
The Feedback Group that triggered it (and how many flags went into it)
A diff: the current value on the left, the proposed value on the right
A summary of why the proposal was generated - Decide:
Approve — if the proposal can be applied to its target, the change deploys to your stack immediately. The proposal moves to “Deployed” status and an entry appears in the Audit Log.
Reject — the change is discarded. The Feedback Group stays open in case a different proposal makes more sense later.
Dismiss — useful for “this is fine as-is, stop suggesting changes.” The group is closed and won’t generate new proposals. - Repeat until the queue is empty (or until you’ve reviewed enough for one sitting).
Some approved proposals may be skipped instead of deployed if they cannot be applied to their target. Staged Changes can show these skipped proposals in an amber panel with the reason they were skipped. Skipped proposals remain staged and actionable, so you can still review, reject, dismiss, or approve them again after fixing the underlying issue. The Audit Log entry for the approval can also include skip details in its changes_deployed metadata.
Verify it worked
For an Approved proposal that was deployed:
- Check the Audit Log tab. The change appears with your name, the timestamp, and a copy of the before/after. If the proposal was skipped, the Audit Log’s
changes_deployedmetadata may include the skip reason instead. - For prompt-edit and routing-update proposals, open the targeted Agent Stack and confirm the change is reflected in the specialist’s system prompt or the routing rules.
- Test the stack with a question similar to the ones that triggered the feedback. The new behavior should match what the proposal promised.
If an approved proposal was skipped, check the amber skipped panel in Staged Changes for the reason. The proposal remains staged and actionable until it can be applied, rejected, or dismissed.
Reverting a deployed change
If a deployed change turns out to be wrong, you can revert it from the same Audit Log entry. Reverting restores the previous value and records a new audit entry — your stack stays auditable end-to-end.
Troubleshooting
-
Symptom: I can’t see the Staged Changes tab. Fix: Your tenant may be on feedback-only Self-Learning access, or your account may have limited access. Feedback-only and limited access can view Feedback Groups and the Audit Log, but not Staged Changes. Ask an admin to grant full Self-Learning access.
-
Symptom: A proposal looks risky and I’m not sure. Fix: Reject or leave it pending. Feedback Groups keep accumulating annotations even after you reject a proposal — a stronger pattern usually produces a better proposal next time.
-
Symptom: My approval didn’t seem to change anything. Fix: First check Staged Changes for an amber skipped panel. If the proposal was skipped, the panel explains why it was not deployed and the proposal remains staged and actionable. If it was not skipped, remember that some proposals (KB or handbook articles) create a new draft article rather than modifying the live behavior directly. Check Knowledge Base or Handbook for the new draft.