Autonomous Refinement Loop (ARL)
The ARL is a logical process for iterative skill refinement that operates without human intervention by replacing judgment gates with machine-verifiable conditions.
Core loop: Assess → Plan → Implement → Review → Repeat until converged or stopped.
When to Use
Activate the ARL when:
- A skill has quality issues requiring multiple improvement passes
- Iterative refinement is needed with measurable progress tracking
- Human-out-of-loop operation is desired for bounded improvement tasks
- Assessor has identified findings that require multiple iterations to resolve
- Convergence must be tracked objectively across iterations
Prerequisites before activation: Sufficient information must be available upfront to operate the loop without runtime escalation for missing context (R1 verification required).
Prerequisites: Information Completeness Gate (R1)
Before entering the loop, verify information completeness using the RT-ICA pattern (Reverse Thinking - Information Completeness Assessment). The loop cannot start without sufficient input.
What must be present:
- Skill's stated purpose and intended use cases
- Initial assessment findings with file:line evidence
- Refinement plan with acceptance criteria
- Knowledge of downstream references (what depends on this skill)
- Quality baselines (structural inventory before changes)
What R1 checks: Classify each information need as available, derivable, or missing. Block progression if critical information is missing.
When R1 activates:
- At loop entry (iteration 0)
- At re-entry after escalation
Failure state: Loop begins with missing information, produces wrong output that must be reverted, or escalates for information that should have been captured upfront.
SOURCE: Synthesis: ARL-Applicable lines 11-32, Human-Out-of-Loop Prerequisites lines 166-177
Loop Structure
One ARL iteration follows this gate activation sequence:
R1 (info completeness) → R5 (purpose anchor) → ASSESS → R3 (validity filtering) →
R7+R2 (convergence/loop check) → PLAN → R4+R8 (quality/proportionality) →
R10 (split justification) → IMPLEMENT → R6 (content-loss) → R9 (downstream impact) → Loop
Gate timing:
- Before assessment: R1 (information sufficient?), R5 (purpose drift?)
- After assessment: R3 (findings valid?), R7 (converging?), R2 (oscillating/stalled?)
- After planning: R4 (plan sound?), R8 (changes proportional?), R10 (splits justified?)
- After implementation: R6 (content preserved?), R9 (references still valid?)
SOURCE: Synthesis: ARL-Applicable lines 260-305
The 10 Gates
| Gate |
What It Checks |
When It Fires |
What Failure Looks Like |
| R1: Information Completeness |
Sufficient context to operate loop without escalation |
Loop entry, re-entry after escalation |
Loop proceeds with gaps, agent hallucinate-fills missing information, produces fluent but wrong artifacts |
| R2: Loop Detection |
Oscillating, stalling, or exceeding resource bounds |
Start of each iteration before assessment |
Loop runs indefinitely without converging, fix A breaks B repeatedly, same findings recurring |
| R3: Validity Filtering |
Findings have verifiable evidence (file:line citations) |
After assessment, before planning |
False positives consume iteration budget, regressions introduced, phantom issues trigger changes |
| R4: Plan Quality |
Plan internally consistent, addresses actual findings |
After planning, before implementation |
Inconsistent plan proceeds, addresses wrong findings, changes must be reverted |
| R5: Purpose Anchor |
Skill still serves original stated purpose |
Captured at iteration 0, checked each iteration |
After N iterations, skill optimized for assessor metrics but no longer serves original use case |
| R6: Content-Loss Detection |
All semantic units preserved after changes |
After implementation, before next iteration |
Refactoring removes sections deemed "redundant", no gate catches removal, human discovers loss later |
| R7: Convergence Tracking |
Findings decreasing, stable, or alternating across iterations |
Each iteration boundary after assessment |
Loop cannot determine progress, fixes trivial issues indefinitely, or oscillates without converging |
| R8: Proportionality Check |
Proposed fix proportional to finding severity |
During plan quality gate (R4) |
Low-severity finding triggers high-scope change that introduces risk without proportional benefit |
| R9: Downstream Impact |
All references still resolve after changes |
After implementation, alongside R6 |
Refactoring renames file, breaks three other skills linking to old path, not detected until invoked |
| R10: Split Justification |
New skill independently viable, not just parent-dependent |
When plan proposes splitting content |
Skill split into three pieces, two only invoked from parent, adds navigation complexity without value |
SOURCE: Synthesis: ARL-Applicable — each gate documented in sections R1-R10
Exit Conditions
The loop stops when:
- Convergence (R7): Finding count reaches zero or stabilizes below value threshold
- Failure state (R2): Oscillation detected, no progress across N iterations
- Insufficient info (R1): Cannot proceed without human input
- Max iterations: Safety limit reached (prevent unbounded execution)
Escalation vs termination: R2 failure states may trigger self-correction if recoverable, or escalate with diagnosis if not. R1 gaps always escalate to request missing context.
SOURCE: Synthesis: ARL-Applicable lines 304-305
Framework Patterns
The 10 R-requirements map to existing framework mechanisms at three coverage levels:
| Coverage |
R-Requirements |
Framework Patterns Available |
| Import directly |
R1, R3, R4 |
RT-ICA (SAM), GAN-inspired validation (Octocode/BMAD), 7-dimension plan checking (GSD) |
| Partial coverage |
R2, R5, R9 |
Bounded iteration count (GSD), objective injection (Ralph), downstream impact analysis (Octocode) |
| Build from scratch |
R6, R7, R8, R10 |
No framework provides content-loss detection, convergence tracking, proportionality checks, or split justification |
Key insights:
- R1 (RT-ICA): SAM's RT-ICA is one-shot; ARL needs re-triggerable RT-ICA within the loop
- R2 (Loop detection): No framework detects finding-level oscillation across iterations
- R5 (Purpose anchor): GSD has deviation rules within execution; ARL needs cumulative drift detection across iterations
- R6 (Content-loss): Entirely novel — no framework compares structural inventories before/after changes
- R7 (Convergence): Entirely novel — requires cross-iteration state tracking absent from single-pass pipelines
- R8 (Proportionality): Novel comparison of finding severity vs change scope
- R10 (Split justification): Novel independent viability assessment for extracted skills
SOURCE: Synthesis: ARL-Applicable — each R-requirement section includes framework pattern table
Universal Principles
The ARL applies seven universal patterns for autonomous development systems:
- Structure Over Instruction: Pipeline forces checks rather than asking agents to check themselves
- Front-Loading Reduces Runtime Gates: More context captured upfront = fewer human interventions during execution
- AI Cannot Reliably Self-Evaluate: Independent verification structurally separates producer from evaluator
- Compression Is Architectural: Information compression works when architecture forces it, not when instructed
- Iteration-Aware State Required: Loop control needs state persisting across iterations (convergence, oscillation, drift)
- Parallelism Enables Independent Verification: Multiple agents checking different dimensions simultaneously reduces shared blind spots
- Failure Paths Need More Compression: Escalation context needs better compression than success paths
Cross-reference: Synthesis: General Theory documents these patterns with evidence from 6 surveyed frameworks
References
Complete detail on each gate, framework patterns, and prerequisites:
1---2name: 659-description-skill-5956003e3description: Autonomous Refinement Loop for iterative skill improvement — Assess, Plan, Implement, Review, Repeat until converged. Machine-verifiable gates (R1-R10) replace human judgment at each phase. Use when refining skills through multiple autonomous iterations.4---56# Autonomous Refinement Loop (ARL)78The ARL is a logical process for iterative skill refinement that operates without human intervention by replacing judgment gates with machine-verifiable conditions.910**Core loop:** Assess → Plan → Implement → Review → Repeat until converged or stopped.1112## When to Use1314Activate the ARL when:1516- A skill has quality issues requiring multiple improvement passes17- Iterative refinement is needed with measurable progress tracking18- Human-out-of-loop operation is desired for bounded improvement tasks19- Assessor has identified findings that require multiple iterations to resolve20- Convergence must be tracked objectively across iterations2122**Prerequisites before activation:** Sufficient information must be available upfront to operate the loop without runtime escalation for missing context (R1 verification required).2324## Prerequisites: Information Completeness Gate (R1)2526Before entering the loop, verify information completeness using the RT-ICA pattern (Reverse Thinking - Information Completeness Assessment). The loop cannot start without sufficient input.2728**What must be present:**2930- Skill's stated purpose and intended use cases31- Initial assessment findings with file:line evidence32- Refinement plan with acceptance criteria33- Knowledge of downstream references (what depends on this skill)34- Quality baselines (structural inventory before changes)3536**What R1 checks:** Classify each information need as available, derivable, or missing. Block progression if critical information is missing.3738**When R1 activates:**3940- At loop entry (iteration 0)41- At re-entry after escalation4243**Failure state:** Loop begins with missing information, produces wrong output that must be reverted, or escalates for information that should have been captured upfront.4445**SOURCE:** [Synthesis: ARL-Applicable](./references/synthesis-arl-applicable.md) lines 11-32, [Human-Out-of-Loop Prerequisites](./references/human-out-of-loop-prerequisites.md) lines 166-1774647## Loop Structure4849One ARL iteration follows this gate activation sequence:5051```52R1 (info completeness) → R5 (purpose anchor) → ASSESS → R3 (validity filtering) →53R7+R2 (convergence/loop check) → PLAN → R4+R8 (quality/proportionality) →54R10 (split justification) → IMPLEMENT → R6 (content-loss) → R9 (downstream impact) → Loop55```5657**Gate timing:**5859- **Before assessment:** R1 (information sufficient?), R5 (purpose drift?)60- **After assessment:** R3 (findings valid?), R7 (converging?), R2 (oscillating/stalled?)61- **After planning:** R4 (plan sound?), R8 (changes proportional?), R10 (splits justified?)62- **After implementation:** R6 (content preserved?), R9 (references still valid?)6364**SOURCE:** [Synthesis: ARL-Applicable](./references/synthesis-arl-applicable.md) lines 260-3056566## The 10 Gates6768| Gate | What It Checks | When It Fires | What Failure Looks Like |69|------|----------------|---------------|------------------------|70| **R1: Information Completeness** | Sufficient context to operate loop without escalation | Loop entry, re-entry after escalation | Loop proceeds with gaps, agent hallucinate-fills missing information, produces fluent but wrong artifacts |71| **R2: Loop Detection** | Oscillating, stalling, or exceeding resource bounds | Start of each iteration before assessment | Loop runs indefinitely without converging, fix A breaks B repeatedly, same findings recurring |72| **R3: Validity Filtering** | Findings have verifiable evidence (file:line citations) | After assessment, before planning | False positives consume iteration budget, regressions introduced, phantom issues trigger changes |73| **R4: Plan Quality** | Plan internally consistent, addresses actual findings | After planning, before implementation | Inconsistent plan proceeds, addresses wrong findings, changes must be reverted |74| **R5: Purpose Anchor** | Skill still serves original stated purpose | Captured at iteration 0, checked each iteration | After N iterations, skill optimized for assessor metrics but no longer serves original use case |75| **R6: Content-Loss Detection** | All semantic units preserved after changes | After implementation, before next iteration | Refactoring removes sections deemed "redundant", no gate catches removal, human discovers loss later |76| **R7: Convergence Tracking** | Findings decreasing, stable, or alternating across iterations | Each iteration boundary after assessment | Loop cannot determine progress, fixes trivial issues indefinitely, or oscillates without converging |77| **R8: Proportionality Check** | Proposed fix proportional to finding severity | During plan quality gate (R4) | Low-severity finding triggers high-scope change that introduces risk without proportional benefit |78| **R9: Downstream Impact** | All references still resolve after changes | After implementation, alongside R6 | Refactoring renames file, breaks three other skills linking to old path, not detected until invoked |79| **R10: Split Justification** | New skill independently viable, not just parent-dependent | When plan proposes splitting content | Skill split into three pieces, two only invoked from parent, adds navigation complexity without value |8081**SOURCE:** [Synthesis: ARL-Applicable](./references/synthesis-arl-applicable.md) — each gate documented in sections R1-R108283## Exit Conditions8485The loop stops when:8687- **Convergence (R7):** Finding count reaches zero or stabilizes below value threshold88- **Failure state (R2):** Oscillation detected, no progress across N iterations89- **Insufficient info (R1):** Cannot proceed without human input90- **Max iterations:** Safety limit reached (prevent unbounded execution)9192**Escalation vs termination:** R2 failure states may trigger self-correction if recoverable, or escalate with diagnosis if not. R1 gaps always escalate to request missing context.9394**SOURCE:** [Synthesis: ARL-Applicable](./references/synthesis-arl-applicable.md) lines 304-3059596## Framework Patterns9798The 10 R-requirements map to existing framework mechanisms at three coverage levels:99100| Coverage | R-Requirements | Framework Patterns Available |101|----------|---------------|------------------------------|102| **Import directly** | R1, R3, R4 | RT-ICA (SAM), GAN-inspired validation (Octocode/BMAD), 7-dimension plan checking (GSD) |103| **Partial coverage** | R2, R5, R9 | Bounded iteration count (GSD), objective injection (Ralph), downstream impact analysis (Octocode) |104| **Build from scratch** | R6, R7, R8, R10 | No framework provides content-loss detection, convergence tracking, proportionality checks, or split justification |105106**Key insights:**107108- **R1 (RT-ICA):** SAM's RT-ICA is one-shot; ARL needs re-triggerable RT-ICA within the loop109- **R2 (Loop detection):** No framework detects finding-level oscillation across iterations110- **R5 (Purpose anchor):** GSD has deviation rules within execution; ARL needs cumulative drift detection across iterations111- **R6 (Content-loss):** Entirely novel — no framework compares structural inventories before/after changes112- **R7 (Convergence):** Entirely novel — requires cross-iteration state tracking absent from single-pass pipelines113- **R8 (Proportionality):** Novel comparison of finding severity vs change scope114- **R10 (Split justification):** Novel independent viability assessment for extracted skills115116**SOURCE:** [Synthesis: ARL-Applicable](./references/synthesis-arl-applicable.md) — each R-requirement section includes framework pattern table117118## Universal Principles119120The ARL applies seven universal patterns for autonomous development systems:1211221. **Structure Over Instruction:** Pipeline forces checks rather than asking agents to check themselves1232. **Front-Loading Reduces Runtime Gates:** More context captured upfront = fewer human interventions during execution1243. **AI Cannot Reliably Self-Evaluate:** Independent verification structurally separates producer from evaluator1254. **Compression Is Architectural:** Information compression works when architecture forces it, not when instructed1265. **Iteration-Aware State Required:** Loop control needs state persisting across iterations (convergence, oscillation, drift)1276. **Parallelism Enables Independent Verification:** Multiple agents checking different dimensions simultaneously reduces shared blind spots1287. **Failure Paths Need More Compression:** Escalation context needs better compression than success paths129130**Cross-reference:** [Synthesis: General Theory](./references/synthesis-general-theory.md) documents these patterns with evidence from 6 surveyed frameworks131132## References133134Complete detail on each gate, framework patterns, and prerequisites:135136- [Synthesis: ARL-Applicable](./references/synthesis-arl-applicable.md) — R1-R10 mapped to framework mechanisms, loop structure137- [Synthesis: General Theory](./references/synthesis-general-theory.md) — 7 universal principles for autonomous development systems138- [ARL Research](./references/autonomous-refinement-loop-research.md) — Problem definition, what replaces human judgment139- [Human-Out-of-Loop Prerequisites](./references/human-out-of-loop-prerequisites.md) — Conditions for removing human gates140- [Expert Panel Q&A](./references/qa-expert-panel.md) — Phase 1-2 expert panel findings141- [Autonomous Loop Principles](https://github.com/bitflight-devops/stateless-agent-methodology/blob/main/autonomous-loop-principles.md) — SAM extension analysis (cross-reference)
tools-only