Review and feedback

What it is

Review is the human gate in every loop; feedback is what review leaves behind. Approvals, rejections, and corrections are captured as durable memory — they improve future proposals, runs, and predictions instead of dying in a meeting.

What it holds

• Approvals: explicit, placed where effects happen — workflow, branch, or node level, closest to external writes. Nothing commits on implication.
• Corrections: fixes aimed at the right layer — scope, mapping, definition, source data, or skill instructions. A correction teaches extraction, mapping, and prediction at once, which makes it the highest-value feedback there is.
• Rejections: refusals with reasons. "Wrong" without a reason cannot be learned from.
• Identity corrections: merging duplicates and fixing links, which teach resolution what "same" means in your business.

How it relates

• Feedback attaches to runs, proposals, skills (versions improve), and ontology (definitions and mappings get fixed, then rerun).
• Outcomes (what actually happened) combine with review to measure accuracy and direct improvement.
• Silence teaches nothing: unreviewed outputs neither confirm nor correct.

What this means for you

• Correct at the layer, not at the symptom — then rerun and confirm.
• Give reasons with rejections; future you will thank present you.
• Treat the feedback habit as the product: the loop compounds, meetings don't.

Image: feedback flowing from a reviewed run back into proposal, mapping, and skill versions.

Next

• Practice it: the flagship loop.
• Report problems well: Getting help.