Run
- Software proposes an actiona specific consequential action
- A supported boundary mediateson a path established as enforcing
- Allow · Deny · Step up · Defera Decision with a reason
- Execution stays distinctAuthority, Attempt, and Effect remain separate
01The Problem
Software is about to take a consequential action. It may send an email, refund a customer, open a pull request, or move money. There is one moment on a supported enforcing path — before dispatch — where the applicable Decision and Authority can still govern execution.
Miss that moment and governance becomes archaeology.
02Why existing approaches fall short
Async review is not a gate. Nightly audits are not a gate. A dashboard someone will look at tomorrow is not a gate.
Rules bind a consequential action only when its path reaches a supported Aarmos consequence boundary established as enforcing. Other paths may be known bypasses, unconfirmed, or still unknown.
03The concept
Run enforces governed execution under the applicable Decision and Authority at supported consequence boundaries. Policy evaluation returns a Decision: allow, deny, step_up, or defer. A Decision is not Authority, an Attempt, or an Effect.
04How Aarmos applies it
Agents and software can propose the same consequential action through different frameworks and protocols. Aarmos governs it only when it reaches a supported consequence boundary on a path established as enforcing.
- Path state and path-set completeness are separate: an enforcing path does not make every route governed.
- Controlled qualification does not establish enforcement in a customer or live environment.
- A structured HTTP request can carry operation meaning; a coarse network connection cannot inherit it.
- For governed executions, evidence keeps Decision, Authority, Attempt, and observed Effect separate.
05Example
Suppose support software proposes a $9,400 refund through a supported structured-tool path. Policy returns step_up, requesting additional authority. If that authority is granted and a subsequent evaluation returns allow, Run may dispatch the action under both the Decision and Authority. The Attempt and any Effect observed at that boundary remain separate facts.
06Mini-FAQ
- Does one enforcing path cover every route to the action?
- No. Enforcement state belongs to a specific path. Other paths may be known bypasses or unconfirmed, and the complete path set may remain unknown.
- What happens when an enforcing boundary cannot authorize dispatch?
- That path does not dispatch without the applicable allow Decision and Authority. This does not make unwired, unconfirmed, or known-bypass paths governed.
- Can I use my existing policy engine?
- See the supported policy-gate interfaces and integration boundaries in the policy gate docs.