An agent holds a signed mandate that says what it may spend, on which rail, with whom. Enforcement happens at the signer boundary, before a key signs, and the verdict is verifiable by anyone.

Not a trust score, not an allowlist, not a service you have to call. A delegation credential is a W3C Verifiable Credential; the check on one is offline; the issuer DID and the schemas are public and frozen.

Run a verifier yourself. Three lines, no account, no API key:

git clone https://github.com/observer-protocol/op-verify-service
cd op-verify-service && docker compose up --build
./compose-smoke.sh

The smoke test checks a credential that must verify and one that must be refused, and fails if either answer is wrong. A test that only proves the happy path cannot tell a working verifier from one that says yes to everything.

Or verify a published credential against the hosted endpoint without cloning anything:

curl -s https://observerprotocol.org/credentials/maxi-0001-trading-mandate-2026-08.json \
  | jq '{agentDid: .credentialSubject.id, mandate: .}' \
  | curl -s -X POST https://verify.observerprotocol.org/v1/verify \
      -H 'Content-Type: application/json' --data @-

That endpoint is open by ruling. It takes an artifact as input and retrieves nothing, so a caller can only check a credential it already holds.

The adapters are not equally supported and the difference is stated, not implied. One is proven against a live system and not yet deployable; the rest are reference implementations, two of which have no published package at all. Each README says which it is and what backs that claim, because an unlabelled reference integration that someone picks up expecting production support is worse than no listing.

The hosted endpoint is a convenience, never a dependency. What it checks on a delegation credential can be re-checked offline from the npm package: the issuer DID document is public, the schema URLs are frozen and content-addressed, and revocation status lists are static public files.

That set is delegation credentials, refusal records and lapse records. It does not include determinations, resolutions, instructions or releases. A PolicyEvaluationCredential is a determination and is a different artifact from a refusal record; both published PECs still fail with PEC-NO-VERIFIER-PATH, enforced in the website repository's CI.

Refusal records became verifiable at engine rc.9, which exports the payload builder. A scratch directory containing only @observer-protocol/policy-engine@1.0.0-rc.9, with no checkout of any repository, rebuilt the signed payloads for all 14 refusals in the 2026-08-08 corpus: 14 of 14 verify, 14 of 14 reject a one-field tamper. The absence of a checkout is the point, because it makes the result a counterparty's, not ours.

"Verifiable offline by anyone" was on this org's description until 9 August 2026 with no limit at all. The list above is the limit, and it is now wider than the one written here on that date.

Archived repositories under this organisation are kept public and readable on purpose. A published package's repository link must keep resolving, and a tarball you already installed must keep verifying, whether or not the work continued.

Because they stay public, their metadata stays true. An archived repository's description and topics are a permanent public claim, not a leftover, and a permanent false claim is worse than a current one: nobody is coming back to it. When a description or topic is found wrong, the repository is unarchived, the metadata corrected, and the repository re-archived. The code is frozen at the point of archiving. The claims made about it are not. See ORG-METADATA-POLICY.md.