What this entry is
A SIGNED, artifact-bound verdict committed and published BEFORE its outcome exists. The schnorr signature binds the verdict + a hash of the exact reviewed artifact to our published key; the entry is Bitcoin-anchored (OTS) while still unsettled, so the anchor provably PRECEDES the outcome. Verify via POST /verify-proof or NIP-01, with no trust in us. Outcome will be appended in place at /ledger/{n}/outcome when the action resolves.
Verdict
approve_with_concernsconfidence 0.86
The claim is directionally well-scoped: it distinguishes ordinary provider-controlled logs from independently verifiable decision evidence and supplies a fallback resolution date. Its settlement criteria remain materially ambiguous around what qualifies as "without trusting OpenAI," what documentation snapshot controls at GA, and what constitutes an equivalent mechanism.
high correctness: "A third party can verify without trusting OpenAI" is not a determinate technical standard: a signature made with an OpenAI-controlled signing key still requires trust that OpenAI correctly issued and protects that key, while it can independently verify message integrity and provenance. This ambiguity can cause disputants to reach opposite resolutions for the same signed receipt.
Fix: Define the required property as publicly verifiable cryptographic binding of a canonical question/options/choice payload to an OpenAI-published verification key, while explicitly stating that this does not establish decision correctness or remove trust in OpenAI as issuer.
high missing_check: "Official API reference / docs at GA" has no fixed evidence snapshot or definition of GA. Documentation can be revised after launch, different endpoint versions can reach GA on different dates, and a marketing GA announcement may precede or follow the reference update; this makes the resolving corpus and time contestable.
Fix: Specify the controlling source and snapshot rule: e.g., the publicly accessible official API reference for the Decisions endpoint, archived at the timestamp of OpenAI's first explicit GA announcement, or the official docs as accessed at 23:59 UTC on 2026-12-31 if no such announcement exists.
medium correctness: "Equivalent third-party-checkable record" is underspecified. A documented signed HTTP response header, detached receipt endpoint, transparency-log inclusion proof, or webhook-delivered signed artifact may satisfy the intended protection despite not being a JSON response field, whereas the opening sentence specifically says the response will not include a record.
Fix: Resolve FALSE if official documentation provides any documented response field, response header, receipt endpoint, or log-inclusion proof that cryptographically binds the canonical request payload and result and is verifiable with publicly available verification material; otherwise resolve TRUE.
medium intent_mismatch: The conclusion that deployers "will have to build that record themselves" is broader than the evidence criterion. Absence of an OpenAI-native attestation does not establish that deployers must build cryptography themselves; they could use a third-party audit/logging service, a trusted execution environment, or an external transparency log.
Fix: Narrow the conclusion to: "Deployers will not receive an OpenAI-provided independently verifiable decision record and must supply an external recordkeeping or attestation layer if they require one."