This document is the orientation page for SADAR's execution model: how a capability that has already been declared, matched, and discovered becomes a governed action at runtime.
It covers what "execution model" means in SADAR's particular sense:
This page is the companion to Core Functional Model. That page covers:
This page picks up after a match is made: what happens at invocation and through a multi-hop chain, and how authority and intent are evaluated at each step.
The normative basis lives across multiple sources.
This page frames how those pieces compose into a single execution pattern and is referenced rather than re-derived in each.
Audience: enterprise architects evaluating SADAR for runtime governance; implementers building or integrating an enforcement framework; planner-agent developers; and security architects reasoning about authority propagation and revocation across organizational boundaries.
In conventional software, the logic that sequences operations, checks preconditions, and authorizes actions lives in application "glue" code — the caller that composes functions, modules, and APIs. That arrangement works because the caller holds global knowledge of a composition that is fixed at authoring time. The flow's correctness is implicit in the code path: there is no separate artifact to check against, because the flow is the code.
Agent flow within SADAR's execution model is structurally different in three ways, and each difference removes one of the assumptions the conventional model depends on:
The execution model is therefore the union of: a discipline separating what may be held from what must be decided live; three trust regimes that carry authority without granting it; a substrate/enforcement split that determines where authority becomes binding; and a four-axis gate that every step must pass. The remainder of this page covers each.
A single discipline runs through every layer of the execution model:
No verified-once artifact — an identity, a signature, a cache entry, or a token — may stand in for a decision that must be made here and now by the party that owns that decision.
This is the same principle that motivates SADAR's rejection of identity-based authorization, generalized from identity to time. An attribute verified once, elsewhere, is never permitted to impersonate a decision that must be made with current context by its rightful owner. The model achieves this by keeping two things strictly distinct at every layer: the artifact you can hold onto, and the decision that must stay live.
Read top to bottom, the manifest owns "what is this," the issuer owns "may you start," the server owns "may you continue," and the enforcement layer owns "is this appropriate, here, in this chain." Four owners, four live decisions, four independently bounded artifacts that make those decisions cheap to act on without ever making them stale.
Three artifacts carry trust through a chain. Each vouches for something different, and — critically — none of them grants the next one's decision.
A few properties of each are worth stating explicitly, because they are where the regime earns its place.
The manifest's signature defers rather than grants. A signed manifest that points the recipient at an authentication endpoint is doing the opposite of a credential that asserts authority. Its signature vouches for the declaration — this capability, this identity, these endpoints — and then explicitly hands the authorization decision to the live endpoint it names. It is the introduction, not the grant.
The token is a one-thing-once permission, not a bearer capability. Scoping the token to the declared intent (from the SCT), the transaction-instance UUID, the component (agent / tool / resource) id, and a replay nonce means the token cannot be repurposed even by its legitimate holder — its authority is pinned to the appropriateness frame the SCT declared. The issuer sets the TTL; the holder uses the token until it expires and then refreshes; the server may reject it at any time for revocation, deprecation, or posture change, forcing reauthentication to obtain a new token. The TTL bounds optimism; the revocation right bounds the TTL. Together they yield a live authority decision at cached cost.
The SCT makes authority available, not enforced. The SCT presents the same originator facts at every hop, whether or not anything acts on them. Making those facts binding is a separate concern, addressed next.
SADAR is the substrate; it does not enforce. This division is deliberate and load-bearing.
The substrate makes the originator's authority and the declared intent legible — uniform, passive, and present at every hop regardless of whether anything consumes it. The enforcement layer makes that authority binding — elective, active, and present only where an enforcement framework actually runs. SADAR exposes the facts; an enforcement framework decides to treat them as a continuous obligation and applies policy against them.
This is why revocation in SADAR is per-server, not per-chain. The chain is dynamically defined and mutable, so there is no fixed composition for the substrate to revoke across — any chain-aware revocation would require the substrate to know a topology it has deliberately refused to assume. Instead, a server reserves the right to force reauthentication at any time; the token semantics make that seamless except for latency. A server (or the enforcement framework running at it) may revalidate the originator's authority — not merely the immediate requester's — to detect that the root authority has been revoked. Containment is not propagated through the chain; it is independently rediscovered at each server that elects to look.
The consequence is a security model worth stating plainly, because it differs from "the protocol guarantees X": end-to-end guarantees are a property of which servers run enforcement, not a property of the chain itself. The substrate is uniform — the SCT is present throughout — but the strength of any end-to-end guarantee is proportional to enforcement density along the path, and silent wherever enforcement is absent. A chain with enforcement only at its edges has end-to-end intent checked only there; a chain with enforcement at every hop has continuous containment.
The enforcement layer provides the sequencing and fine-grained checks that used to live in the application logic that glued functions, modules, and APIs together. Relocated out of the caller — which no longer has global knowledge — and out of the components — which are context-free by design — those checks become declarative and chain-aware.
An enforcement framework dynamically assembles the applicable policies based on four things:
It reads the component's structural declarations from the manifest — what the component performs, what it does_not_perform, and the prerequisites it expects_completed — and evaluates them against the live chain instance. Two kinds of gate result, and they have different authors:
The decision to apply a step is the conjunction of what the component says it needs and what policy says is permissible here, for this originator, for this intent, at this step.
Because the planner and the enforcement framework consume the same process definitions — the planner as reusable execution-plan templates, enforcement as the prerequisite/exclusion model — they share a vocabulary. A rejection can therefore be expressed in the terms the planner builds with: "this step requires process X's steps a, b, and c to have completed first." That makes the feedback a repair instruction rather than an opaque denial, and turns enforcement from a firewall into a control loop.
The components stay ignorant throughout. An agent, tool, or resource can appear in any combination of chains, so it has neither the visibility nor the standing to make these checks. The check is chain-scoped; the component is context-free. The component can only honestly declare its requirement; only the layer holding the chain instance can evaluate it.
A step is permitted only when it passes four independent checks, each owned by a different party and answered against a different artifact:
The action proceeds only on the conjunction. This is the imperative glue's job, decomposed into four declarative checks that no single party holds, reassembled live by an enforcement layer that holds the only thing spanning them — the instance of the intent itself. Capability lives in the component; authorization in the SCT; sequence in the attested completion record; scope in the originator's declared intent.
The action proceeds only on the conjunction. This is the imperative glue's job, decomposed into four declarative checks that no single party holds, reassembled live by an enforcement layer that holds the only thing spanning them — the instance of the intent itself. Capability lives in the component; authorization in the SCT; sequence in the attested completion record; scope in the originator's declared intent.
The fourth axis is the one conventional glue never enforced, because in a monolith the intent was the code path. SADAR makes intent an explicit, declared, checkable artifact.
A SADAR Process Definition (SPD) is a graph of IRI steps expressed in a cypher-like syntax in the registry (see Process). It is a definition, not the definition — there may be any number, business or technical, and none is canonical. This pluralism is deliberate: it sidesteps the ontology-ratification problem that defeats most enterprise process-modeling efforts, because the definition is chosen per-intent by the originator rather than imposed globally.
The originator declares end-to-end intent by selecting a process definition; each step's intent is then assessed against the overall intent. Where the originator calls a single agent without an explicit definition, that agent's capability set serves as the implicit intent definition. The scope gate is therefore always armed — the floor is never undefined. The absence of an explicit process definition does not mean "anything goes"; it means "bounded by the one component actually invoked." Scope-checking is structural, not a feature that can be switched off — only widened or narrowed by what intent is declared.
Prerequisites are expressed in IRIs, and their presence with a completed status in the SCT is the proof they were performed. The check is literal set membership over attested facts — there is no ontology to subsume through, so it is deterministic by construction. This also fixes the integrity boundary: an unenforced or non-emitting hop writes no completion into the SCT, so its prerequisite is unsatisfiable downstream. The same enforcement-density parameter that bounds the revocation-containment window also bounds the completeness of the sequencing record — sequencing guarantees are exactly as strong as enforcement is dense, and silent where it is not.
Worked example. Consider a step that would delete a production database. If that deletion is not a step in the declared process, it is denied — regardless of why it was attempted, regardless of whether the originator actually holds that right, and regardless of whether the agent called holds that right. Scope of intent governs independently of motive, identity-rights, and capability. The action is out of scope for the intent that was declared, and scope is a property of the composition, not of any actor in it. This is appropriateness-over-correctness expressed as a runtime gate.
The parts of the execution model compose into a single runtime pattern:
The execution model is not a static description of the architecture; it is the runtime substrate through which every governed action passes. The substrate guarantees the availability and legibility of authority and intent; the deployment's enforcement topology determines what is actually guaranteed about them.
This page covers the execution model as an architectural framing. Several adjacent topics are intentionally out of scope and live in dedicated documents:
The enforcement framework's internal policy engine Out of scope. SADAR specifies the substrate an enforcement framework consumes — the legible authority and declared intent — not the engine that evaluates policy against them.