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 records. The v3 construction is in no published release. A v3 record
- checks on this page, which carries the construction from the engine commit that issues it; it does not check with
- npm install, whose signableFromRefusal rebuilds a v3 store record without v3's fields and does
- not read the served row at all. Measured 24 August 2026 against the version npm install serves.
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 records CI holds this page's v3 construction to. A + 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 @@ -223,13 +225,14 @@
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 and v2 refusal constructions are what @observer-protocol/policy-engine exports at
- 1.0.0-rc.21, the version npm's latest tag serves a reader today.
- The v3 refusal construction is in no published release; this page carries it from the unpublished engine commit that
- issues it. Corrected 24 August 2026: this paragraph said both constructions were the package's, and for v3
- that was false. 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 and v2 bytes it produces are identical to the package's own over every such refusal this repository publishes,
- and that its v3 bytes match five records the enforcement point signed, because there is no package to hold them to.
+
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 โ
offline.didDocumentPath at a local copy and it makes no network call at all. The hosted verifier is a separate deployment running a different engine version; see the SDK section.POST /v1/verify returns 200 with a signed result.
engine.running: "0.3.3"; the package above is 1.0.0-rc.21. Re-measured against
+ engine.running: "0.3.3"; the package above is 1.0.0-rc.22. Re-measured against
rc.10 on 9 August 2026: they agree on 7 of the 8 artifacts this site publishes. The eighth is
never evaluated by the hosted engine at all — it is refused at that deployment's issuer
allowlist, which does not carry the testbed issuer. So the agreement is on samples rather
diff --git a/index.html b/index.html
index 1f30995..2e1fd9e 100644
--- a/index.html
+++ b/index.html
@@ -1008,7 +1008,7 @@ onUnreachable: 'cache-then-deny' is the only accepted value: if the revocation list cannot be fetched, a cached answer is used and then the credential is denied. A status list hosted on an origin other than the pinned issuer's is refused until you allowlist it, and Observer Protocol's own clause-zero revocation demonstration is exactly such a pair, so it does not verify out of the box. That limit is published in the package.
@observer-protocol/policy-engine 1.0.0-rc.21 on npm, MIT. Section 05 is a transcript of it running against a credential served from this domain.@observer-protocol/policy-engine 1.0.0-rc.22 on npm, MIT. Section 05 is a transcript of it running against a credential served from this domain.$ npm install @observer-protocol/policy-engine $ curl -O https://observerprotocol.org/verify-samples/verifies-delegation-mandate.json @@ -354,7 +354,7 @@There is no verifier for a PolicyEvaluationCredent
A resolution record now checks with the version this page tells you to install. It did not, for four releases.
An approval resolution is the record of a human decision, signed at both ends: the routing and the outcome. Rebuilding its signed bytes needs
-resolutionPayload. The versionnpm installserves exports it. For four releases it did not.Read out of every published tarball rather than out of a release note:
+resolutionPayloadwas exported at1.0.0-rc.8, withdrawn across 4 consecutive releases,1.0.0-rc.9through1.0.0-rc.12, and restored at1.0.0-rc.13. npm'slatesttag no longer points inside that band, at1.0.0-rc.21, which is the version this page documents and the version the install line above gives you.Read out of every published tarball rather than out of a release note:
resolutionPayloadwas exported at1.0.0-rc.8, withdrawn across 4 consecutive releases,1.0.0-rc.9through1.0.0-rc.12, and restored at1.0.0-rc.13. npm'slatesttag no longer points inside that band, at1.0.0-rc.22, which is the version this page documents and the version the install line above gives you.The 122 signed resolution records this estate holds were always rebuildable by someone who installed
@rc; what they were not was rebuildable by someone who followed the instruction on this page. That was worse than a missing feature: the instruction was complete, it ran, and it produced a package silently missing one constructor. That number is now 0: every signed resolution record this estate holds is rebuildable at the versionnpm installserves. It was 122 for as long aslatestpointed inside the band.The withdrawal appears in no changelog. The package's own release notes record neither the removal nor the restoration, so nothing but the tarballs could have told you. That is why the figures in this paragraph are read from a measurement in
results/and compared against npm on every build, instead of being typed here where nothing could contradict them.What to do about it. Nothing. The version this page documents and the version its install line gives you both rebuild a resolution record, because npm’s
@@ -501,7 +501,7 @@latesttag now points past the withdrawal band rather than inside it. This site stays pinned to whatlatestserves, for the same reason it did while that was the broken version: a page that documents a version nobody receives is the failure this whole surface is written against.Convenient, ours, and now the same engine two releases back.
Correction: the two verifiers converged, and this section said otherwise for a week
This section used to argue that the hosted service was a different build. It reported
-engine.running: "0.3.3"and concluded that any agreement between the two was "agreement observed on samples, not a shared code path". That argument is false and has been since 9 August 2026. Convergence landed that day, in commitd3278efb3cb2, built 2026-08-09, and nothing here recorded it. The page went on making an argument its own subject had stopped supporting.Read from the service's own
+/versiontoday:engine.running1.0.0-rc.10,engine.builtAgainst1.0.0-rc.10,agree: true. It is the published package. The published package is1.0.0-rc.21, so the honest description is the same engine, two releases behind, and not a separate implementation. What remains true is that a version gap is a real gap: rc.10 and rc.12 are not the same code, and a difference between them is a difference you can meet.Read from the service's own
/versiontoday:engine.running1.0.0-rc.10,engine.builtAgainst1.0.0-rc.10,agree: true. It is the published package. The published package is1.0.0-rc.22, so the honest description is the same engine, two releases behind, and not a separate implementation. What remains true is that a version gap is a real gap: rc.10 and rc.12 are not the same code, and a difference between them is a difference you can meet.The old "agree on 7 of 8" figure is withdrawn, and the denominator was the defect rather than the agreement. Three of those eight artifacts never reach the hosted engine at all, so a ratio over eight was never reproducible by a reader. One is the testbed-issuer demonstration credential, and that deployment refuses it at its issuer allowlist, so the refusal is evidence about the allowlist and not about the engine. The other two are the
PolicyEvaluationCredentialartifacts, for the reason in the next paragraph. A figure whose denominator counts artifacts that cannot be submitted is not a measurement of agreement; it is a measurement of how many things we tried.A PolicyEvaluationCredential cannot be submitted here at all. Post one as the request body and the service answers
HTTP 400,body must carry agentDid (string) and mandate (object). There is noagentDidto supply: a PEC'scredentialSubjectcarriesdecision,evaluator,proposalandevaluatedAt, and noid. The endpoint's shape assumes a delegation credential granting authority to a subject, and an evaluation credential has no subject in that sense. This is the same root cause as the gap in section 02, met at the transport rather than in the validator: both the package and the service are built around one credential shape, and the artifact that records a determination does not have it. Wrapping a PEC in an inventedagentDiddoes get a response, and what comes back is a structural refusal aboutcredentialSchema, which is the offline failure repeated rather than a second opinion about it.The service is also candid about a second limit, in its own
@@ -544,7 +544,7 @@/versionresponse: the schema and issuer allowlists it enforces come from environment variables on the host,inRepo: false, so a change to what it accepts "leaves no reviewable record". The offline path has no such property, because the allowlist is the one you wrote.Checking a record is not approving a vendor.