# Identifying a Computation

Before computations can be executed, they need to be identified as **Computation Definitions**, which exist within the context of an associated [joint computing environment](https://corex-network.gitbook.io/corex-network/joint-computing-environments). The joint computing environment establishes the state that the computation can interact with. Each **Computation Definition** includes details on the outputs of the computation and contains a version field to ensure that any future executions are based on the correct version of the definition.

Also, the **computation definition** specifies who has the authority to execute the computation and authority can be restricted in several ways: no one may have access (**Null**), a single entity may be authorized (**Private**), specific entities may be allowed (**Reserved**), or anyone may execute the computation (**Public**).

Each **Computation Definition** also includes parameters. These fall into two categories: *Data Objects*, which come from on-chain or off-chain sources and can be mutable or immutable, and *Binary Data*, which has a specified length in bits for raw data that will be used during the computation.\ <br>

## Corex Network computations are divided into two main categories:

* [x] **Ordinary Computations** are requested by computation customers to perform secure computing tasks. Each computation is defined in relation to a specific[ joint computing environment](https://corex-network.gitbook.io/corex-network/joint-computing-environments), which provides the state or data on which the computation acts.
* [x] **Framework Computations** are responsible for managing key operations and are divided into three categories:

1. *Shared key generation computation*: These computations handle the shared key generation when a new [joint computing environment](https://corex-network.gitbook.io/corex-network/joint-computing-environments) is added to a [cluster](https://corex-network.gitbook.io/corex-network/clusters) and the computation customer can set high priority fees upon setup.
2. *Transition system computation*: These computations manage both forced and planned migrations of clusters and each [node](https://corex-network.gitbook.io/corex-network/nodes) in the cluster can contribute a variable amount to the priority fees based on how important fast execution is to them.
3. *Inactivity detection computation*: These computations occur when a cluster experiences non-participation issues that can’t be resolved internally. They require a broader consensus of nodes, and priority fees are carried over from the original computation causing the dispute.&#x20;
