The map
Figure 1. Five scenarios and the surfaces each one leans on. Evidence appears in every row — if a workflow cannot say what it proved, Pactmark is the wrong tool for it.The scenarios
Regulated back office
Claims, invoices and onboarding packets. Bounded work, a verified artifact, and a record that
survives an audit.
Customer refunds
An irreversible financial effect behind an approval gate, with a reconciliation path for the
moment the payment API stops answering.
Research with citations
Bounded egress, citation-shape verification, and an evidence record that refuses to claim the
sources are true.
Document pipeline
Content addressing, deterministic verifiers and a reproducible export — no model required for
the checks.
Incident response
Delegated worker authority, fenced ownership, and compensation as a separately authorised run.
The shape every scenario shares
1
Bound the work before starting it
Purpose, data class, budget, deadline, decision owner. The
WorkOrder is where you decide what
“too far” means.2
Declare tools honestly
Risk class, scopes, egress and effect strategy. Over-declaring costs you an approval prompt;
under-declaring costs you an incident.
3
Put humans at the irreversible steps
Not at every step.
require_approval on R3 and above, allow_with_grant below it, is a common
starting shape.4
Produce an artifact, then verify it
Deterministic checks first — schema, checksum, policy. Model-assisted evals only where a
deterministic check genuinely cannot exist.
5
Say what you proved, and what you did not
The
doesNotProve list is not a formality. It is the part that makes the rest credible.When to use something else
Reading the scenario pages
Each one follows the same structure: the situation, the actors, theWorkOrder and policy, the
tools, the flow, the evidence produced, and — always last, always present — what that evidence does
not establish.
Start with refunds
It is the scenario where every Pactmark design decision has an obvious reason.