Check a determination
without trusting the party
who gave it to you.

@observer-protocol/policy-engine 1.0.0-rc.22 on npm, MIT. Section 04 is a transcript of it running against a credential served from this domain.

Two of the five. The two PolicyEvaluationCredential artifacts carry no credentialSchema and are refused by our own verifier on structure; one older trading mandate is missing authorizationConfig.policy. Re-issuing them is a signing operation, not an edit, and it has not happened yet.

Signatures solve authenticity and not completeness. A firm can hand over a hundred clean determinations and withhold the hundred-and-first, and all hundred verify. The open questions are governance and regulatory rather than cryptographic: who runs the log, who is obliged to publish to it, what a gap in it legally means, and how a firm demonstrates completeness without exposing commercially sensitive volume. Full account: /supervisors, section 04 →

A record names who decided, kept separate from who issued the authority, and that separation is real: the decider in our demonstrations is a separately-keyed did:key, cryptographically distinct from the enforcement point, and you can verify that separation offline from its own DID. What it is not is a second party. It is a fixture we generated and control, not a published organisation and not an independent third party with its own interests. The separation is real as cryptography and currently means nothing as governance. Proving a decider is genuinely independent needs a real second party, and until one exists this row says fixture rather than independent.

Of 11,432 signed records across 13 record stores we hold, written between 2026-08-05 and 2026-08-15, 3,089 of them (27.0%) cannot be checked by anyone. They are instructed, report records, and no version of the engine ever published rebuilds their signed bytes, so there is nothing to verify a signature against. This is not a version pin and it is not a gap that a reader can work around by installing something else: those records carry a signature that no counterparty, and no one here, can check. Principle 04 below says the evidence is portable or it isn't evidence. For better than a quarter of what we sign, it isn't. A second class, resolution records, was rebuildable at some published version but not at the one npm install served, for four releases. That count is now 0; section 02 of /verify carries what happened. Every figure in this row is read from results/ and fails the build if the copy and the measurement disagree. The population closes on 2026-08-15 and predates op.enforcement.refusal.v3; no v3 record is counted here.

verifyDecisionAttestation is exported by the version npm install serves, and verify-samples/ppp-determination-refused-outcome.json is a published decision attestation it returns attested on. The record carries the document that was signed as base64 beside a documentHash, and sha256 over those stored bytes reproduces that hash, so the input to the signature is rebuildable from the record alone, by someone who holds nothing else and was present for none of it. Checked in CI in both directions, so a regression and a silent repair both break the build. What it establishes is narrower than the word verifier suggests, and the narrowness is stated where the check is run rather than here: a named key signed those exact bytes and nobody has altered them since, while policyRef.hash, vocabularyRef.hash and deciderArtifactDigest.value are confirmed present and never resolved against anything. The field-level account is on the docs page.

The property above rests on the raw document and signature being preserved through ingestion. That is true of deployments running the determination-records path. It is not true of what came before it: those deployments verified an attestation once on receipt and did not keep what they verified, so a determination recorded on one of them cannot be rebuilt by us or by anyone else, permanently. This repository cannot tell you which records those are. The boundary is a property of a deployment, it is not readable from any artifact published here, and no version string in this estate marks it. Read the row above as a statement about a determination you are holding, not as a statement about every determination that exists.

/check, published 17 August 2026. No account, and the check runs in the visitor's own browser against a key recovered from the decider's own identifier, so nothing pasted into it reaches us. The page carries no script of its own and, for a period after it was published, the CDN in front of this domain added one anyway. That setting was disabled on 17 August 2026 and the absence corroborated across two runs an hour apart, so the page states again that it loads nothing, and the audit that watches it is invoked with nothing disclosed, which means the absence is proven on every run rather than asserted once. The row below carries what that layer is able to add. It covers one artifact type, a decision attestation. A delegation credential and a refusal record verify against the published engine already and neither has a box on that page, so an outside party holding one of those still installs the package. And a public surface is not a public corpus: it checks the artifact somebody hands you, and there is no address that will hand you one you were not given. That is the completeness row above, unchanged by this. The page's verdicts are run against the published sample and against deliberately broken variants on every build.

This domain is served through a CDN, and a CDN in front of a static origin can change what a visitor receives without any change to what we publish. That is a property of the arrangement rather than an accusation about a setting, and it is in this register because a page that tells a visitor what it loads is only as good as the layer between it and them. Measured on 17 August 2026: /check was published carrying no script of its own, and the page a browser received loaded static.cloudflareinsights.com/beacon.min.js. Nothing in our repository had changed, and it was injected only for requests carrying browser headers, so a build check reading the file and a plain fetch of the same URL both reported it clean. It was disabled at the zone the same day. Two runs of the audit an hour apart, on 17 and 18 August 2026, both found it absent, which is what corroborated means here and is the whole of what it means: it rules out a transient and rules out nothing else.

The surface, not the instance. A zone of this kind is capable of injecting or rewriting a page in at least these ways: an analytics beacon on every HTML response; email address obfuscation, which rewrites addresses and adds a decoder script; a script loader that defers and rewrites the page's own script tags; bot detection JavaScript served under a CDN-owned path; and a tag manager, which can load third-party tags configured entirely outside this repository. An edge function on a route can rewrite the HTML arbitrarily. Each of those is a capability of the surface and none of them is a statement about how this zone is configured today, which is not readable from this repository: the configuration lives in a dashboard and changing it produces no commit.

So the control is a measurement rather than a document. scripts/served-page-audit.mjs fetches the page as a browser and compares what it carries against what the page discloses, failing when something undisclosed appears, when something disclosed is no longer there, and when one of the page's own scripts is missing or altered. That third direction is the one a subtraction hides in: an injected script is loud, and the page's own verifier being removed leaves a page that renders and decides nothing. It also refuses to treat an absence as established on one observation: a thing that is disclosed and not there may have been removed at the zone or the edge may transiently have stopped adding it, so that answer is held open until a second run separated in time sees the same thing. It is a standalone file with no dependency on this repository, so it can run on a clock rather than on a commit, which is the only shape that catches a change nobody committed.

What that control does not reach, said here rather than left to be discovered. It reads markup and executes nothing, so it establishes what was delivered, not what is performed. It sees every script the page carries, external or inline, and it cannot see what any of them does once it runs: a runtime request made by a script already disclosed is outside it, and disclosing a tag manager would not tell you which third parties that manager then loads. An earlier version of it read only external references, so an injected inline script issuing a request on load came back clean and printed that the page loaded nothing. It was exactly accurate about the comparison it made, and that accuracy is what stopped the next question being asked. And the same limit runs along a second axis, which is the one that produced this row. Until 17 August 2026 the beacon was configured to be added for some visitors and not others, decided at the edge by where the request came from. So what was delivered varied by reader, and a fetch from one place could have found nothing while another found the beacon, with neither result wrong about itself. The audit establishes what was delivered to one client, from one origin, at one time. Edge configuration can vary delivery by origin, by user agent and by request, and nothing here claims coverage across any of those. This is the original finding on a second axis: the first version of that check could not see an inline script, and no version of it can see a reader somewhere else.

On a corpus of 908 refusals, the determination-side join is closed for 7. A refusal that fires before the attestation is read records no citation, and the record says so positively rather than leaving the field blank, so the gap is visible in the data rather than inferred from its absence. So a refused payment mostly cannot be connected to the determination it cited, and the party asking which determination a refusal was about will not get an answer from these records. Provenance: measured on the payment stack and relayed here on 17 August 2026. Unlike the figures in the rebuildable-records row above, nothing in this repository re-derives it, and the record stores it was taken over are not published here.

AIP v0.9, ratified 25 July 2026, tagged v0.9, review record in the public repository. Additive over v0.6 through v0.8; an implementation conforming to any of those remains conforming.

Published 8 August 2026 as delegation/v2.7.json, carrying requiresDecisionAttestation, served at a URL that is immutable from the moment it went live. Note precisely what this does and does not change: the shape is now pinned and public, and there is still no verifier path for a PolicyEvaluationCredential. A published schema is not a verifier.