Compatibility: Pactmark 0.1.x.
Almost every agent framework merges two things that behave completely differently: the capability and the permission to use it right now. Pactmark keeps them apart.

​
AgentDefinition — the compiled contract

An AgentDefinition compiles instructions, schemas, tools, model profiles, policy and verifiers into a versioned identity. It is reusable, immutable and says nothing about who is allowed to run it.
Registration produces digests over the whole contract. That is what makes same-version behaviour drift observable: if you change a tool’s schema but leave version: "0.1.0" alone, the digest changes, and an in-flight run that was accepted against the old contract will refuse to resume against the new one rather than quietly behaving differently.
This is the opposite of hot-reloading prompts in production. Pactmark treats an undeclared change to a running contract as a fault, because from the perspective of an audit it is one.

​
WorkOrder — the authorised piece of work

Figure 1. A WorkOrder answers five separate questions. None of them are answered by the agent definition, and none of them can be chosen by the model. The same compiled agent might be accepted under a low-risk internal work order in one tenant and refused under a highly_restricted data class in another. The definition did not change; the authority did.

​
The fields that carry the most weight

​
{ code, registryVersion }
required
The declared reason the work is being done. Grants and model security profiles are bound to purposes, so a purpose mismatch is a denial, not a warning.
​
public | internal | confidential | restricted | highly_restricted
required
Constrains which model profiles and tools are admissible at all.
​
assist | augment | automate | apprenticeship_protected | critical_human_decision
required
How much of the work the system is permitted to carry, independent of what it is technically capable of.
​
assist | co_produce | delegate_review | exception_based | closed_loop
required
How much review the output receives before it counts as done.
​
{ mode: 'requesting_principal' } | { mode: 'registered_role', role }
required
Who is allowed to approve a decision inside this run. Resolved to a concrete principal or role at acceptance time — never chosen later by the run itself.
​
WorkBudget
required
Turns, model calls, tool calls, active execution milliseconds, per-call byte and token caps, and an optional monetaryCeiling with an explicit price-bound version and expiry.
​
string[]
required
What the work asks for. Requesting a capability is not receiving it — the host still has to issue a matching grant.

​
Input stays unknown until it proves itself

createWorkOrderRequest parses the whole request through a strict schema. Inside the run, external input remains typed as unknown until its registered runtime schema succeeds. There is no path where unvalidated external data is treated as a known shape.

​
Acceptance turns a request into a bound record

A WorkOrderRequest is what a caller sends. An AcceptedWorkOrder is what the system stores, and it carries more:
A client cannot select its own tenant or principal. Those come from the injected authenticator. If your host maps them from request headers without verification, you have moved the trust boundary and Pactmark cannot move it back for you.

​
The authority boundary, restated

The model may propose content and tool requests. It cannot create a grant, an approval, a credential, a budget, a schema result or an effect acknowledgement. Those are resolved by injected host ports and persisted bindings — before, during and after the model runs.

Authority and policy

How grants, reservations and kill switches are evaluated per effect.

Run lifecycle

What happens to an accepted work order once it starts moving.