Paste a decision attestation
or an enforcement refusal record.
Find out whether it holds.

The example, and why it is this one

Load the published example fills the box with ppp-determination-refused-outcome.json, served from this domain and checked in CI on every build. It is a refusal determination: an agent declining a claim, which is the case a disputing party actually arrives with. Try the tool on it before you have an artifact of your own.

Load a refusal record fills it with an enforcement refusal instead, from a card-dispute demonstration against Banxico Circular 34/2010 numeral 3.6. A reversal of a credited amount was requested, the decider found it did not proceed, and the mandate refused the payment because that outcome is not one it treats as authorising. The figures and the parties are constructed and the regulation is real; nothing in it is a client record and it is an authorisation for nothing.

It is the record a service actually sent, not one written for this page. It was taken unmodified from a GET /v1/refusals response, which is the shape a console's copy button puts on your clipboard, and it is signed under op.enforcement.refusal.v3. So the example here is the same thing you would be holding, in the same shape, under the construction the enforcement point issues today.

The published engine reads v2 and v3 records. A v3 record checks on this page and with npm install: @observer-protocol/policy-engine rebuilds a v3 store record with v3's fields, and reads the served row through signableFromRefusalRow. Corrected 24 August 2026: this said the v3 construction was in no published release and did not check with npm install. That held through 24 August 2026, until rc.22 was published; the publish makes it false. Measured 24 August 2026 against the version npm install serves.

It is signed by a demonstration key that no party stands behind. The key the record names belongs to the demonstration service that issued it, the same key that signs the five v3 records this page carries as regression vectors. A green result here establishes the construction and the key: that these bytes, rebuilt under the construction the record states, were signed by the key the record names. It does not establish who held that key, and for this example nobody does. The same limit is stated on the Lightning entry in the registry, where the issuer was a demonstration did:key rather than a production one, and it applies here for the same reason.

It cites a determination, which is what makes the panel below the verdict worth reading. The refusal's signature covers four fields of that citation and not the rest of it, and the page derives that boundary by rebuilding the payload without each field rather than by consulting a list.

What this runs

An attestation document runs the same sequence as verifyDecisionAttestation: the document is canonicalised, the decider's key is recovered from its did:key, and an Ed25519 signature is checked over those bytes with your browser's own WebCrypto.

A refusal record runs the same sequence as signableFromRefusal and refusalPayload: the signed payload is rebuilt from the record's own fields, under the construction the record itself states rather than whichever version this page ships, and the signature is checked against the key the record names.

The attestation sequence and the v1, v2 and v3 refusal constructions are what @observer-protocol/policy-engine exports at 1.0.0-rc.22, the version npm's latest tag serves a reader today. Corrected 24 August 2026: until rc.22 was published this paragraph said the v3 construction was in no published release and this page carried it from an unpublished engine commit; the publish makes v3 the package's like v1 and v2, and moved the version above from rc.21 to rc.22. This page loads nothing, so it cannot import the package; it carries its own copy of those constructions and CI asserts, on every build, that the v1, v2 and v3 bytes it produces are identical to the package's own over every such refusal this repository publishes, with the five v3 records the enforcement point signed kept as regression vectors their own signatures verify. A divergence turns the build red rather than turning a verdict here wrong. The same checks, run from npm on your own machine ↗