Run, review, and recover

The runner answers a bounded question: given this approved blueprint and recorded state, what work is eligible next? It does not independently decide the legal merits of a task or supply its own model subscription.

The active host receives a task, performs the permitted work using its available tools, and submits a structured result. The runner validates that result before advancing.

A task has an explicit lifecycle

View the relationship model

flowchart TB
    E["Eligible"] --> I["Issued with run, node, and attempt identifiers"]
    I --> V["Result submitted for validation"]
    V -->|Valid| C["Completed and recorded"]
    V -->|Invalid| X["Rejected with an explanation"]
    X -->|Correct the result| V
    C --> N["Determine the next eligible work"]

A stale attempt or duplicate completion must not be treated as new work. Missing capabilities or unresolved decision data produce a blocked state or an explicitly designed human handoff. The host should not invent a substitute route.

Decisions need evidence and authority

Blueprint confirmation establishes which process will run. It does not approve every later result. A workflow can still require a lawyer to accept a research scope, decide an exception, or approve an output.

The local record captures the declared actor, outcome, and evidence. It provides an audit trail. It does not independently verify professional identity or enforce enterprise roles.

Parallel work still needs precise joins

View the relationship model

flowchart TB
    I["Accepted document intake"] --> S{"Split"}
    S --> C["Extract chronology"]
    S --> Q["Extract issues"]
    C --> J{"Join this split instance"}
    Q --> J
    J --> H["Lawyer reviews both outputs"]

Each branch belongs to a particular split instance. The join waits for the required branches from that instance, rather than combining whichever completions happen to exist. Rework can create another pass through a process, so instance identity matters.

Preserve progress across sessions

State transitions are persisted in SQLite. A checkpoint carries the pinned blueprint, required skill versions, execution state, decisions, event history, and included artifacts. Resuming should continue from that state without repeating completed tasks.

Tool access must be checked again in the destination host. A package can carry instructions and records; it cannot carry a promise that a connected research service is authorized there.

The local lineage model expects one active executor. Exporting a checkpoint is a handoff, not a mechanism for creating independent concurrent copies to merge later. Offline copies cannot be globally locked by a local runner; divergent histories require explicit selection.

Treat uncertain external outcomes carefully

If an external action times out after submission, the action may already have succeeded. Record the intent and any receipt. Reconcile the external state before retrying. A local transaction cannot promise exactly-once behavior across an unrelated third-party service.

The first release supports a defined process subset: start and end events, human/AI/integration tasks, exclusive decisions, paired parallel branches, bounded rework, and expanded subprocesses. External replies enter through waiting tasks. Unsupported constructs should fail clearly instead of being approximated silently.

The BPMN export is an interchange representation. Execution follows the validated canonical manifest. It is not a general-purpose BPMN server or a claim of full Signavio round-trip compatibility.