Lab docs

Impact Room

Impact Room is a lab/demo direction for showing controlled external effects from agent proposals.

Lab/demo

Impact Room static reference environment showing an agent, scoped capability, boundary check, and guarded impact doorImpact Room static reference environment showing an agent, scoped capability, boundary check, and guarded impact door
Reference screen for the Impact Room demo surface.

What Impact Room is

Impact Room is a reference adapter for Impact Boundary Core and a local preview for state-bound agent impact. It works in two directions at once: a product demo you can run and inspect, and a learning artifact for adapter developers who want to see how public state, agent attempts, human approval, scoped permission, stale recovery, and admitted materialization fit together.

It is not just a room with a door and a key. The room exists so the engineering idea stays visible. An external agent starts with limited public knowledge. It reads guided state, sees public affordances, and tries actions that may or may not succeed. Some are blocked because the agent is at the wrong station. Some are blocked because it lacks approval. Some are allowed but produce no visible effect because the capability has gone stale. A fresh, valid capability can finally materialize visible impact. The visible story is simple on purpose. The point is not the room; it is the boundary behavior.

Two core ideas

State-bound impact. An agent is not judged only by what it wants to do, but against the state the system currently trusts, the policy for that state, and the capability evidence attached to the action. Opening the door is not a button press with a plausible label. It depends on a scoped key tied to the door's public state at a specific moment. If the state moves on and the key is no longer fresh, repeating the action more confidently does not make it valid. The agent gets blocked or no-impact feedback and has to continue from current state.

A public surface, not a control plane. The agent enters through a small public contract (/connect, /agent/state, returned action metadata) and never touches raw Broker, Host, Core, or WorkOrder internals. The browser is observer and operator, not the agent: it renders sanitized public projection and the operator moment when human approval is needed, and it is held to the same constraints as any external client. That separation is the design, not a cosmetic detail.

What the demo makes visible

A few moments carry the model:

  • Admin Override is real enough to tempt the agent, but stays blocked: operator authority is separate from agent authority.
  • Approval for a scoped key does not open the door; it only creates the conditions for a capability to exist.
  • A stale key shows the difference between possession and validity: it produces no visible door change.
  • A fresh key aligns with current state, and only then can a door-open action materialize.

Materialization is the part people notice in the room, but it is not the same as intention, policy evaluation, or even admitted work. Impact Room keeps those distinctions visible.

Where to go deeper