A cleared step does not clear the sequence
Action checks govern one step. Trajectory assurance governs whether the whole sequence stays within its authority and policy boundaries.
An action can pass every local check and still help produce a result the system prohibits. Control has to follow the sequence, not only its steps.
A sequence of individually permitted actions can collectively violate system constraints and safety invariants. A cleared tool call therefore proves only that one action met one check at one moment.
That gap grows with delegation. The paper identifies untrusted prompts, memory, retrieved knowledge, and tool interfaces as attack surfaces. It ties delegation to identity, trust, capability control, and decision transparency.
Those concerns meet in the trajectory. An agent can read allowed data, call an allowed tool, and send an allowed message. Their combination can cross an authority or policy boundary.
Put policy above execution
Ankur Sharma and Deep Shah propose a vendor-neutral reference architecture with two internal planes. The split gives sequence control a place to live without folding every concern into each action handler.
Their Control and Governance Plane holds intent, policy, trust, authority, confidence, auditability, observability, human oversight. It answers whether the work may continue and what evidence must survive.
Their Runtime and Coordination Plane holds agent lifecycle, workflow coordination, model and tool routing, context and memory coordination, scheduling, traffic management, runtime assurance. Runtime means the software that executes the work.
This boundary matters. Platform services and physical infrastructure remain outside the proposed architecture and connect through explicit interfaces. The design replaces no existing framework.
Record the route and judge the trajectory
Per-action checks still matter. Each check should bind an actor, authority, input, tool, and policy decision to the action it cleared.
Sequence control needs the ordered record around those checks. It can then evaluate accumulated effects, delegation changes, and the final result against system-level invariants.
Model origin is proof of which model ran. Runtime is the software that executes the work. Keeping those facts distinct prevents an execution record from becoming an unsupported model claim.
We covered an independent way to test model origin in Audit the backend from the text alone. That evidence belongs beside the trajectory record when model choice affects authority or policy.
Both papers present proposed designs. Neither paper reports production adoption. No paper author is a Muniment customer or endorser.
Muniment’s position is that a useful action record must support both decisions: why one step passed and why the whole sequence remained allowed.
Join the waitlist if your action records need to preserve that distinction.