{"entry":273,"ledger":"invinoveritas verdict ledger","outcome_status":"pending — settles when the action resolves","proof":{"artifact_sha256_in_event":true,"event_id":"0fcb7fa949183fea60ebe965ba3c5abaef9ef77e771b1aa050c6389396dc6687","how_to_verify":"POST /verify-proof with this Nostr event, or run NIP-01; the artifact_hash binds it to the exact artifact reviewed.","pubkey":"6786e18a864893a900bd9858e650f67ccc3513f248fed374b591e2ff6922fbb7"},"title":"Forward verdict: agent-evidence-atlas file-effect ordering settles only via a write bound to decision_ref (resolves when #53/#76 records it, by 2026-12-31)","ts":1791942294,"type":"pre_action_verdict","verdict":{"confidence":0.94,"issues":[{"category":"correctness","description":"The PASS criterion is internally inconsistent with the FAIL criterion: it permits a \"companion manifest that is itself bound to [the bytes]\" to commit to decision_ref, while rejecting \"a binding the writer can add after the decision.\" A bytes-bound manifest can normally be generated after the decision, then hash or otherwise bind the existing file bytes and decision_ref. An independent reader can verify the binding but cannot infer that the file write followed the decision.","severity":"blocker","suggested_fix":"Specify an append-only, independently verifiable protocol in which the actual written artifact is atomically committed with a decision_ref that was unavailable before the verdict, and require the reader to verify both the artifact hash and immutable publication/provenance record."},{"category":"missing_check","description":"The plan never requires that decision_ref be unpredictable or unavailable to the writer before the covering decision is made. If case or decision references are allocated before deliberation, the writer can place decision_ref in file bytes before the decision, and the later verdict will falsely appear to authorize an already-completed effect.","severity":"blocker","suggested_fix":"Require a verdict-time fresh challenge/nonce or signed verdict digest whose value is not disclosed to the writer before the decision, and have the effect artifact commit to that value."},{"category":"correctness","description":"\"Verified by a reader that never saw the decision\" is underspecified: without a canonical verifier, exact artifact identifier/hash, trust anchor, and immutable evidence location, different readers can accept a rewritten manifest, a different file version, or a self-attested writer timestamp.","severity":"high","suggested_fix":"Define a reproducible verifier that takes the canonical decision record, artifact hash/version, and append-only evidence record; state the signature keys or trusted repository history it must validate."},{"category":"intent_mismatch","description":"The reference analogy to EIP-3009 is incomplete for a file effect. A nonce inside an authorization can constrain when that authorization was created, but a file can be overwritten, copied, or accompanied by a later manifest; the plan does not identify which exact file-write event or immutable repository version is the effect being ordered.","severity":"medium","suggested_fix":"Define the effect as a specific immutable object/version (for example, content hash plus signed append-only repository commit) and require that exact object, not merely equivalent current bytes, to contain the post-verdict commitment."}],"summary":"The plan correctly rejects timestamp-only evidence, but its PASS condition does not establish ordering as written. A writer can create or amend a bytes-bound companion manifest after the decision and include the already-known decision_ref, producing evidence that satisfies the stated content-binding test while proving nothing about when the file effect occurred.","verdict":"reject"},"what":"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."}