Pactmark is an evidence-native TypeScript framework for agents that perform bounded work under explicit authority. Each word in that sentence is load-bearing.
Producing a defensible record is not an add-on you bolt on later. The run history, the artifact digests, the verification results and the EvidenceRecord are first-class objects with their own schemas, and a record that cannot state its own limits fails validation.
A run is not an open-ended conversation. It is a WorkOrder with a goal, a validated input, a purpose, a data class, a budget, a deadline and an accepted agent definition. When those bounds are exhausted, the run stops.
Authority is an object, not a vibe. Grants, approvals, credential references and reservations are created by host code, bound to a tenant and purpose, and re-checked before every effect.

​
The problem it is built for

You can already get a model to call a function. What you cannot easily get is a truthful answer to the questions an auditor, a security reviewer or an incident commander will ask three months later:
1

Who authorised this?

Not “the agent decided to” — which authenticated principal, in which tenant, for which declared purpose, under which capability grant, valid until when.
2

What actually happened?

Not a reconstructed log line — an ordered, append-only sequence of validated events that no later process is allowed to rewrite.
3

Did the external effect occur?

Not “probably” — either an acknowledgement, a definite non-dispatch, or an explicitly parked uncertainty waiting on a registered reconciliation strategy.
4

What was checked, and what was not?

Not “it passed” — the exact bytes, the exact verifier, the exact rubric version, and a written list of the things that result does not prove.

​
Where it fits

Figure 1. Pactmark earns its complexity where an action has consequences and someone will ask about it afterwards. Notice that evidence appears in every row.

​
What Pactmark is not

Being explicit about the product boundary saves everyone time: The kernel owns work contracts, authority, durable run semantics, governed effects, artifacts, verification and bounded evidence. Provider, protocol, storage and platform integrations all live behind adapters, and that separation is enforced by dependency rules, not convention.

​
How to read this documentation

If you want to build something today

Quickstart → First agent → Defining tools → Testing agents.

If you are evaluating the design

Mental model → Architecture → Authority and policy → Limits.

If you are the security reviewer

Security model → Threat model → Sandbox boundary → Supply chain.

If you have to run it in production

Readiness checklist → Data flow → Reliability → Responsibility matrix.
Every page on this site carries a compatibility note and, where relevant, an explicit statement of what the described behaviour does not establish. Those statements are part of the documentation, not disclaimers appended to it. Start with What Pactmark does not prove if you are deciding whether to adopt it.