Core Concepts
Understand the MirrorNeuron workflow, blueprint, job, and runtime-node model.
Core Concepts
Use these terms consistently when you build, operate, or integrate with MirrorNeuron. This page explains the runtime model; use the CLI, API, and bundle references for exact syntax and fields.
The execution model
Blueprint folder → validation → job submission → runtime scheduling → worker execution
↓ ↓ ↓ ↓ ↓
manifest + payloads requirements job ID events/state artifactsThe control plane accepts jobs, records their state, and exposes inspection and control operations. The execution plane runs the workflow's agents on the selected execution environment. Redis stores durable runtime state; a run store records local artifacts for blueprint-oriented runs.
Terms
| Term | Meaning |
|---|---|
| workflow | A declared graph of work that MirrorNeuron schedules and executes. |
| blueprint | A reusable packaged workflow, usually a folder containing a manifest, configuration, payloads, and supporting material. |
| bundle | The validated job package submitted to the runtime. |
| job | One submitted workflow execution. The runtime identifies it with a job ID. |
| run | The blueprint-oriented record of a launch and its local run-store outputs. A run ID identifies those artifacts. |
| agent | An executable participant in a workflow with a declared role and runtime contract. |
| runtime node | A machine or runtime member eligible to run work. A cluster has more than one runtime node. |
| event | A recorded runtime occurrence, such as progress, failure, retry, or completion. |
| artifact | A file or output associated with a run, for example events.jsonl, result.json, or a report. |
| control plane | The scheduling, state, inspection, and control responsibilities of the runtime. |
| execution plane | The workers and execution environments that perform workflow work. |
Execution boundaries
The execution mode selected by a blueprint determines where worker code runs, what resources it can access, and how strongly it is isolated from the rest of the system.
-
Direct host execution (
HostLocal) runs worker code directly on the machine. It provides the lowest overhead and direct access to local hardware, making it useful for trusted workloads such as real-time processing or large-scale simulation. Because the code shares the host environment, use this mode only for payloads you have reviewed and trust. -
Docker is the default execution mode for most workflows. It provides a reproducible, containerized environment with controlled dependencies and file access. Use it for workflows that need a configured runtime but do not autonomously generate, install, and execute new code.
-
NVIDIA OpenShell runs worker code inside a policy-controlled sandbox. It is the preferred boundary for autonomous agents that create or modify code, install dependencies, or execute unfamiliar commands. Review the sandbox policy, uploaded or mounted files, credentials, network access, and exposed services before running the blueprint.
Running in Cluster
Cluster execution allows jobs to run on MirrorNeuron runtime nodes which are connected into a pool of resources (GPU,CPU,Memory). The runtime can automatically place or relocate work across the cluster based on node availability and job requirements. See Cluster.
What to inspect after a launch
Use the job ID to inspect runtime state:
mn job status <job_id>
mn job monitor <job_id>Use the run ID to inspect blueprint artifacts:
mn blueprint logs <run_id>
mn blueprint tail <run_id>Replace <job_id> and <run_id> with the values printed by mn blueprint run.