operating model closed loop reasoning

Operating Model: Closed-Loop Reasoning

Language: 🇺🇸 English | 🇰🇷 한국어

Closed-loop reasoning is the default way Ghost-ALICE OS handles complex work. The agent does not reason once and stop. It compares the current state against references, identifies mismatch, and rewinds when needed.

The core claims are simple.

• Complex work is not one-shot reasoning; it is closed-loop reasoning.
• Verification is not post-processing; it is how the work proceeds.
• Verification strength should match verification burden.

Contents

• Six-Step Loop
• State
• Reference
• Mismatch
• Complexity Levels
• Relation To Skill Routing
• Practical Reading
• Related Documents

Six-Step Loop

Closed-loop reasoning repeats this flow.

1. Create a provisional state.
2. Bring out the reference.
3. Compare the state and the reference.
4. Identify mismatch.
5. Repair the state or escalate to a human.
6. Repeat until the stop condition is reached.

The important point is that mismatch must change the work. Explaining it away does not close the loop.

State

State is the provisional artifact being examined.

Examples include:

• current draft
• current claim
• current code
• current task plan
• current source-target mapping
• current install or update state

State is not finished work. It is a hypothesis until it has been checked against references.

Reference

Reference is what the state is checked against.

Common references include:

• schema
• SSOT
• evidence
• source locator
• user constraint
• target format
• platform contract

Without a reference, verification becomes a feeling. Ghost-ALICE OS tries to connect claims to references.

Mismatch

Mismatch is disagreement between state and reference.

Common forms include:

• logical inconsistency
• insufficient evidence
• schema violation
• overclaim
• source-target mapping error
• implementation/spec mismatch
• a formally valid result with the wrong meaning

Mismatch is a failure signal, but it is also evidence that the loop is working. The important response is to move focus up or down and repair the work.

Complexity Levels

Ghost-ALICE OS does not force the same loop strength on every task.

Level	Nature	Loop Strength
task-complexity-level-1	Obvious or low-recovery-cost work	One lightweight check
task-complexity-level-2	Work needing source choice, form mapping, or external evidence	Checkpoint-based comparison
task-complexity-level-3	Work involving claims, numbers, policy, research, implementation, and documentation	The loop is the work itself

More tool calls do not automatically mean task-complexity-level-3. Conversely, a short copy task can be task-complexity-level-2 if source selection and target mapping matter.

Relation To Skill Routing

The calls graph should be static and sparse. Repeated verification, re-reading, and mismatch-based repair do not all belong in the static graph.

Instead, Ghost-ALICE OS uses this structure.

• task-router identifies work meaning and candidate skills.
• boundary-contract locks allowed and prohibited surfaces.
• Each work unit is compared against references.
• Completion claims close through a claim-evidence-map.

This separation keeps the skill graph readable while allowing runtime verification to be as strong as the work requires.

Practical Reading

From a user's point of view, closed-loop reasoning looks like this.

• The agent fixes scope before execution.
• The agent re-checks files or evidence in the middle of work.
• The agent asks for evidence before claiming completion.
• Even a small edit can be reconsidered if it conflicts with the larger document or contract.

This behavior is not delay. It is the operating model for keeping the quality floor intact.

Related Documents

• Design Philosophy: Floor, Not Ceiling
• Operating Model: Fallback and Escalation
• Ghost-ALICE OS full design