> For the complete documentation index, see [llms.txt](https://healdocs.lattica.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://healdocs.lattica.ai/core-concepts-explained/runtime.md).

# Runtime

The **HEAL Runtime** is an engine that sequentially processes a model inference pipeline, as defined in a [JSON-based transcript](/core-concepts-explained/transcript.md). This runtime is hardware-agnostic, delegating each operation to a provided device engine and abstracting execution to enable both software fallbacks and hardware acceleration.

The runtime reads an execution transcript (a list of operations) and executes them step-by-step. It handles memory references between host and device, dispatches each instruction to the correct function, and manages verification if required.

This allows for seamless execution of fully homomorphic encryption (FHE) workflows, including

* Moving data between the host and hardware (`host_to_device`, `device_to_host`)
* Executing tensor operations (e.g., `modmul`) on hardware
* Managing memory via named tensor references
* Logging performance and verification success

{% hint style="warning" %}
The runtime described here is used with sandbox transcripts in an isolated environment and is designed as a simplified version of the Lattica backend.\
However, any hardware that is compatible with this runtime is also compatible with the full Lattica backend. This ensures a smooth path from development and testing to full deployment.
{% endhint %}

***

## Call Format

```python
run_transcript(device_t_eng, transcript, verify=False)
```

### `device_t_eng`

The hardware abstraction interface knows how to run each function. \
This is the **bridge between the runtime and your implementation**. 

### `transcript`

JSON-based list of instructions. \
For full details, see the [*Transcript* ](/core-concepts-explained/transcript.md)page.

### `verify`

By default, **`verify=False`**, which means the runtime just runs the functions and assumes the hardware gives correct results.

If it is enabled, the runtime compares the actual result with the expected output (embedded in the transcript). If they don't match, it raises an error.

This is useful for debugging or validating your hardware functions.

***

## Output

At the end of execution:

* The runtime prints timing info
* You get logs for each step
* If verification is enabled, it confirms correctness

***