review and improve

A process only gets better if somebody checks what comes out. You decide who: you, the pixie, both, or nobody. When a result misses, you say why, and the lesson can travel back into the process so the next run starts better.

choose how results are checked

The chip in the Runs header, next to Template, sets this for the process. It shows a short form: auto, human, self×3 or self×3+human.

option	what happens
auto approve	results publish the moment the pixie submits them
human review	results are staged; they publish when you approve (the default)
self review	the pixie critiques its own results and retries before publishing on its own
self + human	the pixie self-reviews first, then results wait for you

In the two self options, a self-review retries stepper sets how many critique passes the pixie gets: 1 to 10, default 3. The chip can also read inherit where a layer above supplies a default: a process inherits from the canvas default, and a pipeline card inherits from the process it points at.

approving a result

With human review, the pixie stages its results and a review card appears in the run's chat, with the actual previews on it. Nothing is published yet.

Only a result you clicked to approve publishes. The pixie cannot approve its own staged work. Approve publishes immediately, with no further pixie turn. The results then appear in the run's Results cell and the node's tray.

Email and API runs have nobody to click, so they never stage; they publish directly.

rejecting with notes

On the review card, Not yet opens a box: What's wrong, or what should change? Write the reason and press Send feedback, or Decline without feedback. A reason is worth the few seconds: with none, the pixie asks what fell short before it touches anything.

review mode

A rejection moves the run's pixie into Review mode. You don't pick this mode; it starts because you declined, and the dock shows it locked. In Review mode the pixie:

1. says in one line which stage caused the miss and why, instead of just trying again;
2. reworks that stage, up to three attempts, checking the new result against your note;
3. stages the fix for your approval.

feedback the pixie remembers

The pixie writes what you reacted to as a sticky note starting FEEDBACK: and pins it to the stage it concerns. Every later result is checked against those notes before it is submitted. Taste-level lessons go into the pixie's memory. Both stay with the process, so runs after this one start with them.

telling the process what it learned

After you approve the fix, the pixie asks whether the miss was only about this request or whether the process would hand the same flaw to every run. If it is the process, it asks for a one-click go-ahead, then files a report with the process's template owner; the owner updates the template so the next run starts fixed. If you decline, nothing is sent, and the lesson stays as a note in the run.

folding a good run back

When a change inside one run proves the whole process better, such as a stronger model, a better prompt or a new stage, you can promote it. Ask in the run's chat: "update the base process with what we changed." The pixie offers an approval card first. On Approve it:

• replaces the template's canvas with the run's canvas, cleaned of run leftovers;
• syncs the run's declared inputs and outputs to the process node;
• merges the run pixie's new memories into the resident's.

Runs you start afterwards use the new template. Runs already in flight keep the one they cloned.

limits & good to know

• Self-review retries: 1 to 10, default 3.
• A rework in Review mode gets up to 3 attempts per rejection.
• A rejected run keeps its history; Run again is the way to try fresh.

related

• runs — where staged and published results appear.
• approvals — the same policy across a pipeline.
• make a process