Tasks and specifications

What a task is

A task executes one R&D goal against a frozen input set. It binds a specification and a sandbox, then enters a running state machine asynchronously.

A task is not a conversation. A conversation is a long-lived container for interaction that can span any number of turns; a task is an execution with a definite start and end, frozen inputs and deliverables. One conversation can start several tasks.

What the specification freezes

The specification is resolved before the task is created and is immutable while it runs. It freezes:

• the creator and the workspace;
• the repository reference and baseline branch;
• the initial flow snapshot;
• the exact capability version of every node — flow node, model, runtime, skill and extension;
• the member credential revision;
• the input references and their content digests.

The specification contains no secrets at all. Credentials are injected into the runtime environment by the control plane at run time and deleted as soon as each component is ready; they never reach an image, a repository, the specification, a log or an event.

Why it is immutable

The specification is immutable so that an execution can be replayed and explained.

If the model version, skill version or knowledge version were free to drift mid-run, "why did this task produce that result" would stop being an answerable question. The same goes for failure: you would be unable to tell whether the cause was your code or a changed dependency.

Retry, rework, restart and resume therefore all reuse the same specification. While a task is running, no floating reference is permitted to refresh a flow, a node or a capability.

Concretely: if a published version is later deprecated, tasks already referencing it are unaffected; moving a tag to a new version changes neither published flows nor in-flight tasks. Emergency security revocation is a separate governance action, and it requires explicitly terminating the affected sandboxes.

Preflight: where the specification comes from

When a task is created, the record is persisted and an identifier returned first, after which it enters the user-visible preflight stage. Preflight is the only place a specification is produced, and the point at which every authorisation check converges.

Preflight re-authorises the planning result against the current user and the current workspace. It does not trust the conclusions reached during planning: it re-checks the visibility and permissions of every reference under the same identity, then runs deterministic validation — the dependency graph is acyclic, every required input has exactly one legitimate source, artefact type contracts are compatible, and budgets and limits are frozen explicitly.

Only a successful preflight creates a sandbox. This is a fail-closed boundary: a failed preflight creates no half-built environment, and does not silently fall back to broader permissions.

Three sources for a flow

Preflight needs a flow. There are three ways to get one.

Smart orchestration is the default. The platform analyses the task goal, the existing requirements, the constraints, the deliverables and the acceptance criteria; retrieves published flows visible to the current user; and for each candidate reads the full contract of the exact version, comparing inputs, outputs, nodes, dependencies and capabilities. A similar name is not a fit. When a flow satisfies the task, its exact version is reused; a task-scoped temporary flow is generated only when nothing fits.

Using an existing flow is an explicit choice of a published version by the user. This path skips model planning, but it still has to pass preflight and freezing.

Creating a flow opens a separate authoring page and produces a publishable long-lived asset.

Whichever path you take, the result goes through the same deterministic compiler and the same digest validation.

Replanning while running

A frozen revision cannot be modified in place. If the plan turns out not to hold during execution, the agent can propose a new flow revision, which goes back through compilation, permission and risk assessment. The initial specification is left untouched; subsequent revisions are written to an append-only plan log that preserves the old topology, the reason for the change, the initiator and the approval record in full.

A completed node may only be reused when its invocation contract, inputs, upstream artefacts, node template and capability digests are all compatible; otherwise it is explicitly invalidated and rerun. Replanning cannot delete historical evidence, and cannot present a not-yet-executed node as though it had been part of the initial plan.

Rebuilding a task

Rebuilding from the original task reads its business inputs and creates a new task as the current operator. It re-freezes the model and credentials, the capability lock and the runtime, and it re-issues the current knowledge access policy. The old task is preserved intact.

The point of this behaviour is that a rebuild is not a recovery — it is the same intent executed again under new conditions.