Illustrative example · sourced 2026-09-23Sample — never sent
Illustrative example: reading a held decision
This issue was never sent. It is an illustrative example of how an issue explains one decision. Its facts come from one real, dated entry in the public decision record, cited below; everything else is plain-language explanation, not data. It is not an upcoming send, and not today's market news.
What happened
The record dec-2026-09-23-abstain was decided at 2026-09-23T13:32:50 UTC under
policy-v2-2026-09-23. It reads status: held, with abstention.kind: no_opportunity.
Its abstention.reason field says ten candidates were voted on and seven of them drew a
pass from a seat, and that under the rule it states, any pass vetoes a buy (D38 rule that day; replaced by red-flag-v1 on 2026-09-28). The exact
wording is on the record's decision detail page, linked below.
The record's buy_count, required_approve_votes, pass_count and symbol fields are
null, not zero. This example leaves them null rather than filling them in.
Why it matters
Explanation, not data: a held day still gets its own dated record and a stated reason. In a real weekly issue, a day like this one appears as a one-line entry under a "No trades" heading, giving the date, the recorded reason and a link to the record. How the committee votes →
Uncertainty
- The record's
known_gapsfield lists one gap: "committee does not record alternatives or invalidation conditions". This example does not fill it in. - The reason accounts for seven of the ten candidates. The public record lists the ten candidate symbols but not their votes, so it does not say what happened with the other three.
- No execution or fill evidence is published for this entry, and none should be inferred either way.
Read the record
Read the entry itself on its decision detail page, or see the public log.
Real issues are built and sent automatically behind a fixed chain of send checks. This sample was never sent. Not investment advice.