Developing on HEAT

Developing on HEAT means authoring a session template: a graph of named nodes that turns uploaded data into a dashboard. You rarely write a service. You choose node templates, configure them, connect them and end the graph with a node that publishes a Dimension.

A session template names each step by its node template, a reusable kind of processing step implemented by a Runner. When data arrives, HEAT creates a Session from the template, runs each node as its parents finish and stores every result as an immutable node output. The last node publishes a dimension, which is what an instructor opens in the HEAT dashboard.

A session template is not code that runs on your machine. It is a JSON document that a deployed HEAT environment executes for you.

The toolbox at a glance

Tool	What it gives you
Five platform runners	core-utils, dashboard-tools, system-utils, audio-utils and video-utils. Each is a container image that executes a set of node templates. system-utils is built into the platform and is always present.
Close to 70 platform node templates	Transforms for CSV, JSON and capture protobuf, analytics steps, and the dashboard publishers. The full list is in the node template catalog.
20 dashboard widgets	Charts, maps, tables and playback components for the Next dashboard. Each binds to named channels through a Layout. See Dashboards.
Arbex scripting	Sandboxed JavaScript run by the `system-arbex-js` node template when a declarative node is not enough. See Arbex.
Connectors	The documented paths for getting data in from a new simulator, sensor or tool, from a plain file upload to a custom publisher. See Connecting a simulator or sensor.
HEAT Capture interfaces	The interface control documents and web API of the Capture application, the simulator plugins for MACE, Unreal Engine and VBS4, and the HEAT ProtoLib data model. See Capture for developers.
HEAT v2 API	The REST surface for creating sessions, uploading data and exporting assessment results as reports from outside the cluster. It is the only API available to integrators. See APIs.

Three paths

Choose the least effort that meets the need. Most solutions start on the first path and move down only when they have to.

No code

Use a shipped preset. The platform ships a small set of session templates, for example system-tabular-dashboard-autodetect-next, which takes any CSV upload and opens a dashboard with an automatically chosen layout. You create an Ingest that points at the preset, post a file and read the result. Nothing is authored.

Configuration only

Compose platform node templates into your own session template. You pick the transforms, set their configuration, and hand-write the dashboard layout so the widgets show what you want. Everything you need already exists in the five platform runners. This path covers most tabular and JSON integrations.

Code

Write an Arbex script or build your own runner. Arbex is the shorter step: one node in the graph runs your JavaScript against the parent output and returns JSON, so custom metrics and bespoke layouts stay inside the template. A runner is the longer step: a container image with its own dependencies that registers new node templates through a .heat manifest. See Building your own runner.