# Event-Driven Re-check Queue: Which Determinations Are In Motion *Probity Institute — method note. Descriptive only: no rating change, no recommendation, no statement about how any holder should vote or act.* A determination is a statement about contract state at a date. The published cycle re-examines all 53 DAOs quarterly, and between cycles events happen: a governance vote transfers control of a deployment, a multisig cancels two proposals that had already passed. A reader holding a determination needs to know which of the 53 are being re-examined right now, and why. The queue answers that in one file. ```bash curl -s https://probity-institute.pages.dev/data/determinations/recheck-queue.json \ | python3 -c " import json,sys q = json.load(sys.stdin) print(q['summary']) for i in q['open']: print(i['id'], i['age_days'], 'days', [c['standard'] for c in i['cells_in_scope']]) " ``` ## What opens a re-check Four conditions, all required: 1. The watch record's class is **material** under the published classifier. Material means an executed or on-chain event of the class the standards measure, as distinct from one that touches the subject matter without settling anything. 2. The record carries a **chain read**. A material claim that rests on a forum post opens nothing until it is anchored to contract state. 3. The event touched at least one **GSA cell that exists in the determination**. 4. The event happened **after the determination's `as_of` date**. The fourth condition is the one that does real work, because it is the one that is easy to get wrong. Records carry two dates: when the event happened and when the record was written. Compound proposal 608 executed on 2026-09-29 at 08:26 UTC; the record documenting it was read on 2026-10-02; the determination is dated 2026-10-01. Counted by record date it is a post-`as_of` event. Counted by event date it is already inside the determination's evidence. The queue counts event dates and publishes the basis beside every date. ## What does not open one Not every event is a re-check, and the ones that are not are published rather than dropped. | Bucket | Meaning | Why it does not open an item | |---|---|---| | `pre_as_of_events` | The event happened on or before the determination date | The determination was made after it; the scheduled cycle covers it | | `unanchored_events` | Material class, no chain read in the record | An unanchored claim is not a state change; it opens nothing until a read lands | | `watch_only` | `may-affect` and `context` events | They touch the subject matter of a standard without settling a mechanism question | | `undated_events` | No derivable event date | The queue cannot place the event relative to `as_of` | `pre_as_of_events` carries a `date_conflict` flag for the awkward case: a record whose own re-check note names a later cycle than its event date implies. One such case is on the queue today. The flag states the conflict and does not resolve it. ## Why each event did not open an item Counts tell a reader that sixteen events were set aside and one was not. They do not say which event, or on what rule. `event_triage` says both. Every watch record the generator discovers resolves to exactly one published code: | Code | Opened | Rule | |---|---|---| | `opens_material_anchored_post_as_of` | yes | material class, chain-anchored, touches an existing GSA cell, event date after the determination `as_of` | | `does_not_open_pre_as_of` | no | event happened on or before the determination `as_of`; the published determination already covers it | | `does_not_open_no_chain_read` | no | material class but the record carries no chain read; an unanchored claim is not a state change | | `does_not_open_no_cell_in_scope` | no | material and anchored, but the class touches no GSA cell that exists in the determination | | `does_not_open_may_affect` | no | `may-affect` class: engages the subject matter of a standard without settling a mechanism question | | `does_not_open_context` | no | `context` class: recorded for the watch layer, bears on no criterion | | `does_not_open_undated` | no | no derivable event date; the queue cannot place it relative to `as_of` | Each row carries the record's own fields (`source_record`, `slug`, `record_type`, `impact`, `chain_verified`, `gsa_standards`), the date and its basis, the `bucket` it landed in, `opened`, and the rule text. `counts_by_code` totals them, and generation fails unless the triage covers every discovered event and every `opened: true` row is carried by a real item. The section also publishes `unmapped_record_types`: record classes present in the directory but absent from the watch vocabulary. An unmapped class is classified `context` by default and can never open an item, so a vocabulary gap would otherwise look identical to "nothing happened". Listing the gaps makes the difference visible. ```bash curl -s https://probity-institute.pages.dev/data/determinations/recheck-queue.json \ | python3 -c " import json,sys q = json.load(sys.stdin)['event_triage'] print(q['counts_by_code'], q['unmapped_record_types']) for e in q['events']: print(e['event_date'], e['slug'], e['record_type'], e['code']) " ``` ## Field guide | Field | Meaning | |---|---| | `id` | `rc--`; stable while the earliest event in the item is stable | | `opened`, `age_days` | When the item opened, and how long it has been open | | `status` | `open`, `stale` (open past 45 days), or `closed` | | `trigger_fingerprint` | SHA-256 of the canonical sorted trigger identity (`source_record`, `slug`, `event_date`, `record_type`); a closure cannot silently absorb a later event | | `triggers[]` | The event or events that opened it, including `source_record`, event date/basis, record type, standards and chain-verification state | | `cells_in_scope[]` | Each GSA standard the event touches, with the verdict published at `as_of` | | `closing_condition` | What closes the item: exactly one evidenced disposition per scoped cell | | `closed`, `disposition`, `cells_moved` | Closed date; typed item result (`no_change`, `cell_change`, `superseded`); and the exact moved-cell list | | `cell_dispositions[]` | Per-cell `before`, `current`, `after`, typed disposition, and non-empty evidence | | `event_triage` | Every discovered event with the published code that decided it, the rule text, and the class vocabulary gaps | | `undated_events` | Records an event date could not be derived for; published so an undatable record cannot vanish into a count | Open items merge events for the same DAO within 30 days. A closed item's date is a hard boundary: it consumes exactly the trigger set through that date, and later material events start a new item even when they fall inside 30 days. Event records describe arcs, not independent facts: one governance arc can produce seven records, and seven re-checks for one arc is noise. ## Worked example: Compound, opened 2026-10-07 Proposals 612 and 613 passed and were queued before the Community MultiSig cancelled them. The cancellation is chain-verified: `ProposalCanceled` events on the Compound Governor at transaction `0xf9eac8a2…`, block 26141787, 2026-10-07 16:44:59 UTC. Both cells the event touches, GSA-1 and GSA-2, were `near-miss` at `as_of` 2026-10-01. The item closed `no_change` on 2026-10-21 under queue schema 1.1 (the closure contract is unchanged in 1.2). GSA-1 remains `near-miss`: a 5-of-9 multisig cancelled the queued proposals, so frozen GSA-1 check 4 (no external EOA or multisig can cancel a queued proposal) remains unsatisfied. GSA-2 remains `near-miss`: this event does not establish token-holder replacement or revocation of every operator without incumbent consent. The closure publishes one evidenced `no_change` row for each cell, `cells_moved: []`, and a fingerprint binding the disposition to this exact trigger record. ## Limits - **Event dates are derived, not declared.** A record type with a field holding the event's own timestamp yields `date_basis: event_timestamp`. Otherwise the basis falls back to the read timestamp, then to the latest date in the record. The basis is always published, so a reader can discount an item whose date rests on the weakest basis. - **The 30-day merge window is a judgement.** Two genuinely separate arcs within 30 days share one item. The triggers list keeps them separately visible. - **Closure is written, never inferred.** A generator does not decide that a re-check is done. Queue 1.2 rejects a ledger unless its root is schema 1.0, its item and trigger identity match exactly, dates are valid, every scoped cell has one evidenced before/current/after disposition, moved-cell declarations agree, and after verdicts agree with the canonical determination. `precision_to_date` reports how many closed items actually moved a cell. - **Triage classifies; it does not re-weigh.** A `may-affect` event opens nothing even if a reader thinks it should. The class table is published so a disagreement with the classification is an argument about a stated rule rather than a guess about a silent one. - **45-day staleness is a disclosure, not an escalation.** A stale item is one the institute has not closed within 45 days of opening. It is published as stale. - **Universe only.** Events concerning DAOs outside the 53 are recorded in the watch layer but never queued, because there is no determination for them to bear on. - **The queue does not score.** An event-driven re-check brings the scheduled review forward. It applies the frozen methodology unchanged: no criterion is relaxed, and a generator never moves a cell. ## Why publish it Fifty-three verdicts with one date look equally stable to a system that consumes them. They are not. This file states which ones are in motion, which event put them in motion, and what the institute owes before it can call the review finished. A determination that is under review is a different object to hand a risk reviewer than one that is not, and the difference should be in the feed rather than in a reader's memory of the news. ---