Execution and Runtime

Execution turns an authorized work order into actions, artifacts, and recorded results. In Sovereign Source AI, agents and workers run in limited environments. Institutional policy sets the permissions for each environment. The runtime enforces these limits, keeps the evidence, and lets the institution operate independently of any one provider. You can replace the operating system, workflow engine, and infrastructure. The intent, authority, requirements, and execution history stay the same.

The execution boundary

A Sovereign Work Order defines one unit of authorized work. It links the work to a parent intent. It also lists these items:

The platform selects an execution environment that agrees with these limits.

The agent cannot get more authority if it chooses a different tool or asks for a more permissive environment. A child work order gets the same authority as its parent, or less. The runs, actions, and artifacts of each child work order stay linked to the original authorization.

The platform isolates each worker, so the agent cannot get around these limits. Each worker gets only the capabilities and credentials that its assigned task needs. Controls outside the model manage network access, secrets, storage, and access to dependencies. A worker makes candidate results and evidence. A worker that makes a result cannot release that result.

Agents, workers, and workflows

An agent reads context. It proposes permitted actions or does them. A worker is the limited environment where the computation runs. A workflow manages dependencies, durable state, approvals, and progress across many units of work.

One program can do more than one of these roles. Each role still has a different responsibility. The workflow state records the completed work, the work that is not done, and the authority that the next step needs. A model conversation must not be the only record of institutional work. If a conversation stops, the workflow state still has the record.

Workers are disposable. Workers make candidate artifacts and evidence. A separate, trusted release process approves and signs them. Before it approves and signs an artifact, the release process examines the candidate and its evidence. Thus an attacker who gets control of a worker cannot also release artifacts.

Reference build

A reference build has these parts:

The scheduler selects an approved runtime profile. Workers get credentials with a narrow scope. They do the authorized work and return outputs with execution records. Then the platform destroys or archives each worker, as policy specifies.

A FreeBSD-first runtime is one replaceable choice for the reference build. It gives a controlled host environment with isolation, storage snapshots, and network limits. Other hardened runtimes can do the same job in the architecture. If a workload needs special compute hardware, that workload can run in a second, separate environment.

Compute capability and isolation are separate decisions. If a workload needs acceleration, that need does not give it permission to access institutional data, networks, or signature keys.

Offline operation and runtime transfer

In private or offline operation, the critical execution path must stay usable inside its permitted boundary. If policy prohibits external connections, approved local resources must supply the models, packages, credentials, policy decisions, and evidence storage.

To move a runtime, you must move more than the executable files. These records must stay valid in the destination environment:

Deployment definitions help this transfer. The real test is whether the institution can continue its governed work with a new provider. The institution must not have to rebuild its operational logic around that provider.

From the research

All topics