Overview
Vega Runtime provides the public execution behavior for supported work. It tracks work as tasks, groups activity into sessions, supplies approved context, maintains continuity, coordinates eligible Capabilities, and assesses recovery after interruption. This page describes what operators can observe and rely on; it does not describe proprietary execution mechanisms.
Concepts
| Term | Meaning |
|---|---|
| Task | A tracked unit of requested work. |
| Session | An operational period in which Vega Runtime is active. |
| Task context | Information relevant to one task. |
| Session context | Information relevant to the current operating period. |
| Runtime state | The reported current state of the Runtime, sessions, tasks, and available Capabilities. |
| Persistent memory | Approved retained context available according to deployment policy. |
| Recovery | Assessment of work affected by interruption or restart. |
Tasks and task lifecycle
Vega Runtime accepts a task only when it is ready and an eligible Capability can support the request. A task reaches a completed, failed, or cancelled terminal outcome. A capability gap is reported when the requested work cannot be matched to an eligible Capability.
For example, an approved request to produce a spoken greeting becomes a task only if the deployment is ready and an eligible speech Capability is available. The Runtime reports the task's outcome rather than implying success from request acceptance alone.
Sessions and session lifecycle
A session is the public operating boundary for related Runtime activity. Vega Runtime establishes an active session after successful startup. Tasks handled during that operating period are associated with the session. An orderly stop or interruption ends the active period; a later start begins a new active session and may assess prior interrupted work.
Context
Vega Runtime makes context available within approved task, session, and deployment boundaries. Task context relates to the current request; session context relates to the active operating period; Runtime context relates to the current deployment. Context availability depends on the relevant boundary and permissions. It is not a general-purpose channel for sharing arbitrary data.
Provide task-critical information explicitly. Do not assume a prior task, conversation, or session makes information universally available to later work.
Runtime state, persistent memory, and continuity
Runtime state communicates the active lifecycle condition, session activity, task activity, Capability availability, and visible warnings. Persistent memory is deployment-approved retained context that supports continuity. Together they allow Vega Runtime to report operational status and assess eligible interrupted work.
Persistence does not prove that a real-world effect occurred. It preserves operational continuity, not a substitute for observing a robot, external device, or physical environment.
Capability orchestration
Vega Runtime conceptually evaluates a request against the Capabilities available to the deployment, coordinates eligible work, and reports the observed outcome. The Runtime does not implement the Capability itself and does not bypass the Capability's declared requirements, limitations, or safety boundaries.
Recovery, restart, and task continuation
After a restart or interruption, Vega Runtime assesses eligible prior work and reports whether it is resolved, can continue under current policy, or needs attention. It uses available Runtime state and Capability-reported facts to avoid unsupported assumptions. A task can continue only where the current deployment can establish a supported next position.
For example, if an external device may have been active when a Runtime session ended, do not repeat the request automatically. Review the recovery status and verify the real-world condition when the outcome is uncertain.
Execution guarantees
Vega Runtime guarantees that it reports work within task and session boundaries, does not report an unavailable Capability as a completed result, distinguishes known outcomes from unresolved recovery conditions, and stops accepting new work once shutdown begins. These are behavioral guarantees; they do not replace physical safety controls or Capability-specific requirements.