Harness & Execution Runtime
A governed execution boundary between intent, models, tools and effects.
Primitive Harness records Thread → Turn → Event → Receipt and uses provider-neutral ExecutionRequest, ExecutionPlan and ExecutionRun contracts. Workspace remains product-state control plane; Harness owns governed execution.
The Harness is the part that turns 'please do this' into a controlled run, watches what happens, and keeps the receipts. Changing the AI model should not mean changing the rules.
This is one of Primitive's core architectural boundaries. Models, agents and external adapters can vary, while the execution contract remains stable. That avoids rebuilding governance separately for every provider or agent framework.
Causal execution record
The runtime stores durable Thread, Turn, Event and Receipt execution records so a run can be inspected as a sequence of inputs, transitions and effects.
Execution contracts
ExecutionRequest describes requested work, ExecutionPlan describes how it will be performed, and ExecutionRun represents the governed runtime instance.
Strategies
The canonical runtime includes deterministic Efficiency, Performance, High Assurance and Experimental execution strategies.
Runtime surfaces
Authenticated runtime inspection, cancellation and server-sent event surfaces are included in the current release capability set.
Where this description comes from
These pointers are the authority behind the status and technical description. If implementation and documentation disagree, the canonical implementation or Control contract wins and this page should be corrected.