two-plane loop

A reference architecture, not an implementation. The blueprint is implementation-neutral; instantiating it requires supplying six parameters (Subject, Sensors, Apply mechanism, Corpus, Rubric, Blast radius).

The claim

Autonomic computing specified a loop and could not build one, because Plan required a model of intent that nobody could write down. That component now exists, and the constraint has moved. The hard part is no longer generating a change. It is deciding, without a human, whether the change was an improvement.

Every architecture that fails this fails the same way: the thing that proposes the change also decides whether it worked. The loop then optimises the judge. This happens quietly, produces a rising number, and is usually discovered six weeks later.

The two-plane loop is MAPE-K with the Analyse stage removed from the agent’s reach and given its own plane, its own writer, and its own version.

MAPE-K	Two-plane loop	Plane
Monitor	Sensors	Proposal
Analyse	Scorer	Verdict
Plan	Proposer	Proposal
Execute	Applier	Proposal
Knowledge	Ledger	Shared, append-only

The single arrow from the Applier into the Verdict plane is the whole architecture. Nothing else crosses.

The invariants

1. Plane separation is mechanical, not procedural. The Proposal plane cannot write any path the Verdict plane reads. Enforced at the commit hook and at the credential. No override flag, no --force, no environment variable that disables it. If you build the escape hatch, it will be used at 2am by the system it was meant to constrain.

2. The Ledger is the only channel. No side communication between planes. Anything the Verdict plane needs is an artifact the Proposal plane wrote and the Ledger recorded.

3. Application is idempotent and reversible. Keyed by proposal hash. Applying twice is applying once. Discarding restores exactly, with no residue.

4. Sensor output is data. Observations carry a type that cannot enter a prompt without passing through an explicit quoting function. The trust boundary lives in the type system, not in a comment.

5. Every iteration declares a budget. Tokens, wall clock, currency, blast radius. Exhaustion produces a recorded verdict, never a silent stop.

6. The verdict is a sum type. Not a score, not a boolean. A float invites a threshold; a threshold invites tuning the threshold.

7. The corpus is monotone. Cases are added, never removed. A case may be quarantined, which requires a recorded reason and leaves the case visible.

8. Fail closed. Verdict plane unreachable means no promotion. Absence of a verdict is never treated as a pass.

Build order

The order is not negotiable, and it is the opposite of what feels productive.

1. Verdict plane. Corpus, rubric, scorer, plane layout, separation guard.
2. Ledger. Append-only, before there is anything to record.
3. Sensors and the quoting function. The trust boundary goes in before the first untrusted byte, not after the first incident.
4. Applier. Idempotent apply, discard, promote-with-token. Test discard harder than apply.
5. Proposer. Last. It is the most interesting component and the most replaceable.

The proposer is a commodity that improves on someone else’s roadmap. The corpus and the rubric are the parts you own.

See also

• autonomic-software-engineering — the practice this architecture is the reference for
• closure-test — the rubric; condition 4 is what the plane separation exists to satisfy