diff --git a/check.html b/check.html index 339da96..02af63e 100644 --- a/check.html +++ b/check.html @@ -214,7 +214,7 @@
Both are the constructions @observer-protocol/policy-engine exports at
- 1.0.0-rc.12, the version npm's latest tag serves a reader today.
+ 1.0.0-rc.21, the version npm's latest tag serves a reader today.
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 bytes it produces are identical to the package's own over every refusal this repository publishes.
A divergence turns the build red rather than turning a verdict here wrong.
diff --git a/docs.html b/docs.html
index 1253795..59f8df9 100644
--- a/docs.html
+++ b/docs.html
@@ -218,7 +218,7 @@
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.12. Re-measured against
+ engine.running: "0.3.3"; the package above is 1.0.0-rc.21. 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 a5f0c5b..d9f62af 100644
--- a/index.html
+++ b/index.html
@@ -983,7 +983,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.12 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.21 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 @@ -501,7 +501,7 @@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.12, 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.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.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.