Impact Boundary Labs
GitHub
Documentation navigation

Core docs

Impact Boundary Core

Core is the foundation for Impact Boundary Labs. It models structured intent, admission, state binding, impact, verification, and evidence.

Foundation / contract layer

What Impact Boundary is

Impact Boundary is a control layer between an agent's intent and a real external effect. An agent decides what it wants to do, but it does not write directly into the target system. It submits a structured intent. The system checks current state, evaluates policy, validates the decision path inside Core, and only then exposes admitted work to an adapter that performs the target-specific change.

The distinction that is easy to miss: reading context and writing impact are not the same operation. An agent may need broad context to reason well. A write changes a repository, a ticket, a room, an account, or a cloud resource, something with consequences outside the model. Those two paths should not be treated as equivalent.

The problem in plain terms

Agents are increasingly wired to tools that perform real actions. That is useful, but it makes the action path hard to reason about. When a model opens a pull request or changes a cloud resource, several questions matter at once: what exactly was requested, what state it was evaluated against, which policy allowed it, whether it was formally admitted before a worker touched the target, and what actually changed afterward.

Without a boundary, those collapse into one vague idea: "the agent did something." That is too weak for a system anyone has to operate, constrain, or audit.

The write path

Reading can stay direct and product-specific. Writes go through a narrower path:

  • the agent submits intent;
  • the system checks target state;
  • policy evaluates whether the request should proceed;
  • Core validates the decision;
  • only admitted work becomes available to an adapter;
  • the adapter materializes the effect;
  • the adapter reports an outcome.

The sequence is the product. It keeps a successful tool call, a policy response, and a real effect from being treated as the same event. Three checkpoints in that path carry the real weight:

  • State is checked system-side, not "the agent already looked at it." The state read is part of the decision, so it can act as a gate rather than a claim.
  • Policy returns a candidate, not a verdict. A policy result still has to fit the Core contract and the current request. Policy proposes; Core admits.
  • Core is the gate before work exists. It validates that state and policy output fit the expected shape, status, reason, and next action. It does not prove the change is semantically correct; it decides whether admitted work may be created at all.

Only after admission does the runtime create a WorkOrder: a bounded handoff that an adapter worker can claim, not a raw client request and not a free-form tool call. When the worker finishes, it reports an outcome, the system's separate record of what actually happened, distinct from the original request.

Read directly. Write through the boundary.

That is the shortest useful way to hold the whole model in your head. Reading may be broad. Writing must be explicit, bounded, and inspected through a decision path before it reaches an adapter.

Where this applies

The pattern fits anywhere an agent is connected to a system that matters operationally: repositories and pull requests, issue and ticket systems, workflow boards, account and entitlement actions, cloud and infrastructure controls, or any internal tool with a mutation endpoint. The common thread is not the product category. It is that the agent is no longer only generating text; it is on a path that can change a live system.

What it is not

Impact Boundary is easy to over-read the moment you see the word "security." The current v0.1.0 bundle does not make that claim. It is not an agent framework, not a semantic-correctness proof, not a replacement for human review, and not a claim that policy output alone is sufficient or that every admitted request is wise. It is a structured gate between intent and effect: a narrower claim, and the one the bundle actually supports.

What the bundle demonstrates

The public v0.1.0 bundle runs the model end to end on a local machine: Impact Boundary Core v0.1 compiled into the runtime, and an Adapter Host that exposes HTTP routes, talks to state and policy connectors, and hands admitted work to adapter workers. A minimal fixture adapter completes the loop, so the whole flow (intent, state check, candidate decision, admission, claimed work, materialized outcome) can be watched without wiring in a valuable real system. That makes it useful for architecture evaluation, adapter design, and early security review. The value is not a promise that the model is right. It is that external impact gets a clear path, a visible gate, and a concrete handoff.