Concept

Invocation, actors and admission

A governed action is not just an outbound call. Something triggered it, someone or something is accountable for it, and other systems may have contributed the facts it relied upon. An invocation is the unit that holds all of that together — one admitted trigger, the actors that ran inside it, and the decisions they attempted.

Admission: the door, not the scheduler

Aarmos does not schedule work. It admits it. When your scheduler, queue consumer, or webhook receiver is about to start a run, it asks for admission with the upstream delivery or run id. Aarmos either admits the trigger as a governed invocation or refuses it with a stated reason — and either way that answer is recorded. Replaying the same trigger key does not silently start a second run.

aarmos admit request --trigger-key "sched-2026-08-10T02:00Z"
aarmos admit log

Actors and lineage

Multi-agent systems fan out. Inside one invocation, Aarmos tracks which actor spawned which and how it knows — because attribution you cannot justify is worse than an admitted gap.

Basis	What it means
Observed	The runtime saw this actor act. The strongest attribution Aarmos can make on its own.
Declared	An adapter reported a spawn edge. It is an attribution claim by the adapter, recorded and marked as such — never upgraded to observed.
Unattributed	Activity inside the invocation that no actor claimed. Aarmos reports the gap instead of assigning it to the nearest parent.

aarmos lineage show
aarmos lineage list
aarmos status --actors

Per-actor coverage is reported the same way runtime coverage is: if an actor's activity was never observed crossing the gate, Aarmos says so rather than counting it as governed.

Participants contribute facts, not rules

A decision often depends on something only another system knows — a credit limit, a change window, a risk score. Those systems are registered as participants and asked for facts. Aarmos never hosts their rules and never fetches policy from them: a participant answer is an input to the decision, recorded with the decision, and revalidated when the attempt resumes.

aarmos participants add risk-engine --endpoint http://127.0.0.1:9100 --transport local
aarmos participants check
aarmos participants ask risk-engine

Approvals are revalidated at resumption

A human approval is a contribution bound to a specific attempt digest and the policy version in force when it was given. When the attempt resumes, every contribution is checked again — against the policy in force at that moment and the approver's authority at that moment. An approval that has lapsed, or an approver who has since left the scope, does not carry a stale decision across the line; the attempt asks again.

aarmos approvals list
aarmos approvals show <attemptDigest>
aarmos approvals approve <attemptDigest>

The evidence durability boundary

Evidence is committed to durable storage before the governed action is allowed to run, not after it returns. The ordering matters: an action that executed but was never recorded is the one failure mode governance cannot recover from.

If evidence cannot be durably committed — a full disk, a read-only workspace — the runtime refuses the action rather than proceeding unrecorded. Proxied requests get a 503, the CLI exits 16, and the message says nothing was recorded because nothing ran.