The execution chain

Concept

The execution chain

Most governance tools answer one question: was this call allowed? That answer is worth very little on its own. An auditor asking about a single API call six months from now actually needs seven answers, and each one has to be independently checkable.

Aarmos models those seven as a chain. Every other concept in these docs is a detailed view of one link.

  1. 01

    Authority

    Who is answerable for this being permitted at all?

    The root of every chain. Authority is held by a person or an organisation, never by an agent. Everything below it is derived, and nothing below it can exceed it.

  2. 02

    Invocation

    What started this?

    The trigger — a person typing, a schedule firing, another system calling in. An action whose invocation cannot be named is not governed, however well-behaved it looks.

  3. 03

    Actor

    Who is acting right now?

    The agent, sub-agent, or process taking the step. Actors are distinct from the authority behind them, which is what makes delegation auditable rather than assumed.

  4. 04

    Consequence

    What is being asked?

    The proposed business action being governed. It exists before policy decides whether execution may proceed.

  5. 05

    Effective policy

    Which rules apply, exactly?

    One resolved artifact with one digest, derived from every source that applies to this actor and this Consequence. The receipt cites the digest, so 'the policy said so' is checkable.

  6. 06

    Decision

    What was decided, and why?

    The policy result for the proposed Consequence: allow, deny, step_up, or defer, with the reason and contributing facts.

  7. 07

    Attempt

    What execution was tried?

    Execution after an allowing Decision. An Attempt is recorded separately because permission does not prove execution.

  8. 08

    Effect

    What change was observed?

    What the governed boundary can report after an Attempt. An Attempt does not by itself establish an Effect.

  9. 09

    Evidence

    What can be proved later, without us?

    A signed, hash-chained receipt that verifies offline against the open AVAR spec, long after the runtime that produced it has stopped.

Why the order matters

The chain is evaluated in order, and each link is admitted before the next is considered. Whether an actor may act at all is settled before anyone asks whether this particular action is permitted.

That sequencing is deliberate. If an expired delegation reached policy evaluation and came back allowed, the record would read as governed when it was not — a worse outcome than a plain refusal, because it survives review.

One chain, one set of semantics

The same chain is evaluated by the local runtime and the web app. There is one set of Decision semantics, not one per surface, so a policy result does not depend on where it was reached.

Keep reading

  • Effective policy — how many sources become one artifact with one digest.
  • Delegation — how authority travels to an actor, and how it is taken back.
  • Policy lifecycle — how a rule gets from an idea to something that governs.
  • AVAR receipts — what the evidence link actually contains.