Recursive Refinement

Preamble

A correction can become doctrine too quickly. Recursive Refinement decides when repeated wins, failures, and user corrections deserve to change the system that will shape the next output.

---

Repetition Can Teach The Wrong Lesson

The loop is dangerous because every correction becomes future context. A bad preference can harden into a rule. A trend can masquerade as doctrine. A model-shaped phrase can return so often that it starts sounding like my taste.

Recursive refinement needs promotion rules. One successful output is evidence with limited authority. A repeated failure may reveal a weak pack, a bad ontology term, a wrong reference role, or my unresolved contradiction.

The How Is A Promotion Trial

Every system change should keep the trace:

output -> critique -> user judgment -> proposed change -> counterexample -> keep or reject

The record matters because the system is learning from the same machine it is trying to discipline. A correction needs lineage, counterexample, confidence, and a reason it deserves to shape later work.

One failed output may suggest a new anti-pattern. Three failures across different projects may justify a rule. A counterexample can quarantine the rule until I decide whether it captured taste or captured one bad day.

The First Rule Change Has To Be Reversible

The first proof is one small refinement after a failed output: demote a misleading term, add an anti-pattern, adjust a pack, or change a critique rubric.

When the loop fails to explain why the change was made and what would reverse it, refinement becomes aesthetic drift with a changelog.

The unresolved pressure is contamination. The system learns from my corrections, but my corrections may already have been shaped by the system. A distortion can become consistency if the loop promotes it often enough.