Mandates, Standards & SOPs
Three different documents answer three different questions: what is THIS agent allowed to do, what does EVERY agent on this platform have to obey, and what does OUR organisation additionally require. Getting them confused is the single most common way a new integration misreads a verdict.
Mandate — what THIS agent may do
A verifiable credential naming a target action, permissions and prohibitions, each with constraints (a spend ceiling, an allowed-merchant list, a validity window). Issued to one agent DID by its owning principal. An action outside every permission is refused with NO_PERMISSION_FOR_ACTION; a prohibition that fires outranks any matching permission. A mandate can delegate a narrower mandate to another agent — narrower per-operator (a lower ceiling, a smaller allow-list), never wider — but that's the exception, not the common case: most integrations issue one mandate per agent and stop there.
Standard — what EVERY agent must obey
A platform-admin-published rule pack (POST /standards is platform-admin only) — the cross-tenant baseline every bound agent complies with, regardless of which organisation owns it. A Standard firing is reported as STANDARD_RULE or, for a monitoring-only clause, STANDARD_OBSERVE; a missing or stale pin for an enforced Standard is STANDARD_NONCOMPLIANT.
SOP — what YOUR organisation additionally requires
Your own rule pack, created and owned within your tenant (POST /sop is owner-scoped, not platform-admin). This is where a spend-cap-below-the-mandate, a stricter merchant list, or a mandatory human review for high-risk actions actually lives day to day — the sandbox's starter agent ships with exactly one SOP, a spend cap. A firing SOP is SOP_RULE or SOP_OBSERVE.
How a molecule becomes a verdict
A Standard or SOP is a set of molecules; a molecule fires when ALL of its atoms hold, and emits its declared decision and reason code. Atoms are pure predicates over request context (an amount, a risk level, a merchant) — no clock, no network, no model call — which is what lets the same rule be evaluated identically at the gate and, for signed bundles, at the edge with no round-trip. Across every molecule of every bound pack, the MOST RESTRICTIVE decision wins: one BLOCK beats ten ALLOWs.
See it in code
{
"name": "Per-transaction spend cap",
"molecules": [{
"atoms": [{ "predicate": "amount-over", "config": { "limit": 500 } }],
"decision": "block",
"reasonCode": "SOP_RULE"
}]
}
// Bound to an agent via POST /sop then POST /sop/agents/:identityId/assign.
// Edit it in the dashboard and re-run — no redeploy of the agent, no new mandate.