← the log
sequence 50

delphi.question.published

Appended 15 Aug 2026, 15:53 UTC. Its place in the chain is fixed by the hash of the entry before it; what follows is whether that place is covered by a signature.

← 4951 →
01. Link to this band.

The entry

entry_hash532696edbfae. The chained hash of entry 50, which is what every proof on this page is about.REAL_UTC
sequence_number
50
entry_type
delphi.question.published
entity_type
forecast_question
entity_id
cd22f6a9-1eb7-4927-a2e9-6736a77b75cc
logged_at
2026-08-15T15:53:37.206251+00:00
previous_hash
a6db08f4f2d4a8696faf5581922aee1c6217d9ed1966fade5d4ca3eccd8601cf
payload_hash
e8d22225a60c33ec95fcdfddad30701d20d80fa38fa7dcbdcc374048f3d8d16d
entry_hash
532696edbfae65c292b5f964f925a763eda0ea42ed52c55523c480209e8fe558

sourceGET /api/transparency/entries/{n}· one entry, as served to this reader· payload served

02. Link to this band.

Payload

{
  "slug": "will-copernicus-report-september-2026-as-the-warmest-september-in-its-record",
  "title": "Will Copernicus report September 2026 as the warmest September in its record?",
  "origin": "EDITORIAL",
  "timebase": {
    "clock": "REAL_UTC"
  },
  "closes_at": "2026-09-30T22:00:00.000000Z",
  "opened_at": "2026-08-15T15:53:37.203579Z",
  "blind_mode": true,
  "provenance": "PUBLIC_RECORD",
  "description": "2026 has produced the fifth warmest February, fourth warmest March, second warmest June and joint second warmest July in the ERA5 record, with El Nino conditions developing from July.",
  "question_id": "cd22f6a9-1eb7-4927-a2e9-6736a77b75cc",
  "resolution_criteria": "YES if the Copernicus Climate Change Service monthly bulletin for September 2026 identifies the month as the warmest September in the ERA5 record.",
  "expected_resolution_at": "2026-10-12T12:00:00.000000Z",
  "canonical_source_policy": "Copernicus climate bulletin at https://climate.copernicus.eu/climate-bulletin.",
  "resolution_rule_revision": 1
}

Shown indented so it can be read. The hash is taken over the canonical form of the same object — keys sorted by code point, no insignificant whitespace, UTF-8 rather than escaped ASCII, timestamps RFC 3339 in UTC to microseconds, decimals as their plain string form. The check below re-encodes the object canonically before hashing it, which is why an indented display cannot make it pass or fail.

03. Link to this band.

Verify it here

computed in your browser, not on the server

Recomputing the hashes in this browser… If this sentence stays, this browser has no Web Crypto and nothing here has been verified locally.

The proof, as served

leaf_index
50
tree_size
181
leaf_hash
54792b96a943c087b43aa268252ba69de6e4aac0a66740349610c2147cf11add
audit_path (8)
0: c43dbb5f8de5cc22105095f969123f7bebcc0b6c08fff322a1e59dbd18c4d0641: 11c55a90d4e22bdb12653756c36ed4034e15440ca14b5bb221fc2c88bfdb76ba2: 575d95304450173ca4c6ce66d688d95c5abb0e6b923bcbf1c78a25de9ec4c02a3: 59b626cca7986be0b6ec44fe0d4d89e3fdbd22110dbe11bf0c1a9d22fcaf178b4: 2470c45a41e5b2338cd0a79e1b28f402a0e7e23251bee7ed256b2f8f028ccbe75: 0dec549ee6527dafc0e801068f2df8c4eef8fcb9972397c6eb58217673bbfe9c6: 432b3bec17cc8d9bd118f5d2d11fc56d0578ec1940af60be2192f2f1b8d43dc67: 9635acfeb8c2590a96fbee35cfdc30839f075e00ba35b025d06547731fc18743
root_hash
4c26c3ce818fe1e45410fef48bf0969b94f9e5bc0389388f5310d968c2e42fdc

The earliest published head that covers this entry

No published tree head covers this entry yet, so there is nothing signed to check it against. That is the ordinary state of an entry appended since the last checkpoint, and it is neither a failure nor a permanent one.

sourceGET /api/transparency/proof/inclusion· leaf_hash, audit_path, root_hash· audit-path nodes: 8