Impact Boundary Labs

What changes when the target is yours

The bundle does not need to know your target-specific rules. Your adapter supplies them through three external roles:

POST /state reads the target at decision time
POST /policy returns a candidate such as admitted or blocked
the worker claims admitted work and performs the target-side effect

That means your existing domain logic can stay in your own codebase instead of being pushed into Core or Adapter Host.

One boundary, different targets

The pattern is the same even when the target looks very different:

Target shape	StateProvider reads	PolicyBoundary evaluates	Worker materializes
Repository adapter	branch, file, or pull-request state	whether that repository action is allowed now	open or update one pull request
Ticket adapter	ticket state, assignee, labels, or workflow step	whether that transition is allowed now	move one ticket or add one note
ImpactRoom-style reference adapter	room state, turn state, or allowed action state	whether the proposed room-side effect is admissible now	apply one room-side effect after claim

That is why "build your own adapter" is broader than one demo target. The bundle defines one path to external effect, not one fixed product integration.

What an adapter gives you

An adapter lets you keep your own target logic without collapsing back into a direct-write loop.

You keep:

your target-specific state access
your target-specific policy rules
your target-specific write logic
your target-specific outcome interpretation

You do not take over:

Core decision validation
admitted-decision creation
WorkOrder creation
host-side claim and outcome acceptance rules

That split is the point. Your adapter is not a second Core. It is the target participant that receives admitted work and performs the actual effect.

Why not just let the agent call the tool?

Because "the agent wanted to do it" is not the same as "the system should allow the external effect now."

A direct tool loop makes several important questions harder to answer later:

Was the action evaluated against fresh state?
Did any explicit policy participate?
Was there a formal admission step before the target changed?
Did a worker act on bounded work, or on whatever the model produced?
Is the result a decision, a materialized effect, or only an outcome report?

The boundary exists to keep those objects separate.

What your adapter does not have to solve

You do not need to build the entire system yourself.

You do not need to:

ingest browser or agent requests directly
validate Core decision records
invent admitted work from policy output
invent your own queue contract
bypass claim and lease handling

You only need to participate in the public external protocol.

The practical reason to care

If you already have a system worth connecting, the real question is simple:

"Can we keep our own target logic, but still require a formal path before real external impact?"