Impact Boundary Labs
GitHub
Documentation navigation

Core docs

Live v0.1 demo

The public v0.1.0 bundle exists so you can watch the boundary model run instead of only reading about it. It packages Impact Boundary Core v0.1 and the Adapter Host into a local binary/Docker bundle, plus a minimal adapter fixture that exercises the full flow without a valuable real system attached.

This page is about running it and knowing what to look for. For the model itself, see How it works.

Download the v0.1 bundleView on GitHubHow it works

Get the bundle

The bundle is published on GitHub: github.com/impact-boundary-labs/impact-boundary-core/releases. Each release includes the Windows and Linux Adapter Host binaries, a Docker Compose path, SHA256 checksums, and the minimal target adapter fixture.

Run it locally

Windows and Linux users can run the Adapter Host from the included native binary. macOS users use the Docker Compose path, since this bundle has no native macOS binary. On Apple Silicon, Docker may run the Linux amd64 container through emulation, so local networking and performance vary by setup. That is a packaging boundary, not a change to the model.

What to watch

The demo is most useful if you follow the transitions rather than the implementation details. Five are worth looking for:

  • Intent does not immediately become impact. Submitting a request does not touch the target. It still has to pass state, policy, Core validation, and an adapter claim.
  • State is checked before the decision. The system does not rely only on what the agent said. It performs a system-side check through the state connector.
  • Policy is visible but not final. The flow shows policy proposing an admitted or blocked route, while Core still validates the result before work can exist.
  • Work must be claimed before materialization. Admitted work becomes claimable for a worker, and the worker acts only after that handoff, not just because an intent or a policy response existed.
  • Outcome is a separate report. The system records the result after the worker acts, which keeps "the path was allowed" distinct from "this is what actually happened."

Admitted, blocked, and no-impact

The demo shows more than the happy path, and the difference is the point.

In an admitted flow, the request passes state and policy, Core validates the decision, work becomes claimable, an adapter claims it, and the worker reports completion after materialization. That is the clearest end-to-end view of the architecture.

In a blocked flow, policy or Core stops the request before it becomes admitted work. Blocked does not mean the agent failed. It means the system deliberately stopped the path before external materialization. That is the boundary doing its job.

No-impact is different again. It belongs to outcome semantics, not to the decision. The request may have been admitted, but when the worker tried to act, the target was already in the desired state or the action produced no external change. That keeps "allowed to try" distinct from "a real effect happened."

Why the minimal adapter matters

The included adapter is a local fixture: small, explicit, and able to act as state provider, policy boundary, and worker in one loop. It lets you evaluate the model without connecting a sensitive repository, a production ticket system, or a cloud account. You see the shape of the protocol and the handoff behavior without a high-risk target, which is useful even if you already know you will eventually build your own adapter.

What it does not prove

The demo is intentionally local and bounded. It does not prove production security, durable queues, exactly-once execution across failures, semantic correctness of agent output, hosted identity, or complete trust in arbitrary adapters. It is a demonstrator for the boundary pattern, not a claim that every production concern is solved. The right question to bring to it is simple: does this model make the path from agent request to external effect clearer and more controllable?