| title | Governing Risk with Agents: An Architecture Study of Jido on the BEAM |
|---|---|
| status | Working Draft |
| version | 0.1 |
| date | 2026-07-31 |
| author | Mike Hostetler |
| source_commit | 17fbce2b1c53a46093be92dc59561e2a18b8f775 |
| declared_project_version | 2.3.2 |
Working Draft - not peer reviewed
Mike Hostetler, AgentJido
31 July 2026
Autonomous agents create operational risk when delegated software makes decisions and causes external effects under uncertainty. Prompt and model controls address only part of this risk. Malicious input, faulty decisions, excess authority, process failure, retries, and service failure can produce unauthorized, duplicate, missing, or outcome-unknown effects. Useful autonomy cannot remove all uncertainty. Operational governance therefore needs explicit authority, effect control, failure containment, recovery, and evidence.
This paper studies Jido as a model-independent agent software development kit (SDK) and BEAM-native runtime. The studied source is commit 17fbce2b1c53a46093be92dc59561e2a18b8f775. Its Mix project declares version 2.3.2. This is a commit study, not a study of a v2.3.2 tag. Jido separates an immutable Agent, a replaceable Jido Strategy, Signals, plugin hooks, typed Directives, and the AgentServer runtime. Core has no large language model (LLM) dependency. This fact supports controller independence, but it does not prove safety.
The central result is narrow. Application policy can remain outside unlike Jido execution Strategies for operations represented by the same domain Signal and routed Action. On this managed path, prepare_action/3 runs after routing and before Strategy.cmd/3. Work created inside a Strategy does not automatically receive this check. Controller-created follow-up work is governed only if it returns through AgentServer routing. A deterministic paper-only check found the same allow and deny outcomes across Direct, finite-state-machine, and recorded-proposal Strategies. It also confirmed the escape path, separate Directive telemetry, one local supervised restart, and explicit checkpoint thaw. These observations do not establish calibrated risk reduction, complete mediation, durable effect delivery, or general framework superiority.
Keywords: agent architecture; operational risk; runtime policy; BEAM; Erlang/OTP; Jido; reference monitor; fault containment
An agent can do more than return text. It can change a configuration, send a message, schedule work, start a process, or call an external service. These effects create an operational control problem. The decision method matters, but the execution architecture also matters. A correct control must run at a point that can see the proposed operation and block it before authority is used.
Model-level controls are not enough for this purpose. Direct and indirect prompt injection are specific threats, but controller bugs, stale state, wrong routing, excess credentials, retry races, lost acknowledgements, and process faults can lead to the same operational events. The Coalition for Secure AI (CoSAI) Shared Responsibility Framework threat data assigns prompt-input mediation to the application layer for the common deployment models. This paper makes the same ownership distinction. It does not claim that Jido prevents prompt injection.
The National Institute of Standards and Technology (NIST) Artificial Intelligence Risk Management Framework (AI RMF) 1.0 treats governance, mapping, measurement, and management as connected risk functions [1]. The Basel Committee also separates operational risk management from resilience, while it connects both to change, technology, recovery, and third-party dependencies [2, 3]. These sources support a system view. They do not validate Jido or the study result.
Many agent descriptions combine a model, prompt loop, tools, memory, identity, and runtime into one component. That combination makes the control boundary hard to locate. Jido separates several roles. An Agent holds immutable state and a command contract. A Jido Strategy selects or executes normalized work. Application or third-party code can supply the controller and harness. AgentServer hosts the live Agent, routes Signals, invokes plugin hooks, and drains Directives. The BEAM virtual machine and Erlang/Open Telecom Platform (OTP) supply processes, mailboxes, monitors, and supervision.
This study asks two questions:
RQ1 - Control stability. Which domain contracts, policy artifacts, and policy outcomes remain stable when the Jido Strategy changes?
RQ2 - Managed-path coverage. Which operations can configured Jido plugins and AgentServer observe or block, and which operations exceed that boundary?
The paper also checks three supporting boundaries: direct Action I/O versus Directive execution evidence, one supervised AgentServer restart, and explicit hibernate/thaw. It does not measure enterprise loss, attack success, broad performance, or production reliability.
The contribution is an exact boundary claim, not a product claim:
Application-supplied policy can remain outside and stable across unlike Jido execution Strategies for an operation represented by the same domain Signal and routed Action. This property applies only while consequential work returns through the AgentServer-managed route.
The word agent often hides several different components. Table 1 fixes the terms for this study.
Table 1. Study terms and ownership.
| Term | Meaning in this paper | Primary owner |
|---|---|---|
| Agent | An addressable software entity with immutable state and a command transition contract | Jido contract plus application definition |
| Controller | A mechanism that selects, orders, or creates work; examples include rules, an FSM, a planner, a behavior tree, or an LLM | Application or integration |
| Jido Strategy | Jido's replaceable execution contract that receives normalized Instructions through Strategy.cmd/3 |
Jido contract and Strategy implementation |
| Harness | Code that builds prompts and context, loads memory, exposes tools, handles model results, applies approvals, loops, and stops | Application or LLM integration |
| AgentServer runtime | A GenServer that hosts one live Agent, routes Signals, invokes plugins, queues Directives, and manages lifecycle data | Jido |
| Application policy | The authentication, principal context, authorization rules, and effect conditions supplied by the application | Application |
| Directive | A typed description of runtime-owned work that AgentServer executes through DirectiveExec |
Jido contract or application-defined Directive type |
| BEAM/OTP process | An isolated Erlang process with a mailbox, links, monitors, and supervision behavior | BEAM and Erlang/OTP |
These terms are not synonyms. An Agent is not its controller. A controller is not a Jido Strategy, although a Strategy can implement part or all of a controller. A harness is not AgentServer. A Directive is not a BEAM process. AgentServer runs in a process, but the process is the host mechanism, not the domain Agent.
Cloudflare defines a harness as the loop around a model call that builds prompts, handles memory and tools, streams results, and decides whether to continue [13]. This industry definition is useful because it separates harness behavior from runtime infrastructure. Jido is an agent SDK and runtime architecture, not an LLM harness SDK. An LLM harness can use Jido contracts, but Jido core does not define the prompt loop.
The studied mix.exs contains no LLM provider or inference dependency. This absence removes a core dependency on one controller class. It does not show that an application has correct authorization, safe prompts, limited credentials, or reliable effects.
This paper uses governance invariance as a local study measure. It is not an established assurance term or a universal Jido guarantee.
For an operation represented by the same domain Signal and routed Action, changing the Strategy binding has governance invariance when all of the following statements are true:
- The shared Signal, Action, policy plugin, domain Directive types, and non-controller AgentServer options do not change.
- For the same routed Action and runtime context,
prepare_action/3gives the same allow, deny, or error result. - The comparison starts when the same proposal has the same Signal and Action representation. Controllers do not need to create the same proposal.
A controller-created follow-up operation is in this property only if the integration sends the proposal back through AgentServer Signal routing. Direct execution in a Strategy, direct Jido.Exec use, direct Agent.cmd/2, and a new RunInstruction do not get another prepare_action/3 check.
The study distinguishes cause, event, and impact. A malicious input, controller fault, process crash, or service failure is a cause. An unauthorized write, duplicate write, missing write, or outcome-unknown write is an operational event. The event can create an impact. The study observes policy calls, process state, telemetry, and message delivery in a local test. It does not convert these observations into a loss distribution or a calibrated risk value.
The trusted computing base for the paper-only check includes the pinned Jido source, locked dependencies, study code, BEAM host, local configuration, and test assertions. Untrusted or fallible inputs include study Signals, recorded proposals, and process operation. Host compromise, malicious native code, Byzantine nodes, side channels, and physical actuators are out of scope.
The architecture has three different responsibility sets:
| Layer | Mechanisms in scope | Mechanisms not supplied by this layer |
|---|---|---|
| Jido | Agent and Strategy contracts, plugin hooks, Directives, Signal routing, AgentServer lifecycle and runtime composition | Default application authorization policy, authenticated principal identity, exactly-once effects |
| BEAM/OTP | Processes, mailboxes, links, monitoring, supervision, process restart | Application state restoration, external effect reconciliation, business compensation |
| Application | Authentication, principal context, policy content, effect-level authorization, idempotency, durable audit, compensation, external reconciliation | BEAM scheduling and OTP supervision semantics |
This map prevents attribution errors. Jido uses OTP supervision, but Jido does not create the general process model. OTP can restart a process, but it cannot know whether an external service accepted a prior write. A Jido plugin hook can host policy, but Jido does not authenticate a human principal by default.
The actor model supplies independently addressable computational entities that communicate with messages and can change behavior [4]. Jido does not claim a new actor model. Its live AgentServer uses a BEAM process, but Jido adds domain contracts and runtime composition above the process model.
The Simplex architecture separates an advanced controller from a baseline controller and a decision module that protects a safety region [7]. Simplex supplies a stronger controller-assurance form than Jido supplies here because its decision module and safety model define when control must move to the verified baseline. Jido has no verified fallback controller or plant-safety proof. The relation is structural: both put a control concern outside the advanced controller.
AgentSpec defines a rule language with triggers, predicates, and enforcement mechanisms for LLM agents and reports evaluations across code, embodied, and driving domains [15]. AgentSpec has a stronger policy language and broader reported evaluation than this Jido study. Jido supplies general plugin hooks and runtime boundaries; it does not supply AgentSpec's rule language or its reported safety results.
CaMeL separates trusted control flow from untrusted data and applies capability checks at tool calls [14]. It gives a much stronger prompt-injection and information-flow claim under its design assumptions. Jido does not separate trusted and untrusted data by default, does not provide capability security, and does not prevent prompt injection. A CaMeL-like harness could return a proposed Action to the Jido route, but that composition is not tested here.
FORGE defines policies in Datalog, maintains execution predicates through an observability service, and consults a reference monitor at policy-relevant decisions [16]. Its assume/guarantee contract and causal policy semantics are stronger than a bare Jido callback. Jido's prepare_action/3 is a placement point. It is not a complete reference monitor because paths can bypass it.
Saltzer and Schroeder describe complete mediation, fail-safe defaults, least privilege, and economy of mechanism as protection principles [6]. The Jido path supports a fail-closed application hook for matching configured plugins, but the whole architecture does not meet complete mediation. The paper therefore uses managed path, not reference monitor, for the result.
Proof of Execution (PoE) separates planning, enforcement, effect, and recording. It defines validator-checkable invariants and ties its guarantees to cryptographic and exclusive-effector assumptions [17]. PoE is stronger than Jido Directive telemetry. Jido emits start, stop, and exception events around a local execution attempt. It does not create a tamper-evident causal history, an attestation certificate, or a replay guarantee.
Sagas define compensation for long-lived transactions [8]. Jido Directives do not automatically supply compensation. The application must define compensation and determine when it is safe.
Reliable State Machines (RSMs) use persistent state, inbox, and outbox semantics to provide failure transparency and exactly-once input processing in their model [9]. Durable Functions use record and replay to persist progress while preserving a high-level execution model [10]. Both systems provide stronger persistent-execution semantics than the local Jido restart and checkpoint checks in this paper.
Erlang/OTP supplies lightweight processes, asynchronous signals, mailboxes, links, monitors, and supervisors [5, 11, 12]. A supervisor starts, stops, monitors, and restarts child processes [12]. These mechanisms contain local process failure. They do not by themselves restore application state or determine an external effect outcome.
Prior work covers controller assurance, runtime policy, prompt-injection defenses, effect integrity, actor reliability, and durable execution. This paper does not replace those results. It asks a smaller software-architecture question: can one application policy placement and the same domain operation representation remain stable when the Jido Strategy changes, and where does that property stop?
The studied Agent schema holds current state and a compile-time Strategy binding. The source defines the command result as a new Agent plus Directives and labels Directives as runtime-owned external effects (Agent types and configuration). The generated cmd/3 function normalizes Actions into Instructions and then calls the selected Strategy.cmd/3 (Agent command path).
The Strategy behavior receives normalized Instructions and returns an updated Agent plus Directives (Strategy contract). The built-in Direct Strategy calls Jido.Exec.run/1 immediately for each Instruction (Direct execution). Therefore an Action can perform I/O while the Strategy runs. The paper does not describe Actions as pure.
The finite-state-machine (FSM) Strategy takes a different path. It validates its transition, emits a RunInstruction Directive, and waits for the runtime to feed the result back (FSM execution model). This difference makes Direct and FSM useful unlike Strategies for the study.
AgentServer is a GenServer runtime. Its module contract states that one GenServer hosts each live Agent under the Agent supervisor (AgentServer architecture). AgentServer owns Signal routing and the Directive queue. Jido's logical parent-child relations remain separate from OTP supervisory ancestry.
Figure 1. The solid path is the measured managed path. Dashed paths show work that does not automatically return to prepare_action/3.
The exact call order is the main source result. AgentServer first runs Signal hooks and prepare_signal/2. It then routes the prepared Signal to an Action. After routing, it builds the Action argument and runs configured prepare_action/3 hooks. Only an allowed result reaches the Agent command call (AgentServer call path). The Agent then normalizes the Action and invokes Strategy.cmd/3.
This sequence means prepare_action/3 runs after routing and before the Strategy. The plugin contract says the hook can add runtime context or fail closed, but it cannot rewrite the resolved Signal or Action (plugin contract). AgentServer invokes the hook only for plugins whose configured Signal pattern matches the Signal (matching rule). A missing plugin or a non-matching plugin therefore supplies no policy decision.
The hook is not a policy by itself. Application code must authenticate the caller, create principal context, define scopes, and decide whether the Action and its parameters are allowed. Jido supplies the placement and error contract.
Four limits define the result:
- A direct
Agent.cmd/2orAgent.cmd/3call does not enter AgentServer and does not invoke AgentServer plugins. - Direct I/O inside an already authorized Action is not a second Action-authorization bypass, but it is outside effect-level AgentServer mediation. AgentServer cannot apply a Directive executor to I/O that already happened inside the Action.
RunInstructioncallsJido.Exec.run/1and then feeds a result Action back to the Agent command path. It does not callprepare_action/3for the Instruction it executes (RunInstruction executor).- A Strategy can create new work after the routed Action was authorized. The earlier policy decision does not automatically authorize that new work. The integration must return a consequential proposal through a new domain Signal and route it to an Action if it needs the same check.
These limits prevent a complete-mediation claim. They also explain why controller substitution can preserve policy on one path without governing all controller behavior.
AgentServer wraps DirectiveExec.exec/3 with :start, :stop, and :exception telemetry (Directive telemetry). This creates a separate runtime execution point.
The evidence has a strict limit. The Emit executor prepares the Signal, starts asynchronous dispatch work, and returns {:async, nil, state} (Emit executor). A Directive :stop event can therefore mean that local dispatch was started. It does not mean that the destination acknowledged the Signal or that an external system committed an effect. Debug history is an in-memory diagnostic buffer, not a durable audit log.
An AgentServer child specification uses restart: :permanent (child specification). Jido's agent DynamicSupervisor uses :one_for_one (supervisor configuration). Under this configuration, one child restart does not require sibling restart. The new child starts from its child specification. The supervisor does not automatically call the public checkpoint thaw API.
Jido exposes explicit hibernate and thaw operations through the Jido.Persist application programming interface (API) (persistence API). Persistence is optional. A checkpoint records state at one point. Later unrecorded state is not part of that checkpoint.
Jido core identity data records lifecycle and profile facts such as age, origin, generation, and timestamps (identity data). It is not authenticated principal identity. Authentication and binding to a human or service principal remain application responsibilities.
The unit of analysis is the managed boundary between an Agent, controller, harness, and AgentServer runtime. The source artifact is Jido commit 17fbce2b1c53a46093be92dc59561e2a18b8f775. The commit's Mix project declares version 2.3.2. All Jido implementation URLs in this paper are pinned to that commit. The checks ran with Elixir 1.20.2 and Erlang/OTP 29 on the local host. The mix.lock SHA-256 value was 6d14349c24874542f706a87aba082ba504a2584ea0d9e84072547d62ef47da42.
The paper uses three evidence types:
- Direct source inspection with line-pinned links.
- Existing repository tests for plugin errors,
RunInstruction, restart behavior, and hibernate/thaw. - A small deterministic paper-only ExUnit file,
study_checks_test.exs, outside Jido core.
No live model was used. The recorded-proposal Strategy is deterministic. No production service, payment system, or physical actuator was connected.
The paper-only check defines one policy plugin, shared Signals and Actions, and three Agent variants:
| Variant | Jido Strategy | How the Action runs |
|---|---|---|
| DirectAgent | Jido.Agent.Strategy.Direct |
The Strategy calls Jido.Exec directly |
| FSMAgent | Jido.Agent.Strategy.FSM |
The Strategy emits RunInstruction; AgentServer executes it |
| ReplayAgent | A deterministic recorded-proposal Strategy | The Strategy emits RunInstruction or returns a follow-up Signal |
The variants reuse the policy plugin and the study.write Signal-to-Action mapping. The allow case must show a policy message before the Action's observable message. The deny case must show the same policy message and no Action message.
The escape-path check compares two proposals. The internal proposal creates RunInstruction inside the replay Strategy. The routed proposal emits a new study.write Signal. The test records which Action the policy sees.
The effect-evidence check compares direct Action I/O with an Emit Directive. It attaches telemetry handlers to the Directive start, stop, and exception events. The restart check starts a target and sibling AgentServer under the same DynamicSupervisor, increments both, kills the target, and checks PIDs and counters. The persistence check hibernates state S1, creates later live state S2, stops the process, and explicitly thaws the stored checkpoint.
The command was:
mix test research/governing-risk-with-agents/study_checks_test.exs --seed 0
It completed with Result: 5 passed on 31 July 2026.
The study also ran selected existing tests with this command:
mix test test/jido/agent_server/plugin_prepare_hooks_test.exs \
test/jido/agent_server/agent_server_test.exs:180 \
test/jido/agent_server/directive_exec_test.exs:509 \
test/jido/persist_test.exs:486 --seed 0
It completed with Result: 22 passed, 137 excluded. The plugin tests cover rejection, invalid returns, context conflicts, and exceptions (plugin tests). The other selected tests cover RunInstruction result routing, permanent restart behavior, and persistence round trips (Directive test, restart test, persistence tests).
The refined study plan proposed a production-change-control workload, a mock versioned service, injected lost acknowledgements, raw trial data, latency measurements, and a separate public companion repository. Those artifacts do not exist in this draft. This paper does not report their planned measurements. It weakens the claims to the source and local checks that exist today.
The paper-only check does not establish effect durability, compensation, external reconciliation, distributed behavior, or performance. The test uses process messages as local observations. It does not use a transactional external service.
The shared policy produced the same allow and deny outcomes for DirectAgent, FSMAgent, and ReplayAgent. In each allow case, the policy observation preceded the Action observation. In each deny case, AgentServer returned a plugin error and the Action observation did not occur.
Table 2. Governance-invariance check.
| Property | Direct | FSM | Recorded proposal | Result |
|---|---|---|---|---|
Shared study.write Signal and routed Action |
Yes | Yes | Yes | Unchanged |
| Shared policy plugin | Yes | Yes | Yes | Unchanged |
| Allow result before Action observation | Yes | Yes | Yes | Agreement |
| Deny result blocks current routed Action | Yes | Yes | Yes | Agreement |
| Strategy-specific execution mechanism | Immediate Jido.Exec |
RunInstruction |
RunInstruction or emitted proposal |
Changed as expected |
The result supports governance invariance as defined in Section 2.2 for the tested path. It does not show that the full Agent module is unchanged. Strategy binding is compile-time, so the test uses three Agent modules. It also does not show that the controllers create the same proposals.
The direct Agent.cmd/2 call executed the Action without a policy observation. The internal recorded proposal caused RunInstruction to execute a new Action. The policy saw the original ProposalAction, but it did not see the internally created DirectWriteAction. When the replay Strategy returned the same follow-up operation as a new Signal, AgentServer routed it and the policy saw DirectWriteAction before execution.
Table 3. Managed paths and evidence.
| Operation path | prepare_action/3 before operation? |
Directive telemetry? | Main limit |
|---|---|---|---|
| Matching plugin, AgentServer Signal to routed Action | Yes | Only for returned Directives | Jido supplies a hook, not policy content |
| No plugin or non-matching plugin | No | Depends on Directives | No application decision at this hook |
Direct Agent.cmd/2 |
No | No AgentServer Directive telemetry | Outside AgentServer |
Strategy-created RunInstruction |
No new check for the Instruction | Yes, for RunInstruction |
Earlier Action authorization does not cover new work automatically |
| Controller follow-up returned as a Signal | Yes, after the new route | Depends on returned Directives | Integration must preserve the domain representation |
| Direct I/O inside an authorized Action | One check for the Action | No effect-level Directive event | Outcome needs application evidence |
| Emit Directive | One check for the Action; prepare_emit/2 for dispatch |
Start and stop around local execution | Stop does not prove destination acknowledgement |
The managed boundary is therefore smaller than "all work done by an Agent." The result is exactly the AgentServer route from a matching Signal to a resolved Action.
The direct Action sent its local effect observation and produced no Directive telemetry. The Emit path produced Directive start and stop telemetry and delivered an asynchronous Signal to the test process. This confirms separate execution evidence. It does not show durable delivery.
The supervised restart check killed one AgentServer. The registry later resolved a new PID for the target. The sibling PID remained alive, and its counter advanced from one to two. The restarted target counter was zero. This result separates process restart from state restoration. The child restarted, but its earlier live state did not return.
The persistence check stored S1 with counter value one. The live Agent later reached S2 with counter value two. After the process stopped, explicit thaw returned counter value one. This result separates explicit state restoration from both supervision and later unrecorded state.
No check determined an external effect outcome after a lost acknowledgement. The correct result for that planned case remains unknown until a mock service with durable ground truth exists.
Table 4. Claim status in this working draft.
| Claim | Status | Evidence and limit |
|---|---|---|
| Policy can remain outside three unlike Strategies for the same routed Action | Supported for the paper-only check | One synthetic Signal and Action; three local variants |
| Policy rejection, invalid return, context conflict, or exception blocks the current matching routed Action | Supported in selected upstream tests | Does not cover missing or non-matching plugins |
| Strategy-created follow-up work is governed only when it returns through AgentServer routing | Supported for one internal and one returned proposal | Does not enumerate every custom Strategy |
| Directive start/stop/exception telemetry is a separate runtime evidence point | Supported by source and local Emit check | Not durable audit or external outcome proof |
| One supervised AgentServer can restart while a sibling continues | Supported in one local :one_for_one check |
Single node; one fault; target state restarted fresh |
| Explicit thaw restores recorded S1, not later S2 | Supported in one local ETS check | ETS is not restart-safe across BEAM shutdown |
| Jido reduces calibrated operational risk | Unsupported | No loss model, baseline, or field study |
| Jido gives durable or exactly-once effects | Unsupported and not claimed | No such mechanism was shown |
| Policy-hook cost is small | Unresolved | No latency experiment was completed |
The result comes from control placement. AgentServer resolves the Action before prepare_action/3, and it calls the Agent only after the hook allows the Action. The Agent then calls the configured Strategy. Policy can therefore remain outside unlike Strategies for the same routed Action.
The placement also defines the failure of the property. A Strategy can create a new Instruction, call another system, or execute I/O. The old decision cannot authorize an operation that did not yet exist at the policy point. A governed integration must return consequential proposals through the managed route or add another control point at the effect boundary.
This is lower coupling between application policy and the Strategy on one path. It is not proof that policy is correct. A stable weak policy remains weak. A stable policy with false principal context remains wrong. A matching error can silently remove the hook from a Signal class if the application has no independent configuration check.
Jido defines an operational Agent and runtime without requiring an LLM. The controller can be Direct logic, an FSM, a planner, or an LLM-backed integration. The harness still owns model calls, prompts, memory selection, tool presentation, approval user experience, and stopping rules.
This separation has two benefits for analysis. First, the policy point can use a domain Action rather than model text. Second, a controller change does not require a new runtime concept. These benefits depend on integration discipline. If a harness gives a model direct credentials or lets a Strategy call tools without returning proposals, the managed path does not help that work.
The lack of an LLM dependency in core is thus evidence of controller independence. It is not evidence of prompt safety, identity security, or effect safety.
Three records answer different questions:
| Evidence | Question it can answer | Question it cannot answer alone |
|---|---|---|
| Policy decision | Was this routed Action allowed under the supplied context? | Did the effect execute or succeed? |
| Directive telemetry | Did AgentServer start, stop, or raise during local Directive execution? | Did the external system commit or acknowledge? |
| External system record | What request identity and state change did the service record? | Was the request authorized unless policy evidence is joined |
A serious application needs a request identity that joins these records. It also needs idempotency for safe retry, durable audit, and reconciliation when the caller loses an acknowledgement. Jido core does not supply these application facts automatically.
A process restart gives a new execution host. State restoration gives the new host a recorded prior state. External reconciliation determines what another system did. These are separate operations.
The local result shows this sequence clearly. OTP restarted the process. The target state was fresh. Explicit thaw later restored only the recorded checkpoint in a separate check. Neither operation proved any external effect outcome. Applications that combine these concepts can retry a write that already succeeded or omit a write that never occurred.
RSMs and Durable Functions address more of the persistence problem than Jido does in this study [9, 10]. PoE addresses stronger execution-history integrity under explicit assumptions [17]. Sagas address compensation [8]. Jido applications can integrate comparable mechanisms, but this paper does not treat composition as an existing Jido guarantee.
The architecture supports clear boundaries, fail-closed hook errors on the matching path, and process containment. These features align with boundary definition, fail-safe defaults, least privilege, and resilience principles [6]. The architecture also leaves important duties to the application: authenticated identity, effect-level authorization, durable evidence, and recovery design.
The prepare_action/3 failure behavior is a positive case for the classic fail-safe-default principle. The managed-path limit is also a warning about complete mediation. The paper does not redefine complete mediation to fit the implementation.
Construct validity. Governance invariance is a study measure created for this paper. It measures code and policy stability at one boundary. It does not measure governance quality or business risk.
Internal validity. The check is small and deterministic. Its observed order depends on the studied commit and test design. The source placement explains the result, so the behavioral check is partly confirmatory. The test can miss custom plugin, router, or Strategy behavior.
External validity. One synthetic operation cannot represent all high-risk applications. The study has no production deployment, live LLM, distributed node, human approval process, or durable external service. It cannot support a general framework ranking.
Effect validity. Process messages stand in for effects. They show local order and delivery to a live test process. They do not represent transactional commit, acknowledgement loss, duplicate suppression, or compensation.
Persistence validity. The check uses the Erlang Term Storage (ETS) adapter. Its own documentation states that it is not restart-safe across BEAM shutdown. The result concerns checkpoint selection, not durable storage quality.
Authorship bias. The author designs and maintains Jido. This can affect mechanism selection and interpretation. The pinned source, negative cases, exact limits, and executable checks reduce but do not remove this bias. Independent replication is not complete.
Version validity. The paper studies one commit whose project declares version 2.3.2. Later Jido code can change routing, plugin, Directive, or lifecycle behavior. The paper must not be read as a claim about all versions.
The draft makes no claim of risk elimination, calibrated risk reduction, prompt-injection prevention, complete mediation, authenticated Jido identity, security sandboxing, durable Directive delivery, exactly-once effects, automatic checkpoint restoration on supervision restart, or general framework superiority.
Application policy can remain outside unlike Jido execution Strategies for an operation represented by the same domain Signal and routed Action. AgentServer routes the Signal, then calls prepare_action/3, and only then reaches the Agent and Strategy.cmd/3. This order supports a stable application policy point under Strategy substitution.
The result ends at the managed route. Work created inside a Strategy is not automatically authorized by prepare_action/3. Controller-created follow-up work is governed only when the integration returns it through AgentServer routing or adds another applicable control point.
Directive telemetry, OTP restart, and checkpoint thaw solve different parts of the operating problem. Directive telemetry records a local execution attempt. OTP can restart a process without restoring its prior state. Explicit thaw restores recorded state, not later state and not external effect truth. Authentication, principal context, effect-level authorization, idempotency, durable audit, compensation, and external reconciliation remain application duties.
The local artifact directory contains paper.md, assessment.md, references.bib, source-manifest.csv, paper-metadata.json, study_checks_test.exs, the PDF builder, the architecture figure, rendered page images, and the final PDF. The source manifest maps implementation claims to commit-pinned source and tests. The check runs from the studied Jido worktree after locked dependencies are fetched with mix deps.get --check-locked. The study test file has SHA-256 value 32beaf5c353ecf27a2d7625d2f57c8f09aeb26414b857b3ea07125efc15b9a0a.
This working draft does not have the planned independent companion repository or an archived release. The paper-only artifact has no declared reuse license. It is not a substitute for the planned repository. A later submission should archive the artifact, state a license, publish raw results, add continuous integration, and repeat the checks on the project release-quality baseline.
Mike Hostetler is a Jido designer and maintainer. This is a direct author-product conflict. The study is not an independent evaluation. No external replication or independent audit is reported in this draft.
OpenAI Codex provided substantial assistance with source inspection, reference collection, test and build code, draft text, and the structured whitepaper assessment. The author directed the work and remains responsible for every claim, citation, disclosure, and released artifact. Generative-AI output is not treated as an independent source. The paper requires human author review before submission.
- Elham Tabassi. Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1, National Institute of Standards and Technology, 26 January 2023. https://doi.org/10.6028/NIST.AI.100-1.
- Basel Committee on Banking Supervision. Revisions to the Principles for the Sound Management of Operational Risk. BCBS 515, 31 March 2021. https://www.bis.org/bcbs/publ/d515.htm.
- Basel Committee on Banking Supervision. Principles for Operational Resilience. BCBS 516, 31 March 2021. https://www.bis.org/bcbs/publ/d516.htm.
- Carl Hewitt, Peter Bishop, and Richard Steiger. "A Universal Modular ACTOR Formalism for Artificial Intelligence." In Proceedings of the 3rd International Joint Conference on Artificial Intelligence, 235-245, 1973. https://www.ijcai.org/Proceedings/73/Papers/027B.pdf.
- Joe Armstrong. Making Reliable Distributed Systems in the Presence of Software Errors. Doctoral dissertation, Royal Institute of Technology, December 2003; corrected version 20 November 2003. https://erlang.org/download/armstrong_thesis_2003.pdf.
- Jerome H. Saltzer and Michael D. Schroeder. "The Protection of Information in Computer Systems." Proceedings of the IEEE 63, no. 9 (1975): 1278-1308. https://doi.org/10.1109/PROC.1975.9939.
- D. Seto, B. Krogh, L. Sha, and A. Chutinan. "The Simplex Architecture for Safe Online Control System Upgrades." In Proceedings of the 1998 American Control Conference, vol. 6, 3504-3508, 1998. https://doi.org/10.1109/ACC.1998.703255.
- Hector Garcia-Molina and Kenneth Salem. "Sagas." In Proceedings of the 1987 ACM SIGMOD International Conference on Management of Data, 249-259, 1987. https://doi.org/10.1145/38713.38742.
- Suvam Mukherjee, Nitin John Raj, Krishnan Govindraj, Pantazis Deligiannis, Chandramouleswaran Ravichandran, Akash Lal, Aseem Rastogi, and Raja Krishnaswamy. "Reliable State Machines: A Framework for Programming Reliable Cloud Services." arXiv:1902.09502v3, 27 February 2019. https://arxiv.org/abs/1902.09502.
- Sebastian Burckhardt, Chris Gillum, David Justo, Konstantinos Kallas, Connor McMahon, and Christopher S. Meiklejohn. "Durable Functions: Semantics for Stateful Serverless." Proceedings of the ACM on Programming Languages 5, OOPSLA (15 October 2021): 1-27. https://doi.org/10.1145/3485510.
- Ericsson AB. "Processes." Erlang/OTP System Documentation, version 27.3.4.14. https://www.erlang.org/docs/27/system/ref_man_processes.html.
- Ericsson AB. "Supervisor Behaviour." Erlang/OTP System Documentation, version 27. https://www.erlang.org/docs/27/system/sup_princ.html.
- Cloudflare. "Harnesses." Cloudflare Agents Documentation, last updated 3 June 2026. https://developers.cloudflare.com/agents/harnesses/.
- Edoardo Debenedetti, Ilia Shumailov, Tianqi Fan, Jamie Hayes, Nicholas Carlini, Daniel Fabian, Christoph Kern, Chongyang Shi, Andreas Terzis, and Florian Tramèr. "Defeating Prompt Injections by Design." arXiv:2503.18813v2, 24 June 2025. https://arxiv.org/abs/2503.18813.
- Haoyu Wang, Christopher M. Poskitt, and Jun Sun. "AgentSpec: Customizable Runtime Enforcement for Safe and Reliable LLM Agents." arXiv:2503.18666v3, 31 July 2025; accepted at the 48th IEEE/ACM International Conference on Software Engineering, 2026. https://arxiv.org/abs/2503.18666.
- Nils Palumbo, Sarthak Choudhary, Jihye Choi, Guy Amir, Prasad Chalasani, and Somesh Jha. "Formal Policy Enforcement for Real-World Agentic Systems." arXiv:2602.16708v3, 8 May 2026. https://arxiv.org/abs/2602.16708.
- James Rhodes and George Kang. "Proof of Execution: Runtime Verification for Governed AI Agent Actions." arXiv:2607.05397v1, 26 April 2026. https://arxiv.org/abs/2607.05397.
- AgentJido. Jido source repository, commit
17fbce2b1c53a46093be92dc59561e2a18b8f775; Mix project declares version 2.3.2. https://github.com/agentjido/jido/tree/17fbce2b1c53a46093be92dc59561e2a18b8f775.