Skip to content
Working modelProject

Autonomic Software Loops

Exploring how the control-loop idea applies to software changes that observe consequences and converge against a protected target.

State
working-model
Updated
2026-09-06
Owner
Tim
Area
autonomic-swe / control-loops / evaluation

Current question
What makes an engineering loop genuinely autonomic rather than an automation script with a model in the middle?

Read markdown

Why this exists

Automation can emit changes without establishing that the loop learned whether the change helped. The useful question is what separates an autonomic loop from a script with a model in the middle.

Current model

The repository or service is the managed subject. A work loop can observe, reason, propose, act, verify, and adapt; a governance loop observes task state, evaluates policy, evidence, and risk, exposes or revokes capabilities, and authorizes the next transition. The proposer remains separate from the verdict path.

What is unproven

This is a maintained architectural idea, not a claim that ReactorJet ships an autonomic software engineer. No new experiment or completed progress is implied by this entry.

Next experiment

Map one bounded repository-repair loop into work-loop and governance-loop states, including the failure path that reduces authority.

Artifacts

Open questions

  1. 01How should a protected target evolve without silently changing the meaning of an earlier verdict?
  2. 02Which failure modes should reduce authority instead of merely retrying?

Next

Compare the roles of target, proposer, applier, sensor, scorer, and recovery path in a bounded loop.