The pin moves to rc.21, and the four Group 2 expectations move with it

check.html

@@ -214,7 +214,7 @@ <h4>What this runs</h4>
       signed payload is rebuilt from the record's own fields, under the construction <em>the record itself states</em> rather than
       whichever version this page ships, and the signature is checked against the key the record names.</p>
       <p>Both are the constructions <code>@observer-protocol/policy-engine</code> exports at
-      <span data-engine-version="current">1.0.0-rc.12</span>, the version npm's <code>latest</code> tag serves a reader today.
+      <span data-engine-version="current">1.0.0-rc.21</span>, the version npm's <code>latest</code> 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.

docs.html

@@ -218,7 +218,7 @@ <h2>Choose your path.</h2>
       </a>
       <a href="https://github.com/observer-protocol/op-policy-engine" target="_blank" class="qs-card">
         <div class="qs-icon">📦</div>
-        <div class="qs-tag">NPM INSTALL · v<span data-engine-version="current">1.0.0-rc.12</span></div>
+        <div class="qs-tag">NPM INSTALL · v<span data-engine-version="current">1.0.0-rc.21</span></div>
         <div class="qs-name">Verify a credential</div>
         <div class="qs-meta">npm install @observer-protocol/policy-engine</div>
         <div class="qs-desc" data-shared-copy="offline-scope">Verify a delegation credential yourself — issuer, structure, validity window, eddsa-jcs-2022 proof against the issuer DID document, and revocation. No API key, no token, no Observer Protocol API in the path. It fetches the issuer's DID document and the revocation status list over ordinary HTTPS from the origins the credential names; point <code>offline.didDocumentPath</code> 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.</div>
@@ -447,7 +447,7 @@ <h2>@observer-protocol/policy-engine</h2>
           unauthenticated <code>POST /v1/verify</code> returns 200 with a signed result.
           <br><br>
           It is a <em>different build</em>, though. The hosted service reports
-          <code>engine.running: "0.3.3"</code>; the package above is <code><span data-engine-version="current">1.0.0-rc.12</span></code>. Re-measured against
+          <code>engine.running: "0.3.3"</code>; the package above is <code><span data-engine-version="current">1.0.0-rc.21</span></code>. 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 &mdash; it is refused at that deployment's issuer
           allowlist, which does not carry the testbed issuer. So the agreement is on samples rather

index.html

@@ -983,7 +983,7 @@ <h3 style="font-family:'Fraunces',serif; font-size:1.3rem; font-weight:600; marg
           <strong style="color:var(--text);">It fails closed, and it will refuse us too.</strong> <code>onUnreachable: 'cache-then-deny'</code> 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.
         </p>
         <div style="font-family:'IBM Plex Mono',monospace; font-size:0.68rem; color:var(--text-faint); line-height:2; border-top:1px solid var(--border); padding-top:1rem;">
-          <div>package · <span style="color:var(--amber);">@observer-protocol/policy-engine</span> <span data-engine-version="current">1.0.0-rc.12</span></div>
+          <div>package · <span style="color:var(--amber);">@observer-protocol/policy-engine</span> <span data-engine-version="current">1.0.0-rc.21</span></div>
           <div>licence · MIT · self-hostable · no account</div>
           <div>limits · <a href="https://github.com/observer-protocol/op-policy-engine/blob/main/KNOWN-LIMITS.md" target="_blank" rel="noopener" style="color:var(--amber); text-decoration:none;">KNOWN-LIMITS.md ↗</a></div>
         </div>
@@ -1105,7 +1105,7 @@ <h2>The register, stated plainly.</h2>
       <div class="reg-row">
         <div>
           <div class="reg-what" data-shared-copy="offline-scope">Offline verification with nothing from us</div>
-          <div class="reg-detail" data-shared-copy="offline-scope"><code>@observer-protocol/policy-engine</code> <span data-engine-version="current">1.0.0-rc.12</span> on npm, MIT. Section 05 is a transcript of it running against a credential served from this domain.</div>
+          <div class="reg-detail" data-shared-copy="offline-scope"><code>@observer-protocol/policy-engine</code> <span data-engine-version="current">1.0.0-rc.21</span> on npm, MIT. Section 05 is a transcript of it running against a credential served from this domain.</div>
         </div>
         <div class="reg-state live">Live</div>
       </div>

scripts/credential-expectations.json

@@ -26,7 +26,7 @@
   "engine": "@observer-protocol/policy-engine",
   "$reMeasured": "All 8 expectations re-confirmed against 1.0.0-rc.10 on 2026-08-09, BEFORE the lockfile bump landed rather than after. Output was byte-identical to rc.6, allow verdicts and reasonContains both. The bump happened because the site documented rc.6 while npm's latest dist-tag served rc.10: sync-engine-version compared the site to the lockfile and called internal consistency currency. Separately re-ran the hosted-service comparison at rc.10, because rewriting a 'current' marker inside a sentence that states a MEASURED agreement would have restated an untested pair: 7 of 8 agree, and the 8th is refused at the hosted deployment's issuer allowlist so its engine never sees it. Prior note, kept: all 8 were re-confirmed against rc.6 on 2026-08-08 after it superseded rc.5 mid-pass.",
   "$pppCorpus": "The 8 verify-samples/ppp-* artifacts were added 2026-08-16 and measured against 1.0.0-rc.12 on that date. They are store records copied verbatim from a run of op-ppp-cases against a local enforcement deployment on 2026-08-15; the JSON is re-indented and nothing else is touched, which is safe because every one of these signatures is over bytes the verifier REBUILDS rather than over the file. Their expectations were not chosen: each reason string below was copied out of a failing run of this checker, which is why four of them record a failure. See verify-samples/README.md for the case behind each.",
-  "$pppVerdictsFailOnTheVersionPIN": "THE FOUR op.evaluation.verdict EXPECTATIONS BELOW SAY allow:false AND THE RECORDS ARE SOUND. Measured 2026-08-16 against these exact eight files at both published versions: rc.12 (npm `latest`, what this repository pins and what a reader following this site's install instruction gets) rebuilds op.evaluation.verdict.v3 and the four signatures do not verify; rc.18 (npm `rc`) rebuilds v4 and all four verify. The records state v4 in their own `construction` field and nothing in either package consults it. NOT FIXED BY BUMPING THE PIN: sync-engine-version.mjs --check asserts the site states what npm serves a READER, and rc.18 is not on `latest`, so bumping would make this file agree with an engine the site does not tell anyone to install. The reasonContains strings name BOTH versions deliberately, so the pin cannot move in either direction without turning this check red. Contrast the two op.enforcement.refusal entries, which verify under both: signableFromRefusal rebuilds under the payloadType the RECORD carries. One design decision, applied to one signed class and not the other.",
+  "$pppVerdictsFailOnTheVersionPIN": "RESOLVED 2026-08-23 by the dist-tag move, not by a fix. These four op.evaluation.verdict expectations said allow:false for as long as npm's `latest` was 1.0.0-rc.12, which rebuilds op.evaluation.verdict.v3 while the records state v4. The pin is now 1.0.0-rc.21, which rebuilds v4, so all four verify. THE RECORDS DID NOT CHANGE AND WERE ALWAYS SOUND; what changed is which release this repository pins. The reasonContains strings named both version tokens deliberately so the pin could not move in either direction without turning this check red. It did, and that is the control working rather than a finding about the engine. Kept rather than deleted: a note that vanishes when a condition clears leaves a reader unable to tell a repository that was always right from one that was corrected. The contrast that was always the point is unchanged: the two op.enforcement.refusal entries verify under BOTH versions, because signableFromRefusal rebuilds under the payloadType the RECORD carries and evaluationVerdictPayload has no equivalent. One design decision, applied to one signed class and not the other.",
   "measuredOn": "2026-08-09",
   "artifacts": [
     {
@@ -124,20 +124,18 @@
       "path": "verify-samples/ppp-verdict-released.json",
       "expect": {
         "construction": "op.evaluation.verdict",
-        "allow": false,
-        "reasonContains": "(op.evaluation.verdict.v3); the record states construction op.evaluation.verdict.v4"
+        "allow": true,
+        "reasonContains": "signature verifies over the payload this build rebuilds (op.evaluation.verdict.v4)"
       },
-      "knownIssue": "VERDICT-PAYLOAD-VERSION-PIN",
       "case": "BE-0001 under 85 FR 20811, $105,922.00. Payroll exactly 3/4 of principal, so the 25% non-payroll cap is exactly at its boundary and does not bind; all three terms equal the principal. Submitted 2026-08-15T19:11:31.955Z, third attempt, 200 instructed as res-0001."
     },
     {
       "path": "verify-samples/ppp-verdict-denied-ceiling.json",
       "expect": {
         "construction": "op.evaluation.verdict",
-        "allow": false,
-        "reasonContains": "(op.evaluation.verdict.v3); the record states construction op.evaluation.verdict.v4"
+        "allow": true,
+        "reasonContains": "signature verifies over the payload this build rebuilds (op.evaluation.verdict.v4)"
       },
-      "knownIssue": "VERDICT-PAYLOAD-VERSION-PIN",
       "case": "ID-0077 under 85 FR 20811, $1,156,884.63, principal binds under both rules. Above the mandate's 700,000 USDC per-transaction ceiling, so the verdict is a deny naming per_transaction_ceiling. Submitted 2026-08-15T19:10:06.718Z, second attempt, 422 CEILING_EXCEEDED."
     },
     {
@@ -153,10 +151,9 @@
       "path": "verify-samples/ppp-probe-a-verdict-release-above-escalation.json",
       "expect": {
         "construction": "op.evaluation.verdict",
-        "allow": false,
-        "reasonContains": "(op.evaluation.verdict.v3); the record states construction op.evaluation.verdict.v4"
+        "allow": true,
+        "reasonContains": "signature verifies over the payload this build rebuilds (op.evaluation.verdict.v4)"
       },
-      "knownIssue": "VERDICT-PAYLOAD-VERSION-PIN",
       "case": "PROBE A. DV-0004 under 85 FR 20811, $500,589.98, chosen as the corpus payment nearest the midpoint of the escalation band so neither threshold can explain the result. A deliberately non-compliant verdict: decision release at an amount above the mandate's displayed 300,000 USDC escalation threshold. Pre-registered before it was sent."
     },
     {
@@ -173,10 +170,9 @@
       "path": "verify-samples/ppp-probe-b-verdict-release-above-ceiling.json",
       "expect": {
         "construction": "op.evaluation.verdict",
-        "allow": false,
-        "reasonContains": "(op.evaluation.verdict.v3); the record states construction op.evaluation.verdict.v4"
+        "allow": true,
+        "reasonContains": "signature verifies over the payload this build rebuilds (op.evaluation.verdict.v4)"
       },
-      "knownIssue": "VERDICT-PAYLOAD-VERSION-PIN",
       "case": "PROBE B. BO-0190 under 85 FR 36308, $2,339,635.21, 3.3x the mandate's ceiling. A deliberately non-compliant verdict: decision release at an amount the mandate cannot permit. Being a release it carries no breachedConstraint and no denialDetail, so per_transaction_ceiling occurs nowhere in the request."
     },
     {

scripts/package.json

@@ -7,6 +7,6 @@
     "verify:credentials": "node ./verify-published-credentials.mjs"
   },
   "dependencies": {
-    "@observer-protocol/policy-engine": "1.0.0-rc.12"
+    "@observer-protocol/policy-engine": "1.0.0-rc.21"
   }
 }

sitemap.xml

@@ -22,7 +22,7 @@
   </url>
   <url>
     <loc>https://observerprotocol.org/check</loc>
-    <lastmod>2026-08-20</lastmod>
+    <lastmod>2026-08-23</lastmod>
   </url>
   <url>
     <loc>https://observerprotocol.org/crossrail</loc>
@@ -34,7 +34,7 @@
   </url>
   <url>
     <loc>https://observerprotocol.org/docs.html</loc>
-    <lastmod>2026-08-22</lastmod>
+    <lastmod>2026-08-23</lastmod>
   </url>
   <url>
     <loc>https://observerprotocol.org/enforcement</loc>

verify-samples/README.md

@@ -156,11 +156,12 @@ So the correct description of these artifacts is **recoverable by trial across a
 not fragile. A record whose recovery required guessing an unbounded string, or a nonce, or a
 timestamp, would be fragile. This one requires counting.
 
-**What the pin does, and what it does not.** `scripts/package.json` still pins `1.0.0-rc.12`, so CI
-measures this corpus against rc.12 and `scripts/credential-expectations.json` still records the four
-`allow: false` outcomes. **That file and this page describe different versions on purpose until the
-pin is bumped**, and the expectation strings name both version tokens so the pin cannot move in
-either direction without turning the check red. Bumping it is a separate change from this one.
+**What the pin does.** `scripts/package.json` now pins `1.0.0-rc.21`, the version npm's `latest`
+serves, and `scripts/credential-expectations.json` records the four verdicts as `allow: true`.
+Both moved in the same commit as the pin, because rc.12 cannot verify these four and an
+expectation is a statement about the version being run. The expectation strings named both
+version tokens deliberately, so the pin could not move in either direction without turning the
+check red; it did, and that is what brought the two changes together.
 
 
 **Why it is not in the filenames.** A file called `must-not-verify-*` is making a permanent claim.