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.84
The stated outcome is narrowly falsifiable and candidly discloses the backfilled and late-published records. Do not treat the first production day as a reliable completeness/immutability commitment until cutoff construction, immutable publication, and OTS confirmation handling are operationally enforced.
high correctness: The plan defines N by records created before midnight but does not specify an atomic cutoff/snapshot. A signer can create position 18 before 2026-10-29T00:00:00Z while the 15-minute publisher is reading an earlier records view, producing a syntactically valid 1..17 daily file that falsely omits an in-scope record.
Fix: At cutoff, transactionally persist a signed daily manifest containing the exact ordered record IDs, N, and record-set hash; generate the daily file only from that immutable manifest after all pre-cutoff writes are quiesced.
medium safety: The verdict treats any later SHA-256 change as failure, but the plan provides no immutable, independently timestamped publication of the initial file hash. The service operator can replace the file before an observer records its first hash, leaving no externally auditable evidence that a rewrite occurred.
Fix: Publish the daily-file SHA-256 and manifest to an append-only external medium or independently timestamp it before/at release, and retain immutable versioned objects rather than serving a mutable path only.
medium missing_check: Positions 1-15 commit to a v0 hash of content served by a live /attestations/<proof_id> endpoint, but no immutable content snapshot or retrieval commitment is specified. If that endpoint later changes, disappears, or serves content conditionally, third parties cannot reconstruct the attested bytes even though the record signature remains valid.
Fix: Store and publish immutable byte-for-byte attestation snapshots keyed by content hash (or CID), and make verification fetch those snapshots rather than relying on a mutable application endpoint.
medium missing_check: OTS confirmation is a stated pass condition by 2026-10-31, but the plan has no concrete calendar submission receipt, retry/failover policy, or pre-deadline verification run. A healthy daily file can therefore settle WRONG solely because the selected calendar path does not upgrade in time.
Fix: Submit to multiple OTS calendars, persist submission receipts, schedule deterministic proof-upgrade retries, and run the pinned checker against independently obtained block headers before the settlement deadline.
Outcome
settledcheck.py @1fe5fb29104d (unmodified), cold on the served /deils/anchor-log/2026-10-28.jsonl (sha256 7c9757691ef6bb83f0b0bc6963933c2870a7e29db147edcdf745e53a7848d7d4) + 2026-10-28.ots + records.jsonl, issuer 6786e18a...fbb7, header for block 973617 (hash 00000000000000000000c825458f1b71fe4fcf76bd8cf32903ab42f1f141b262, mempool.space == blockstream.info): {"status":"anchored","state":"confirmed","height":973617,"codes":[],"from_genesis":true,"after_failure":false,"notices":["late_record_beyond_grace"]}