When instructions stopped being enough

The rule was already there

In the early Terrain experiment, an agent could know a rule and still miss it during a busy session. Rewriting the instruction made the expectation clearer, but it did not always remove the opportunity to make the same mistake.

We started looking at repeated incidents as evidence about the operating environment. What condition had allowed the action? Was the system relying on memory at the point where it needed a check?

One incident made the gap concrete

An activation message was delivered through the wrong path. A new session received text intended for a particular successor, read the handoff, and began acting as that role.

The accidental sessions identified themselves and stood down when challenged. The delivery mechanism had failed to establish that the recipient was the intended process. Clearer role instructions alone would not have corrected that delivery problem.

The resulting gate checked that several identity signals agreed before activation could proceed. If they did not agree, it refused to pass. The detailed implementation stayed separate from the operating explanation.

Three honest states

The incident record distinguishes three states for a proposed countermeasure. A written rule sets an expectation. A mechanical counter blocks the action when its conditions fail. A pending counter still needs implementation.

Keeping those states separate prevents a comforting description from standing in for an actual control. A reviewer can ask what enforces the rule, where it runs, and whether the action can still happen through another route.

• Written rule: the requirement is documented and reviewed.
• Mechanical counter: an implemented check blocks the defined failure path.
• Pending work: the intended counter is not yet in place.

The limit belongs beside the result

The first activation gate covered three of four identified failure paths. The original trigger—rerouting a held message through another channel—still depended on doctrine at that point.

That is a useful result with a specific remaining gap. Describing it simply as “fixed” would erase the distinction that the next round of work depends on.

A gate can also contain defects or cover an incomplete model of the problem. Its existence does not prove that the surrounding system is reliable. We need to test the check itself and continue looking for routes it does not cover.

How this changed our loop

We now look for rules that keep being broken, then ask whether a small enforcement mechanism could remove that opportunity. Each incident records the failure, the proposed response, its implementation state, and any observed recurrence.

A counter that has not recurred over a short period is promising. It is still different from proof that recurrence is impossible. The observation window and the situations exercised need to travel with the claim.

This note reflects the early operating record from August 2026. Its most reusable lesson is a question: when a failure repeats, what would need to change in the system for following the rule to stop depending on memory?