> For the complete documentation index, see [llms.txt](https://docs.ees.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ees.xyz/concepts/execution-modules.md).

# Execution modules

Execution modules are smart contracts containing the *logic* of the execution i.e. when conditions are met for the job to be executed. When a job is created through the `JobRegistry` contract, it commits to a single execution module. Execution modules are very abstract giving most flexibility for future execution logic. However, every execution module must implement the `IExecutionModule` interface:

```solidity
interface IExecutionModule {
    function onExecuteJob(uint256 _index, uint32 _executionWindow) external returns (uint256);
    function onCreateJob(uint256 _index, bytes calldata _inputs, uint32 _executionWindow) external;
    function onDeleteJob(uint256 _index) external;
    function jobIsExpired(uint256 _index, uint32 _executionWindow) external view returns (bool);
    function jobIsInExecutionMode(uint256 _index, uint32 _executionWindow) external view returns (bool);
    function getEncodedData(uint256 _index) external view returns (bytes memory);
}
```

The `onExecuteJob` callback function is called by the `JobRegistry` upon execution. It returns the UNIX time in seconds when the job can be executed from.   The `onCreateJob` callback function is called upon creation of a job and is passed arbitrary input data in form of the argument `_input`. It can be used to initialise auxiliary data structures within the module. Similarly, the `onDeleteJob` callback function is called by the `JobRegistry` contract upon deletion of a job. The `jobIsExpired` function returns a bool whether a job is expired and can be canceled. `jobIsInExecutionMode` returns whether the job is in execution mode. Lastly, the `getEncodedData` function returns all data stored in the execution module contract for a job index as an encoded bytes array.

{% hint style="warning" %}
**Warning:** `onExecuteJob` might revert which will in turn revert the original call to `execute` in `JobRegistry`. The execution module solely decides if the right conditions are met for the job to be executed.
{% endhint %}

In contrast to applications, execution modules are created and tested by the EES before being supported by the `JobRegistry` contract. The reason for gatekeeping the addition of execution modules is to avoid fragmentation as every executor has to implement logic to support new execution modules. However, the modular structure allows for progressively adding new and flexible logic to the protocol.

{% hint style="info" %}
**Note:** Existing execution modules are completely *immutable*. The data stored in these can only be created or deleted with job creation or deletion but cannot be modified. A job cannot change execution module during its lifetime.
{% endhint %}

Applications can choose to implement logic to restrict creation of jobs with specific execution modules. An example could be a subscription payment application which chooses to only support recurring jobs. It is recommended that the set of supported modules is extensible, thus having the ability to support new modules in the future. 


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.ees.xyz/concepts/execution-modules.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.