Agent / client
An agent or client is the system that asks for something to happen.
Why it matters: the request starts here, but this component is not supposed to write directly into the target system through the boundary model.
Intent
Intent is the structured request submitted into the boundary.
Why it matters: intent is the starting point for evaluation, but it is not the same as external impact. The system can inspect it, check state against it, and decide whether it should become admitted work.
External impact
External impact is the real effect on the target system.
Why it matters: this is the thing the boundary is trying to control. An external impact might be a repository change, a ticket update, a room move, or a cloud resource change.
State
State is the current condition of the target system that matters for the decision path.
Why it matters: the agent's assumptions may be old. The system checks state so the decision path is based on current target context rather than only on model narrative.
State view
A state view is the governed form in which state is returned to the host.
Why it matters: the system does not need a raw database dump. It needs a bounded representation of the relevant target state.
Policy
Policy is the rule layer that evaluates whether a request should proceed.
Why it matters: policy brings explicit decision logic into the path. But policy is not identical to the final effect.
Policy candidate
A policy candidate is the result returned by policy before Core validates it.
Why it matters: this keeps policy from being mistaken for final authority. The system still needs to validate that the candidate fits the request and contract.
Core
Core means Impact Boundary Core v0.1 inside the binary/Docker bundle.
Why it matters: Core is the contract authority in the decision path. It validates whether the state, policy output, and decision envelope fit together well enough to become admitted work.
Core decision
A Core decision is the validated decision result after the decision path has passed through Core.
Why it matters: only certain Core decisions can create claimable work. This is the gate before materialization can begin.
Admitted
Admitted means the request passed the decision path and may become claimable work.
Why it matters: admitted is the key transition from evaluation to possible materialization.
Blocked
Blocked means the request did not pass the decision path and must not become materialized work.
Why it matters: blocked is not a transport failure. It is a deliberate result of the boundary.
Conflict
Conflict means the request cannot safely proceed without resolving a state mismatch or similar inconsistency.
Why it matters: this is the system's way of saying the world may have changed enough that the action should not move forward as-is.
Work
Work means a claimable unit created after an admitted decision.
Why it matters: it separates "the request was allowed" from "a worker is now permitted to attempt the effect."
WorkOrder
WorkOrder is the repo-doc term for the bounded handoff object given to an adapter worker.
Why it matters: this is the concrete object the worker claims before touching the target.
Claim
A claim is the worker's act of accepting a specific unit of admitted work.
Why it matters: the worker should not materialize before it has claimed the work. Claim is the handoff step between admission and effect.
Adapter
An adapter is the target-specific component that knows how to talk to the external system.
Why it matters: the boundary model keeps target-specific writes out of Core and out of the host decision path.
Materialization
Materialization is the moment the adapter performs the external effect.
Why it matters: materialization is where intent turns into real target impact. That is why the earlier stages exist.
Outcome
Outcome is the report of what happened after materialization was attempted.
Why it matters: outcome is separate from intent and separate from decision. It records the result of execution, not only the permission to try.
Adapter Host
The Adapter Host is the local runtime boundary in the public v0.1.0 bundle.
Why it matters: it connects clients, Core, state and policy connectors, adapter claim routes, and outcome submission.
Boundary
Boundary means the controlled path between request and external effect.
Why it matters: the boundary is the core product idea. It keeps intent, decision, work, and outcome from collapsing into one vague write step.
v0.1.0 bundle
The v0.1.0 bundle means the local Binary/Docker runtime and docs package.
Why it matters: the current public artifact is usable for building external adapters over HTTP, while still not being a full hosted product claim.
Fail closed
Fail closed means the system prefers to stop or deny the path when a required part of the decision flow is missing or invalid.
Why it matters: if state or policy cannot be used correctly, the v0.1 runtime should not quietly treat that as permission to materialize.
Example: if the policy connector is unavailable, the path should not silently become admitted work.