How to run it locally
The public v0.1.0 bundle is distributed as a local Binary/Docker artifact. Windows users can run the Adapter Host directly from the included Windows binary. Linux users can run the included Linux Adapter Host binary, and the minimal target adapter fixture is Linux-oriented.
macOS users should use the Docker Compose path because this v0.1.0 bundle does not include a native macOS binary. On Apple Silicon, Docker Desktop may run the Linux amd64 container path through emulation, so local networking and performance can vary by Docker setup. That is a packaging boundary, not a change to the Impact Boundary model.
This matters because the idea behind the project becomes much clearer once you can watch the steps happen in order. The v0.1.0 bundle lets a technically interested visitor move from theory to observation: submit an intent, see the state check happen, see policy return a candidate, see Core admit or block the path, see admitted work become claimable, and see an adapter report an outcome afterward.
What the v0.1 demo demonstrates
The v0.1 demo demonstrates the boundary pattern, not a hosted product. In concrete terms, it shows:
- a local runtime that accepts structured intent;
- a state check through an external connector;
- a payload-free policy request that returns a candidate decision;
- Core validation of that decision path;
- creation of claimable work only after admission;
- an adapter worker claiming work before materialization;
- outcome reporting after the effect attempt.
That sequence is the point of the v0.1 demo. It makes the intent-to-impact path visible in a way that a direct tool loop does not.
What to look for when using it
When someone first uses the v0.1 demo, it helps to watch for the transitions rather than the implementation details.
Intent does not immediately become impact
The first useful observation is that submitting intent does not itself touch the target system. The runtime accepts the request, but the write path still has to pass through state, policy, Core validation, and adapter claim.
State is checked before decision
The second observation is that state is part of the path. The system does not rely only on what the agent said. It performs a system-side check through the configured state connector.
Policy is visible, but not final by itself
The third observation is that policy participates without becoming direct authority. The v0.1 flow exposes the idea that policy can recommend an admitted or blocked route, but Core still validates the result before work can exist.
Work must be claimed before materialization
The fourth observation is that admitted work becomes claimable for an adapter worker. The worker does not write the target system just because the intent existed or because a policy response existed. It acts after a claimable handoff.
Outcome is a separate report
The fifth observation is that the system records the result after the worker acts. That separates "the system allowed this path" from "this is what actually happened."
The visible flow
The v0.1 demo is easiest to understand as a single visible sequence:
- submit intent;
- check target state;
- evaluate a policy candidate;
- admit or block the path through Core validation;
- expose admitted work to an adapter;
- let the adapter claim and materialize the effect;
- report an outcome afterward.
Each of these stages is visible in the bundle because the v0.1 demo is intentionally narrow. It does not try to hide the important control points behind a larger product surface.
Successful admitted flow versus blocked or no-impact flow
The v0.1 demo is also useful because it shows more than the happy path.
Successful admitted flow
In a successful admitted flow, the request passes the state and policy path, Core validates the decision path as admitted, work becomes claimable, an adapter claims it, and the worker reports a completion outcome after materialization.
This is the clearest demonstration of the architecture because it shows every step from request to effect.
Blocked flow
In a blocked flow, policy or Core prevents the request from becoming admitted work. The important thing to notice is that 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 flow
No-impact is different again. It belongs to outcome semantics, not to the decision stage. The request may have been admitted, but when the worker tried to perform the operation, the target may already have been in the desired state or the action may have turned out to produce no external change.
That distinction is valuable because it keeps the system from confusing "allowed to try" with "a real effect definitely happened."
Why the minimal adapter matters
The included minimal adapter is a local fixture. It is intentionally small and explicit. It can act as the state provider, the policy boundary, and the worker in a local loop.
This makes the v0.1 demo easier to evaluate because a visitor does not need to connect a sensitive repository, a production ticket system, or a cloud account just to understand the model. The fixture shows the shape of the protocol and the handoff behavior without requiring a high-risk target.
That is why the v0.1 demo is useful even for people who already know they will eventually build their own adapter. The fixture gives them a reference point before they start replacing target-specific pieces.
What the v0.1 demo is useful for
The v0.1 demo is useful for a few very practical reasons.
Understanding the boundary pattern
A diagram can say that intent is separate from impact, but the v0.1 demo lets you observe what that separation looks like in a running system.
Testing the adapter mental model
The v0.1 demo shows the responsibilities clearly:
- the host owns the route into Core;
- state and policy arrive through connectors;
- the worker claims admitted work;
- the target-specific effect lives with the adapter;
- the result comes back as an outcome.
That helps teams understand where their own adapter code would actually sit.
Seeing how impact is separated from intent
This is the deepest reason to run it. The v0.1 demo makes it obvious that an intent, a decision, a claim, and an outcome are different objects. That clarity is the heart of the product idea.
What the v0.1 demo does not prove
The v0.1 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 tenant controls;
- complete trust in arbitrary adapters.
It also does not replace human review or claim to be a complete operational control plane. The v0.1 demo is a demonstrator for the boundary pattern, not a claim that every production concern is solved.
No valuable real system is required
One of the strengths of the v0.1 demo is that the basic model can be understood without connecting it to a real high-value target. That lowers the cost of evaluation. A developer or founder can inspect the flow, see the separation between request and effect, and understand how an adapter would fit in before deciding whether to invest in a real target integration.
That is especially useful for teams that are still deciding whether they want stronger write controls around agent systems at all.
Practical summary
The live v0.1 demo is a local, inspectable demonstration of the boundary model. It shows how intent becomes a decision path, how admitted work becomes claimable, and how an adapter reports what happened after materialization. The included minimal adapter is a fixture, not a production connector. The v0.1.0 bundle is useful for understanding the architecture, testing the adapter mental model, and seeing the intent-to-impact separation in action. It is not proof of production security, durable runtime behavior, or semantic correctness.