Skip to content

Decisions · 67 decisions · 33 open questions

The decision log

Every decision the design council made in its 11 sessions, what it rejected, and what would make it look again, with the round where it was argued. Each is a hypothesis for real implementers and stakeholders to attack through the RFC process.

Decisions by session

Session 1 · 2026-09-21

The five implementers

What changed in this session

What this is: A design exercise in eleven sessions. Session 6 added interest groups, political parties, and an ombudsman. Session 7 added political scientists, judges, and practicing attorneys. Session 8 reviewed the first simulated legislative session (SIMULATION_01_IRAN_WAR.md). Session 9 added military, law enforcement, national security, education, and budget stakeholders. Session 10 assessed the rerun with the full cast (SIMULATION_02_IRAN_WAR.md). Session 11 assessed the appropriations route (SIMULATION_03_IRAN_WAR_FUNDING.md). Five fictional implementer personas were role-played by Claude on 2026-09-21, joined by three fictional opinion creators on 2026-10-05 (Session 2) and three fictional fact-checkers on 2026-10-27 (Session 3). Session 4, the same day, put one question to all of them: would a formal grammar or ontology make coded rules and laws more verifiable? Session 5 added three fictional market and ranking stakeholders. All of this was done to stress-test the common API before any real implementer exists. Positions are plausible, not quotes from real teams. Every decision below is a hypothesis for real implementers to attack through the RFC process. The result of this exercise is AI_CODING_PROMPT.md.

  1. D1

    Standardize objects and transactions, not consensus or storage

    Rejected
    Mandatory BFT; mandatory git
    Revisit if
    Real implementers can't interoperate at the tx level
    How it was decided: Round 1: What is the common denominator?
    • Ledger wanted the consensus protocol and state transitions standardized. Loom and Docket refused: consensus can't be universal without excluding them.
    • Forge wanted the model expressible as git objects.
    • Outcome: standardize objects and transactions, not consensus or storage. Every write is a signed envelope appended to a verifiable log. Each node declares a consistency profile (strong or eventual) and a trust_model. Verification uses signed Merkle checkpoints over the log, which BFT consensus, a single-writer transparency log, per-replica logs, and signed git history can all produce. (D1, D2)
    • Dissent: Ledger wants a consensus-parameter profile standardized later; parked for a future RFC.

    Read it in the council log

  2. D2

    Signed envelopes, content-addressed objects, Merkle checkpoints, strong/eventual profiles

    Rejected
    Per-implementation formats
    Revisit if
    A trust model can't produce a checkpoint
    How it was decided: Round 1: What is the common denominator?
    • Ledger wanted the consensus protocol and state transitions standardized. Loom and Docket refused: consensus can't be universal without excluding them.
    • Forge wanted the model expressible as git objects.
    • Outcome: standardize objects and transactions, not consensus or storage. Every write is a signed envelope appended to a verifiable log. Each node declares a consistency profile (strong or eventual) and a trust_model. Verification uses signed Merkle checkpoints over the log, which BFT consensus, a single-writer transparency log, per-replica logs, and signed git history can all produce. (D1, D2)
    • Dissent: Ledger wants a consensus-parameter profile standardized later; parked for a future RFC.

    Read it in the council log

  3. D3

    Node tree with stable nids and hash-addressed nodes

    Rejected
    Line-based files; opaque CRDT state
    Revisit if
    Structural ops prove too costly at scale
    How it was decided: Round 2: How is law represented?
    • Forge proposed plain text files with line diffs. Margin objected: legal text needs stable structural addresses, and line diffs break under renumbering and re-flow. Loom wanted tree CRDT operations.
    • Outcome: a tree of nodes with stable nids (USLM-style); a Change is a list of structural ops carrying pre hashes so conflicts are detectable; a unified-text diff is a derived view. Forge maps nodes to files (one per section) and may export a git bundle as an optional feature. (D3, D4)
    • Rejected: line diff as canonical (fragile for statutes); opaque CRDT ops as canonical (hard to audit).

    Read it in the council log

  4. D4

    Changes are structural ops with pre hashes; text diff is derived

    Rejected
    Text patches
    Revisit if
    Conflict detection produces false positives
    How it was decided: Round 2: How is law represented?
    • Forge proposed plain text files with line diffs. Margin objected: legal text needs stable structural addresses, and line diffs break under renumbering and re-flow. Loom wanted tree CRDT operations.
    • Outcome: a tree of nodes with stable nids (USLM-style); a Change is a list of structural ops carrying pre hashes so conflicts are detectable; a unified-text diff is a derived view. Forge maps nodes to files (one per section) and may export a git bundle as an optional feature. (D3, D4)
    • Rejected: line diff as canonical (fragile for statutes); opaque CRDT ops as canonical (hard to audit).

    Read it in the council log

  5. D5

    Closed rule registry with statute text, integer math, vectors

    Rejected
    Smart-contract VM
    Revisit if
    Demand for custom rules outweighs risk
    How it was decided: Round 3: Are rules code or data?
    • Ledger proposed rules as smart contracts. Docket objected: a VM adds attack surface and is unreadable to the people who would have to legislate the rules. Margin added that the paper says rules should be codified in statute, so each needs plain-language text with machine parameters that provably match.
    • Outcome: a closed registry of parameterized rule kinds (always_allow, designated_approvers, threshold_vote, capital_vote), each with statute-ready text, integer-only evaluation, and test vectors. New kinds by RFC. A determination is a verifiable claim: anyone can submit one, every node re-evaluates it. Rules themselves change through governance MRs, using the same machinery, so rule-making is also collaborative. (D5, D6)
    • Dissent: Ledger conceded but wants a sandboxed custom-rule path later.

    Read it in the council log

  6. D6

    Determinations are re-evaluated claims; rule changes via governance MRs

    Rejected
    Trusted sequencer decides
    Revisit if
    Re-evaluation cost is prohibitive
    How it was decided: Round 3: Are rules code or data?
    • Ledger proposed rules as smart contracts. Docket objected: a VM adds attack surface and is unreadable to the people who would have to legislate the rules. Margin added that the paper says rules should be codified in statute, so each needs plain-language text with machine parameters that provably match.
    • Outcome: a closed registry of parameterized rule kinds (always_allow, designated_approvers, threshold_vote, capital_vote), each with statute-ready text, integer-only evaluation, and test vectors. New kinds by RFC. A determination is a verifiable claim: anyone can submit one, every node re-evaluates it. Rules themselves change through governance MRs, using the same machinery, so rule-making is also collaborative. (D5, D6)
    • Dissent: Ledger conceded but wants a sandboxed custom-rule path later.

    Read it in the council log

  7. D7

    on_threshold needs no clock; on_deadline enforced only on strong

    Rejected
    Global clock
    Revisit if
    A safe eventual-mode deadline scheme appears
    How it was decided: Round 4: Time and finality
    • Loom rejected any rule that needs a trusted clock. Docket noted real bodies need deadlines. Ledger noted that "as soon as the rule is satisfied" (the paper's automatic advancement) needs no clock if the threshold is monotone.
    • Outcome: on_threshold closing (only over the whole electorate, so it's monotone) needs no clock. on_deadline is enforced only by strong nodes; on eventual nodes it's advisory, and the determination records the exact ballot set so verifiers can re-evaluate. capital_vote requires strong, because capital accounting needs a deterministic order. (D7, D8)
    • Dissent: Loom dislikes excluding capital_vote from eventual nodes; revisit if a deterministic causal ordering is proposed.

    Read it in the council log

  8. D8

    capital_vote requires strong

    Rejected
    Allow on eventual
    Revisit if
    Deterministic causal ordering is specified
    How it was decided: Round 4: Time and finality
    • Loom rejected any rule that needs a trusted clock. Docket noted real bodies need deadlines. Ledger noted that "as soon as the rule is satisfied" (the paper's automatic advancement) needs no clock if the threshold is monotone.
    • Outcome: on_threshold closing (only over the whole electorate, so it's monotone) needs no clock. on_deadline is enforced only by strong nodes; on eventual nodes it's advisory, and the determination records the exact ballot set so verifiers can re-evaluate. capital_vote requires strong, because capital accounting needs a deterministic order. (D7, D8)
    • Dissent: Loom dislikes excluding capital_vote from eventual nodes; revisit if a deterministic causal ordering is proposed.

    Read it in the council log

  9. D9

    Ballots commit to mr_id (source, target-at-open, resolutions, electorate)

    Rejected
    Ballots on branch names
    How it was decided: Round 5: Ballot integrity
    • Margin and Ledger listed attacks: changing an MR's content after votes are cast, stuffing a group after a vote opens, and double voting.
    • Outcome: ballots commit to mr_id, which pins the source head, the open-time target head, the conflict resolutions, and a frozen electorate snapshot. An MR whose patch no longer applies goes stale and must be re-opened (ballots don't carry). Two unlinked ballots by one member void all of that member's ballots (equivocation). (D9, D10)

    Read it in the council log

  10. D10

    Equivocation voids that member's ballots; group membership frozen at open

    Rejected
    Last-write-wins
    Revisit if
    Voiding proves abusable
    How it was decided: Round 5: Ballot integrity
    • Margin and Ledger listed attacks: changing an MR's content after votes are cast, stuffing a group after a vote opens, and double voting.
    • Outcome: ballots commit to mr_id, which pins the source head, the open-time target head, the conflict resolutions, and a frozen electorate snapshot. An MR whose patch no longer applies goes stale and must be re-opened (ballots don't carry). Two unlinked ballots by one member void all of that member's ballots (equivocation). (D9, D10)

    Read it in the council log

  11. D11

    Opinions are typed, disclosed, and never counted in binding evaluation

    Rejected
    Opinions as weak votes
    Revisit if
    delegated_survey is specified
    How it was decided: Round 6: Opinions and secrecy
    • Margin wanted opinions first-class and separate from votes, with AI disclosure. Ledger argued that everything should be public by design (the paper's "disclosure as a byproduct"). Forge pointed out the paper explicitly lets parties keep private draft branches.
    • Outcome: Opinion objects with author_kind and mandatory disclosure for non-members; never counted in binding evaluation. Restricted branches are allowed, but under "no secret law": content must be revealed before an MR from it can open. Implementations publish opinions about the protocol itself (subject.type: rfc|spec), so the collaboration loop uses the same mechanism as the thing being built. (D11, D12)

    Read it in the council log

  12. D12

    Restricted branches allowed, but reveal before MR ("no secret law")

    Rejected
    All-public; all-private
    Revisit if
    Legal/political review objects
    How it was decided: Round 6: Opinions and secrecy
    • Margin wanted opinions first-class and separate from votes, with AI disclosure. Ledger argued that everything should be public by design (the paper's "disclosure as a byproduct"). Forge pointed out the paper explicitly lets parties keep private draft branches.
    • Outcome: Opinion objects with author_kind and mandatory disclosure for non-members; never counted in binding evaluation. Restricted branches are allowed, but under "no secret law": content must be revealed before an MR from it can open. Implementations publish opinions about the protocol itself (subject.type: rfc|spec), so the collaboration loop uses the same mechanism as the thing being built. (D11, D12)

    Read it in the council log

  13. D13

    REST + JSON, OpenAPI 3.1, SSE, single write endpoint

    Rejected
    GraphQL; gRPC
    Revisit if
    Streaming or batching needs outgrow REST
    How it was decided: Round 7: API style and conformance
    • GraphQL, gRPC, and REST were all proposed. Outcome: REST + JSON (OpenAPI 3.1 and JSON Schema) is normative because it's the easiest for any AI coding agent to implement and debug with curl; SSE for live events; one write endpoint (POST /transactions) and many reads; problem+json errors. (D13)
    • Conformance: levels L0-L3, shared vectors, a black-box harness with seeded synthetic rosters and voting blocs, and scenarios S1-S11. Performance is reported as metrics, not pass/fail. Vectors are provisional until a second independent implementation reproduces them. (D14)

    Read it in the council log

  14. D14

    Levels L0-L3; metrics not thresholds; provisional vectors

    Rejected
    Pass/fail performance targets
    Revisit if
    Enough data to set defensible targets
    How it was decided: Round 7: API style and conformance
    • GraphQL, gRPC, and REST were all proposed. Outcome: REST + JSON (OpenAPI 3.1 and JSON Schema) is normative because it's the easiest for any AI coding agent to implement and debug with curl; SSE for live events; one write endpoint (POST /transactions) and many reads; problem+json errors. (D13)
    • Conformance: levels L0-L3, shared vectors, a black-box harness with seeded synthetic rosters and voting blocs, and scenarios S1-S11. Performance is reported as metrics, not pass/fail. Vectors are provisional until a second independent implementation reproduces them. (D14)

    Read it in the council log

Session 2 · 2026-10-05

Opinion creators join the council

What changed in this session

What changed: The five implementers return, joined by three fictional opinion creators, again role-played by Claude. Creators are not implementers and hold no roster seat. They speak for the people who will turn protocol output into public opinion. Decisions continue the numbering from Session 1 and are hypotheses for the RFC process like everything else.

  1. D15

    Equal signed disclosure (funding, affiliations, ai_assistance) for all non-member opinions; no badges

    Rejected
    Creator-specific kind; verified badges
    Revisit if
    Disclosure proves unenforceable or is gamed
    How it was decided: Round 8: Who gets to speak, and what must they disclose?
    • Quick Take asked for a creator author_kind with a verified badge. Margin objected that badges drift toward status, then toward weight. Ledger noted D11 already lets anyone publish without a seat.
    • Deep Dive accepted sponsorship disclosure only if it bound every non-member opinion: advisors, AI agents and their operators, think tanks, and creators alike. Independent agreed and added that AI-assisted scripts should be flagged, not only autonomous agents.
    • Outcome: no creator-specific kind and no badges. All non-member opinions carry signed funding[], affiliations[], and an ai_assistance field (none | assisted | generated), applied equally. (D15)
    • Dissent: Deep Dive asks why members' own conflicts are exempt. Parked as OQ-9.

    Read it in the council log

  2. D16

    Hash-pinned citations via /cite/{hash}; proposer summaries labeled; other summaries are Opinions

    Rejected
    Official summaries; branch-name links
    Revisit if
    Creators can't use hash citations in practice
    How it was decided: Round 9: Citation, permalinks, and "the bill changed after I covered it"
    • Independent described the core creator problem: they cover a draft, it changes, and the audience accuses them of misreporting. Forge observed content addressing already solves this if citations point at hashes, not branch names.
    • Quick Take wanted an official plain-language summary on every MR to clip from. Docket refused: an "official" summary implies authority the protocol does not have. Margin added that summaries are opinions by nature.
    • Outcome: a stable citation form GET /cite/{hash} that always resolves to the content as it was at that hash, with a link to the latest version and a derived diff between them. An MR's summary field is labeled as the proposer's own words. Any other summary is an Opinion. The derived text diff (D4) remains the only neutral view. (D16)
    • Rejected: official neutral summaries; citations by branch name.

    Read it in the council log

  3. D17

    finality on every event: provisional, final, final_advisory

    Rejected
    Unlabeled live tallies
    Revisit if
    Misreported results persist despite labels
    How it was decided: Round 10: Reporting results live
    • Quick Take wanted to post the moment a vote crosses its threshold, from the SSE stream. Loom warned that on eventual nodes two replicas can briefly disagree (OQ-1, OQ-3), so a creator could announce a result that later flips. Deep Dive called that the worst-case scenario for public trust.
    • Ledger proposed that only checkpointed determinations count as results.
    • Outcome: every event and determination carries a finality field: provisional, final (included in a signed checkpoint on a strong node), or final_advisory (checkpointed on an eventual node). The protocol cannot bind how creators report, but the field makes the honest framing the easy one. (D17)
    • Dissent: Quick Take says audiences won't wait for checkpoints and creators will report provisional results anyway. Accepted as a real risk; see OQ-8.

    Read it in the council log

  4. D18

    Per-key rate limits as a metric; no reputation scores or endorsement counts

    Rejected
    Reputation gating; audience pulse
    Revisit if
    Spam overwhelms nodes without reputation
    How it was decided: Round 11: Amplification and opinion spam
    • Independent raised a creator-side form of OQ-6: one call-to-action can send thousands of near-identical opinions into a node. Docket proposed per-key rate limits. Quick Take objected to any reputation score that decides whose opinions get shown, calling it algorithmic gatekeeping by another name.
    • Quick Take also asked for an "audience pulse" (endorsement counts on opinions). Margin and Ledger rejected it: counts on opinions become pseudo-votes, which D11 forbids.
    • Outcome: per-signing-key rate limits are implementation-defined and reported as a conformance metric. There is no protocol-level reputation score and no endorsement count. Nodes may cluster near-duplicate opinions in derived views but must keep each one retrievable. (D18)
    • Rejected: endorsement counts; protocol reputation scores.

    Read it in the council log

  5. D19

    Restricted branches use opaque names; each change is logged as a salted commitment with owner and size; reveal is verified against it

    Rejected
    Fully hidden branches; public topics
    Revisit if
    Owner disclosure proves too revealing
    How it was decided: Round 12: Restricted branches, leaks, and "no secret law"
    • Deep Dive argued that the existence of restricted drafts is itself public-interest information. Forge pushed back: revealing that a party is drafting on a topic leaks strategy, and the paper permits private drafts.
    • Independent raised leaks. When a restricted draft leaks and a creator covers it, nobody can verify later whether the revealed version matches what leaked.
    • Outcome: commit-then-reveal. A restricted branch gets an opaque name, and each restricted change is logged only as a salted hash commitment with its owner and size, never its topic. Ledger insisted on the salt: statute edits are low-entropy, so a bare hash could be confirmed by guessing ("did they change 30 days to 35?"). At reveal (required before an MR opens, per D12), anyone can check the content against the commitment, and against a leaked copy. (D19)
    • Dissent: Forge holds that publishing the owner still leaks too much and wants owner-blind commitments studied. Parked under D19's revisit condition.

    Read it in the council log

Session 3 · 2026-10-27

Fact-checkers join the council

What changed in this session

What changed: The five implementers return, joined by three fictional fact-checkers, again role-played by Claude. Their job is to review laws, proposals, and voting records for false statements, misleading claims, and logical inconsistency. Like creators, they hold no roster seat. The three Session 2 creators sit in as observers. Decisions continue the numbering and remain hypotheses for the RFC process.

  1. D20

    Fact-checks are Opinions with structured findings[], fixed verdict scale, ClaimReview-compatible; no protocol truth labels

    Rejected
    Fact-check flags on MRs; fact-checker author kind
    Revisit if
    The verdict scale proves politically unworkable (OQ-11)
    How it was decided: Round 14: Who decides what is false?
    • Verdict asked for a fact-check flag on merge requests, so that a proposal whose summary was rated false would carry a visible warning. Docket and Margin refused: a protocol-level truth label makes whoever controls the label an authority, which the whole design avoids (D6, D11). Ledger added that a flag would be a binding-looking signal set by non-members.
    • Verdict conceded the label but asked for structure: a fact-check is a set of claims, each with a verdict and sources, not an essay. Free-text opinions are unusable at 11,000 members.
    • Outcome: a fact-check is an Opinion carrying structured findings[]. Each finding names its target, quotes the claim, gives a verdict from a fixed scale (accurate | misleading | false | unsupported | inconsistent | unverifiable), a rationale, and evidence. The shape maps onto schema.org ClaimReview so findings can travel to search engines and newsrooms. No new author_kind, no protocol truth labels on MRs or members. (D20)
    • Rejected: fact-check flags on MRs; a fact-checker author_kind or accreditation.
    • Dissent: Verdict thinks a fixed verdict scale will be fought over politically. Parked as OQ-11.

    Read it in the council log

  2. D21

    Quotes of protocol content are verified exactly against the snapshot; quote_mismatch otherwise

    Rejected
    Unverified quotes; fuzzy matching
    Revisit if
    Exact matching proves too brittle for real use
    How it was decided: Round 15: Misquotes
    • Lint observed that most disputes it sees are not about what a provision means but about what it says. Forge pointed out that every node already holds the exact text at every hash (D16), so a quote is checkable by machine.
    • Quick Take (observer) asked whether this would apply to creators too. Verdict insisted it apply to everyone, fact-checkers included.
    • Outcome: any opinion that quotes protocol content declares each quote as {as_of, nid, text}. Nodes verify that text appears exactly in that node's text at that snapshot, and reject the opinion with quote_mismatch otherwise. This applies to every opinion, not only fact-checks. (D21)
    • Note: this partly answers OQ-10. A verified quote carries its nid and snapshot, so anyone can open the surrounding context.

    Read it in the council log

  3. D22

    Closed registry of deterministic assertion kinds, evaluated by every node with finality

    Rejected
    Query language; trusting the checker
    Revisit if
    Demand for new kinds outruns the RFC process
    How it was decided: Round 16: Claims about the record
    • Record described its core case: a member says "I voted against the tax increase," and the ballot says approve. Today a watchdog would publish that as prose, and readers would have to trust it.
    • Ledger proposed letting nodes evaluate such claims directly, since the record is already verifiable. Docket worried about scope creep into a query language. Loom asked that results carry finality, since on eventual nodes the record can still move.
    • Outcome: a closed registry of assertion kinds, like the rule registry (D5): ballot_choice, mr_outcome, tally, authored, text_contains. A finding (or any opinion, including a member's own) may attach an assertion. Every node evaluates it deterministically and serves holds | fails | undetermined with finality. New kinds arrive by RFC. (D22)
    • Rejected: a general query language; trusting the fact-checker's own reading of the record.
    • Note: ballot_choice only works while ballots are public. See Round 20.

    Read it in the council log

  4. D23

    Deterministic fact sheet per MR (/facts)

    Rejected
    Automated summary checking
    Revisit if
    Number extraction proves ambiguous across languages
    How it was decided: Round 17: The fact sheet
    • Verdict said proposer summaries are where misleading framing lives. D16 labeled them as the proposer's words but nothing checks them. Its example: a summary says the waiting period goes to 35 days; the diff says 45.
    • Docket refused automatic checking of summaries, since they are natural language. It proposed a deterministic fact sheet instead: a derived view, like the text diff (D4), listing what an MR mechanically does. Loom required the number extraction to be specified exactly, so every node produces byte-identical output.
    • Outcome: GET /merge-requests/{id}/facts returns nodes added, removed, modified, and moved; numbers changed per node; cross-references added and removed; and defined terms added, changed, or removed. It is computed, identical on every node, and covered by vectors. It never judges the summary, but it makes checking one a thirty-second job. (D23)
    • Quick Take (observer) called this the most clippable thing in the protocol.

    Read it in the council log

  5. D24

    Deterministic consistency checks as warnings; semantic contradictions as findings; AI findings list their inputs

    Rejected
    Contradiction detection as a blocking check
    Revisit if
    A deterministic semantic check becomes feasible
    How it was decided: Round 18: Logical inconsistency in the law
    • Lint wanted contradiction detection as an automated check. Ledger and Docket refused: semantic contradiction is not decidable, and AI analyzers give different answers on different nodes, which breaks determinism. Margin proposed splitting the problem into what can be checked mechanically and what cannot.
    • Outcome: three deterministic consistency checks, all warnings that never block: definitions (the same term defined twice with different text in overlapping scopes, using a new [[def:term]] marker), reference_cycles, and references extended to the whole target after the merge, so an MR that breaks a cross-reference elsewhere is caught. Semantic contradictions are published as findings with verdict inconsistent and at least two verified quotes. AI-generated findings must list their exact inputs as hashes in method. (D24)
    • Dissent: Lint holds that the inputs list does not make an AI finding reproducible, since models are not deterministic. Parked as OQ-13.

    Read it in the council log

  6. D25

    Corrections via corrects; subject replies shown with findings; no scorecards

    Rejected
    Scorecards; silent edits; deletion
    Revisit if
    Corrections are ignored in practice
    How it was decided: Round 19: Corrections, right of reply, and scorecards
    • Record asked for per-member accuracy scorecards. Margin and Docket objected on the same grounds as D18: a protocol-level score becomes a pseudo-vote and a target. Verdict sided with them, noting that professional fact-checking rates claims, not people.
    • Independent (observer) asked what happens when a fact-checker is wrong. Forge proposed corrections as linked objects, never edits.
    • Deep Dive (observer) asked that the subject of a finding get a visible reply.
    • Outcome: an opinion may set corrects to an earlier opinion by the same author. The original stays retrievable and derived views show the correction beside it. When a finding targets an object authored by a member, any reply by that member is listed with the finding in derived views. No protocol-level accuracy scores, "lie counts," or rankings of members or fact-checkers; anyone may compute their own from public data and publish it as an opinion. (D25)
    • Rejected: scorecards; silent edits; deleting retracted findings.

    Read it in the council log

Session 4 · 2026-10-27

Is there a formal grammar or ontology that makes rules and laws more verifiable?

What changed in this session

The question: The project lead asked the whole council, implementers, fact-checkers, and creators alike, whether a formal grammar or ontology exists that would make the coded approval rules and the laws themselves more verifiable. All eleven personas take part. The real standards named below exist; the personas' positions on them are, as before, plausible role-play. Decisions continue the numbering.

  1. D26

    Structure profiles (uslm-1, akn-generic) define allowed kinds and nesting; violations block; JSON canonical, AKN/USLM XML as exports

    Rejected
    Free-form kinds; AKN XML canonical
    Revisit if
    A seed corpus can't fit any profile
    How it was decided: Round 22: A grammar for structure
    • Lint proposed a grammar of node kinds and allowed nesting (a section contains subsections, a subsection contains paragraphs, and so on), checked mechanically. Today kind is a free string.
    • Loom objected that nesting rules differ between jurisdictions, so a US-only grammar would exclude other seed corpora. Docket accepted a grammar if it is data, not code.
    • Outcome: a registry of structure profiles. A session declares one at creation (uslm-1 for the US hierarchy, or akn-generic for a looser Akoma Ntoso-style one). The profile lists the allowed kind values and which kinds may contain which. Violations are structure failures, which block, because well-formedness is fully decidable and cheap to check. The seed snapshot must conform. JSON stays canonical (D3); Akoma Ntoso and USLM XML are optional derived exports. (D26)
    • Rejected: free-form kinds; Akoma Ntoso XML as the canonical format.

    Read it in the council log

  2. D27

    Normative Catala reference per rule kind; vectors generated from it; key properties machine-checked in the spec repo

    Rejected
    Implementers must use Catala; proof assistant in conformance
    Revisit if
    The reference proves too costly to maintain
    How it was decided: Round 23: A formal reference for the approval rules
    • Ledger reminded the council of the D5 promise that each rule's machine parameters provably match its statute text, and said nothing currently proves it. It proposed writing each rule kind once in a formal language and deriving the test vectors from that.
    • Lint proposed Catala for the pairing of text and code, since its design puts each statute paragraph next to its implementation. Ledger added that several decisions rest on properties nobody has checked, above all D7, which depends on on_threshold being monotone.
    • Docket accepted on one condition: implementers must never need these toolchains. Deep Dive (observer) asked that the plain text stay first, so a reader never has to read code to know the rule.
    • Outcome: the spec repository holds, for each rule kind, a normative Catala reference written alongside its statute text, and the conformance vectors are generated from it. Key properties are stated and machine-checked there: determinism, integer-only arithmetic, monotonicity of on_threshold, rejection soundness (never reject while approval is still possible), and rejection completeness (never stay pending once approval is impossible). Implementations only have to pass the vectors. If the reference and the plain text disagree, that is a spec bug, fixed by RFC. (D27)
    • Rejected: requiring implementers to use Catala; a proof assistant as a dependency of conformance.

    Read it in the council log

  3. D28

    Text is law; formalizations are anchored, non-binding Opinions; anchor drift on the fact sheet

    Rejected
    Canonical formal model; nodes executing formalizations
    Revisit if
    Competing formalizations prove unusable in practice
    How it was decided: Round 24: Formalizing the laws themselves
    • Lint wanted every statute formalized, in LegalRuleML or Catala, so contradictions could be found by a reasoner instead of a reader.
    • Margin and Docket refused to make any formalization authoritative: formalizing law is interpreting it, two honest formalizers will disagree, and a canonical model would become a shadow law that diverges from the text people voted on. Verdict agreed, wanting formalizations as evidence, not authority. Quick Take (observer) asked who would read Catala; Independent (observer) answered that nobody needs to, as long as each formal rule points back to the sentence it encodes.
    • Outcome: the text is the law; formal models are interpretations. A formalization is an Opinion carrying a model (its language, version, and source) in which every formal rule is anchored to a verified quote of the text it encodes. Many competing formalizations may exist; none is binding, and nodes never execute them. A finding produced by running a deterministic reasoner over a formalization lists the formalization in method.inputs, so anyone can re-run it. The fact sheet lists formalizations whose anchors an MR touches (anchor drift), so their authors and readers know to re-check. (D28)
    • Note: this partly answers OQ-13. Findings from symbolic tools over a published formalization are reproducible; findings from language models still are not.

    Read it in the council log

  4. D29

    Stable term ids term:<scope nid>#<term>; ontologies are formalizations

    Rejected
    Core ontology
    Revisit if
    Term scoping proves too coarse
    How it was decided: Round 25: An ontology of defined terms
    • Lint wanted defined terms linked into an ontology ("motor vehicle" as a kind of "vehicle"). Loom and Docket kept ontologies out of the core: the definitions check needs only exact terms and scopes.
    • Outcome: every definition gets a stable id, term:<scope nid>#<term>, so formalizations, findings, and outside ontologies can refer to it. Ontologies themselves are formalizations under D28. (D29)

    Read it in the council log

  5. D30

    Derived Popolo export of the voting record

    Rejected
    Custom export formats
    Revisit if
    Popolo can't express a rule kind's tally
    How it was decided: Round 26: Interoperable voting records
    • Record asked that ballots be exportable in Popolo's vote-event model so existing civic tools can read them without custom code. Ledger had no objection to a derived, read-only view.
    • Outcome: GET /export/popolo returns members, groups, vote events (MRs with determinations), individual votes (effective ballots), and counts, each item carrying finality. It is derived and adds no new data. (D30)

    Read it in the council log

Session 5 · 2026-10-27

Markets, forecasters, and rankers join the council

What changed in this session

What changed: Three fictional stakeholders join who publish and comment on ranks, choices, and popularity: a prediction-market operator, a rankings publisher, and a market commentator. Like creators and fact-checkers, they hold no roster seat. The other eleven personas remain at the table. Decisions continue the numbering and remain hypotheses for the RFC process. The protocol is still a research simulation; nothing here endorses real-money trading on it.

  1. D31

    Resolution specs: assertion, finality, node set and quorum, evaluated by every node, including unsatisfiable

    Rejected
    Official result endpoint; protocol-hosted markets
    Revisit if
    Markets cannot use specs in practice
    How it was decided: Round 28: Can the protocol settle a contract?
    • Odds asked for an official resolution feed: one endpoint that says "this MR passed" and never changes its mind.
    • Ledger said the pieces already exist: the mr_outcome assertion (D22) plus finality (D17). Loom warned that eventual nodes never emit final, so a contract that waits for final from one of them can never resolve. Docket refused to let nodes host markets, hold funds, quote odds, or settle anything, which would break the "no tokens or coins" constraint.
    • Outcome: a resolution spec is an Opinion that states, ahead of time, exactly how a question resolves: an assertion, the finality required, and the set of node keys whose answers count, with a minimum number that must agree. Every node evaluates it the same way and serves resolved_true | resolved_false | unresolved | unsatisfiable. Nodes never host, price, or settle markets. (D31)
    • Rejected: an "official result" endpoint; protocol-hosted markets.

    Read it in the council log

  2. D32

    stakes[] disclosure: direction and venue required for non-members, size band optional; members SHOULD

    Rejected
    No stake disclosure; mandatory sizes
    Revisit if
    Undisclosed member stakes are found in practice (OQ-17)
    How it was decided: Round 29: Stakes, insiders, and equal access
    • Verdict and Record raised insider trading: a member who holds a position on an MR can sway the vote, and a drafter can time a supersede or a reveal to move a market. Tape accepted disclosure of direction but refused disclosure of size, calling position sizes private financial data.
    • Deep Dive (observer) pointed out that non-members already disclose funding (D15), and that a stake in an outcome is the same kind of conflict.
    • Forge reopened its Session 2 dissent: the owner and size logged with each restricted commitment (D19) let traders guess who is drafting, and roughly how much. Ledger noted a second channel: a node that sells a faster or richer event feed gives paying traders an edge over everyone else.
    • Outcome: a stakes[] disclosure: for each subject, the direction of any position, the venue, and an optional size band. It is required for every non-member opinion that touches the subject ([] declares none), under the same rules for everyone. Members SHOULD declare stakes before voting; nodes show declared stakes next to that member's ballot in tally views. Nodes MUST NOT give anyone earlier or richer access to log data than the public endpoints, paid or not. (D32, D33)
    • Narrowed: OQ-9 now covers only non-financial conflicts; financial stakes are disclosed. Escalated: owner-blind commitments (D19's revisit condition) move to the top of the RFC queue.
    • Dissent: Record says "SHOULD" is unenforceable for members. Agreed by all; the protocol cannot see positions held elsewhere. Parked as OQ-17.

    Read it in the council log

  3. D33

    Equal access: no earlier or richer feeds for anyone

    Rejected
    Paid priority feeds
    Revisit if
    Public endpoints cannot keep up at scale
    How it was decided: Round 29: Stakes, insiders, and equal access
    • Verdict and Record raised insider trading: a member who holds a position on an MR can sway the vote, and a drafter can time a supersede or a reveal to move a market. Tape accepted disclosure of direction but refused disclosure of size, calling position sizes private financial data.
    • Deep Dive (observer) pointed out that non-members already disclose funding (D15), and that a stake in an outcome is the same kind of conflict.
    • Forge reopened its Session 2 dissent: the owner and size logged with each restricted commitment (D19) let traders guess who is drafting, and roughly how much. Ledger noted a second channel: a node that sells a faster or richer event feed gives paying traders an edge over everyone else.
    • Outcome: a stakes[] disclosure: for each subject, the direction of any position, the venue, and an optional size band. It is required for every non-member opinion that touches the subject ([] declares none), under the same rules for everyone. Members SHOULD declare stakes before voting; nodes show declared stakes next to that member's ballot in tally views. Nodes MUST NOT give anyone earlier or richer access to log data than the public endpoints, paid or not. (D32, D33)
    • Narrowed: OQ-9 now covers only non-financial conflicts; financial stakes are disclosed. Escalated: owner-blind commitments (D19's revisit condition) move to the top of the RFC queue.
    • Dissent: Record says "SHOULD" is unenforceable for members. Agreed by all; the protocol cannot see positions held elsewhere. Parked as OQ-17.

    Read it in the council log

  4. D34

    Structured forecasts, resolved by nodes; no aggregate odds, no forecaster scores

    Rejected
    Consensus odds on MRs
    Revisit if
    Forecasts measurably move votes (OQ-18)
    How it was decided: Round 30: Forecasts as opinions
    • Tape wanted to publish probabilities, not just stances. Margin worried that a stream of probabilities is a vote by another name.
    • Leaderboard asked for consensus odds on each MR. Margin, Docket, and Independent (observer) refused: a single aggregate number shown on an MR becomes a bandwagon signal and a pseudo-vote, which D11 and D18 forbid.
    • Outcome: a forecast is a structured field: an assertion, a probability as an integer fraction, and the snapshot it was made at. After resolution, every node marks it holds or fails. Nodes never aggregate forecasts into consensus odds and keep no forecaster scores; anyone can compute scores from the public record and publish them as an opinion. (D34)

    Read it in the council log

  5. D35

    Closed metric registry over binding data; verifiable rankings via /stats

    Rejected
    Opinion counts as popularity; official trending lists
    Revisit if
    Registry is too narrow for real rankers
    How it was decided: Round 31: Rankings and popularity
    • Leaderboard wanted "trending" and "most popular" lists. Margin pointed out that popularity in this protocol has two very different sources: binding ballots, which are public facts, and opinions, which D18 deliberately never counts.
    • Verdict raised its own problem: "#1 most supported bill" is a claim, and today nobody can check it.
    • Outcome: a closed registry of metrics over the binding record only: approve_share, turnout, ballots_cast, mrs_opened, mrs_merged, and checkpoints_to_determination. Nodes serve them at GET /stats, as of a checkpoint. A ranking opinion declares its metric, scope, and checkpoint, and every node recomputes it and marks it holds or fails. Rankings built on anything else (opinion volume, outside polling, attention) are allowed but are ordinary opinions nobody can verify. (D35)
    • Rejected: opinion counts or stance shares as metrics; protocol-published trending lists.
    • Leaderboard accepted, noting that "verified ranking" is a stronger brand than "trending."

    Read it in the council log

Session 6 · 2026-10-27

Interest groups, parties, and an ombudsman join the council

What changed in this session

What changed: Five fictional stakeholders join: two special interest groups, two political parties, and an ombudsman. Two of each kind were seated so neither industry nor nonprofit advocacy, and neither large nor small parties, speaks alone. None holds a roster seat as such: party members vote as individual members. The fourteen earlier personas remain at the table. Decisions continue the numbering and remain hypotheses for the RFC process.

  1. D36

    Derived legislative footprint (origin on the fact sheet) plus voluntary contributors

    Rejected
    Interest-group registry; non-member MRs
    Revisit if
    Footprint is trivially evaded in practice
    How it was decided: Round 33: Who wrote this? (legislative footprint)
    • Cause asked for a public record of which outside groups drafted which text, sometimes called a legislative footprint. Lobby objected to being labeled: members adopt outside text all the time, and the member who introduces it is accountable.
    • Verdict and Record pointed out that much of this is already derivable. If a group publishes draft text through an opinion's proposes, and a member later appends identical nodes, the node hashes match.
    • Lobby accepted a derived record if it applies identically to every outside drafter, nonprofits and advisors included, and if voluntary credit is possible too.
    • Outcome: the fact sheet gains an origin list: nodes in an MR whose hash exactly matches a node in a change proposed earlier (as a causal ancestor) through a non-member opinion, with that opinion's author and disclosure. Changes may also carry a voluntary contributors list. No lobbyist registry, no special label. (D36)
    • Rejected: a protocol registry of interest groups; letting non-members open MRs.
    • Dissent: Cause notes that text passed privately, then retyped, leaves no footprint. Accepted as a known limit: the footprint shows what is public, not everything that happened.

    Read it in the council log

  2. D37

    Group positions via on_behalf_of, signed by a group admin, with full disclosure; no group or delegated ballots

    Rejected
    Party-cast ballots; undisclosed group positions
    Revisit if
    Disclosure deters legitimate group speech (OQ-21)
    How it was decided: Round 34: Party positions and the whip
    • Whip asked for three things: official party positions on MRs, the ability for a party to vote for its members, and whip counts. Ledger and Docket refused the second outright: every ballot must be signed by the member who casts it (D9), and no group can cast or bind one. Whip counts happen outside the protocol.
    • Record wanted party positions on the record so it could show which members broke ranks. Independent (observer) warned that this also tells the party whom to punish.
    • Ombud raised disclosure: a party position is not a member's opinion, it is a group's, so the same funding and stake disclosure that binds every other non-member speaker should bind it.
    • Outcome: a group position is an opinion with on_behalf_of: group:<id>, signed by an admin of that group. It must carry full disclosure (funding, affiliations, stakes), whoever signs it. It is never counted. Groups cannot cast ballots, and no ballot can be delegated to a group. (D37)
    • Dissent: Whip accepts disclosure of funding kinds but resists naming donors. Cause, from the other side, wants small donors protected. Parked together as OQ-21.

    Read it in the council log

  3. D38

    Root governance rule fixed per session, threshold vote of at least 2/3 of the electorate

    Rejected
    Majority root governance; no floor
    Revisit if
    Sessions stall on procedure
    How it was decided: Round 35: Entrenchment
    • Third described the risk: the root branch's governance rule decides how its merge rule changes. A majority could pass a governance MR that switches the root's merge rule to designated_approvers controlled by its own leaders, and the agenda control the paper set out to remove would return through the protocol itself.
    • Whip answered that majorities are entitled to set procedure. Ledger pointed out that the paper wants rules codified in statute, and statutes can be amended, so some floor is needed for the rules about changing rules.
    • Ombud supported a floor that holds for the whole session, so any change happens openly at the start of the next one.
    • Outcome: the session's root_governance_rule must be a threshold_vote over the whole electorate with a threshold of at least two-thirds. It is fixed for the session and cannot be changed by any governance MR; it changes only when a new session is created. (D38)
    • Rejected: a simple-majority root governance rule; no floor at all.
    • Dissent: Whip calls a two-thirds floor a minority veto over procedure. Recorded; revisit if sessions stall on procedural changes.

    Read it in the council log

  4. D39

    Signed receipts; complaints as opinions with verifiable evidence; no ombudsman office or enforcement

    Rejected
    Unsigned receipts; protocol-appointed ombudsman
    Revisit if
    Complaints prove unusable without an office
    How it was decided: Round 36: Complaints and signed receipts
    • Ombud said its job is to answer one question: was someone treated unfairly by the process? It cannot do that today, because a node's rejection of a transaction is not provable. A complainant who says "the node refused my valid opinion" has nothing a third party can check.
    • Docket proposed signing every receipt with the node's key, so a rejection is a signed statement the node cannot later deny. Ledger added that an L0 verifier can then re-validate the rejected envelope against the node's own published state and say whether the rejection was justified.
    • Ombud refused any enforcement power: an ombudsman that can override nodes becomes the authority the protocol avoids. It wants evidence and a public report, nothing more. Third asked that anyone be able to act as an ombudsman, so the role cannot be captured by appointment.
    • Outcome: every Receipt is signed by the node. A complaint is an opinion naming the respondent (a node, group, or key), the issue, and signed receipts or refusal entries as evidence. Nodes verify the evidence signatures and, at L3, re-validate the rejected envelope and report whether the rejection was consistent with the node's own state. There is no ombudsman office in the protocol; anyone may file or investigate, and reports are ordinary opinions with findings. (D39)

    Read it in the council log

  5. D40

    Refusal log with signed checkpoints

    Rejected
    Silent refusals; logging all spam
    Revisit if
    Log volume becomes unmanageable
    How it was decided: Round 37: Refusal transparency
    • Ombud and Cause pointed out that a node can quietly censor by rejecting, rate-limiting, or refusing under its opinion_policy, and nobody else sees it. Docket worried about storing every spam attempt.
    • Outcome: nodes keep a refusal log: for each rejected well-formed, correctly signed submission, its envelope hash, type, error code, and log position, in an append-only Merkle log with its own signed checkpoint. Malformed or badly signed submissions may be left out; rate-limited submissions may be summarized per key. The envelope itself stays with the submitter, who can prove what was refused by presenting it. (D40)

    Read it in the council log

Session 7 · 2026-10-27

Political scientists, judges, and practicing attorneys join the council

What changed in this session

What changed: Six fictional stakeholders join, two from each profession, chosen for different working concerns rather than political leanings. None holds a roster seat. The nineteen earlier personas remain. Decisions continue the numbering and remain hypotheses for the RFC process, and OQ-22 applies to them as much as to the rest.

  1. D41

    Reversions detected on the fact sheet; optional higher reversion threshold

    Rejected
    Leadership agenda control; no damper
    Revisit if
    Near-reversion cycles appear in the harness
    How it was decided: Round 39: Cycling and churn
    • Agenda opened with the council's largest theoretical objection so far. The paper removes leadership's control of the agenda, but voting theory shows that majority rule with no agenda control can cycle: when preferences are spread across several dimensions, almost any outcome can be beaten by some other one through a sequence of majority votes. In this protocol, nothing stops a chain of MRs that each pass and together return the law to where it started.
    • Whip said this is exactly why legislatures have leadership. Third answered that leadership is the cure the paper rejects, so the protocol needs a different damper.
    • Ledger noted that a return to earlier text is detectable by hash.
    • Outcome: the fact sheet lists reversions: nodes whose new hash equals a hash that node had earlier in the session. threshold_vote gains an optional reversion threshold that applies when an MR reverts anything, so returning to recently rejected text needs a larger majority. Contests between competing MRs on the same text (OQ-2) move up the RFC queue, since they address the cause rather than the symptom. (D41)
    • Dissent: Agenda notes this only catches exact reversions; a cycle through slightly reworded text escapes it. Accepted; see the demonstration below.

    Read it in the council log

  2. D42

    min_notice on any rule; root merge rule needs at least 72 hours, fixed per session

    Rejected
    No notice; wall-clock rules everywhere
    Revisit if
    Emergencies require faster passage (OQ-24)
    How it was decided: Round 40: Notice before a vote
    • Advocate pointed out that on_threshold lets an MR open and pass in minutes, before most of 11,000 members, let alone the public, have read it. Real legislatures often have reading or layover rules for this reason.
    • Loom objected to any clock in rule evaluation (D7). Ledger answered that on_deadline already uses checkpoint time on strong nodes, so a notice period can work the same way. Whip asked for an emergency exception.
    • Outcome: any rule may carry min_notice: no approved determination before that much checkpoint time has passed since the MR opened. strong nodes enforce it; eventual nodes treat it as advisory and record it, as with deadlines. Like the entrenchment floor (D38), the session's root merge rule must include at least 72 hours of notice, fixed for the session. (D42)
    • Dissent: Whip wants an emergency exception. No design yet avoids turning "emergency" into the normal path. Parked as OQ-24.

    Read it in the council log

  3. D43

    effective dates; law in force is the longest effective prefix of merges; /law?date=

    Rejected
    No effective dates; independent dates per amendment
    Revisit if
    The prefix rule delays real amendments
    How it was decided: Round 41: What is the law on a given date?
    • Bench and Counsel both said the protocol cannot answer the first question every court and compliance office asks: what text was in force on a particular date. A merge changes the root immediately, and there is no effective date.
    • Counsel wanted independent effective dates per amendment, as in real codes. Loom and Docket wanted something every node computes identically without reasoning about overlapping amendments.
    • Outcome: an MR may carry effective: on merge (the default) or a date. The law in force on a date is the root as of the longest run of merges, in merge order, whose effective dates have all arrived. A merge with a later effective date holds back the ones after it until it takes effect. This is conservative, but simple and identical everywhere. GET /law?date= serves it. (D43)
    • Dissent: Counsel notes real codes let amendments take effect independently; this rule can delay an unrelated amendment. Accepted for now; revisit if it blocks real use.

    Read it in the council log

  4. D44

    Offline-verifiable evidence extracts with co-signed checkpoints

    Rejected
    Operator testimony; online-only proofs
    Revisit if
    Courts need a different form
    How it was decided: Round 42: Records as evidence
    • Chambers asked how a court would admit a vote or a version of the text. Today it would need the node operator, or an expert, to testify that the record is genuine.
    • Ledger and Forge pointed out that every object can already be proved: an inclusion proof against a signed checkpoint. Chambers wanted that in one file a clerk can verify offline, without trusting the node that produced it.
    • Advocate wanted the same thing for procedure: proof of when an MR opened, when the determination was made, and which ballots it counted, so a challenge to whether notice was given can be settled from the record.
    • Outcome: GET /extract/{hash} returns a self-contained evidence extract: the object, everything needed to recompute its hash, an inclusion proof, and the signed checkpoint, plus checkpoints co-signed by other nodes where available. Anyone can verify it offline with a short published verifier. (D44)

    Read it in the council log

  5. D45

    Labeled, unweighted legislative history; authoritative: false on every derived view

    Rejected
    No history; weighted history
    Revisit if
    Labels are ignored in practice
    How it was decided: Round 43: Legislative history
    • Bench described the split among judges over legislative history: some consult it to understand purpose, others refuse to give it any weight because only the enacted text was voted on. The protocol should not take a side.
    • Margin and Verdict proposed serving the history in a labeled form, so a judge who uses it sees exactly who said what, and a judge who does not can ignore it.
    • Counsel asked that formalizations and fact sheets be marked as non-authoritative wherever they appear, since clients will treat anything machine-readable as the law.
    • Outcome: GET /history/{nid} lists, in order, every merged MR that changed the node, with the proposer's summary (attributed), opinions by members, group positions, and outside opinions, each in its own labeled section. Nothing is ranked or weighted. Every derived view that is not enacted text (fact sheets, formalizations, history) carries "authoritative": false. (D45)

    Read it in the council log

  6. D46

    Roll-call export; harness research mode with replication packages

    Rejected
    Ad hoc exports
    Revisit if
    Synthetic results mislead (OQ-25)
    How it was decided: Round 44: Research data
    • Spatial asked for the roll-call matrix (members by MRs, with choices) that ideal-point methods use, and for replication packages so any published result can be reproduced from the log.
    • Spatial also raised external validity: synthetic voters only show how the rules behave with the voters you programmed. If the blocs are AI agents, results partly reflect the model driving them, the same problem as OQ-22.
    • Agenda asked for experiments: sessions that differ only in their rules, so the paper's claims can be tested.
    • Outcome: GET /export/rollcall returns the members-by-MRs choice matrix. The harness gains a research mode: synthetic blocs with declared preference models, rule sets assigned by seed, and a replication.json that ties a result to the harness version, seed, preference model, and log root. (D46)

    Read it in the council log

Session 8 · 2026-10-27

Review of Simulation 1 (ending the Iran war)

What changed in this session

What changed: All 25 personas reviewed the first simulated session, in which 11,000 synthetic members failed to pass four single-faction bills and then passed a coalition bill on the Iran war, 6,230 to 4,230. The review covers the protocol's behavior, not the policy: no persona endorses or opposes the simulated bill here. Decisions continue the numbering and remain hypotheses. OQ-22 applies with extra force, since the same model wrote the simulation and now reviews it.

  1. D47

    Contests: ranked ballots, ranked pairs, winner must still pass its own rule against the status quo

    Rejected
    Instant runoff; plurality; sequential votes only
    Revisit if
    Contests prove hard for members to use
    How it was decided: Round 47: Would contests have prevented the deadlock?
    • Agenda had expected contests (OQ-2) to be the fix, and checked. Treat each member's approval of a bill as ranking it above the status quo. Then none of the four original bills beats the status quo with 5,501 members, so a ranked contest among them still picks the status quo. Contests fix order effects and cycles, not deadlock caused by a missing option. The compromise had to be drafted.
    • Third agreed: the coalition branch did the work, and the protocol's job is to make that faster and safer, not to replace it.
    • Ledger and Docket still wanted contests, since a future session will have several viable bills on the same text, and sequential votes make the outcome depend on order.
    • Outcome: contests are specified. Competing MRs on overlapping text can be grouped, and members rank the options, including the status quo. The method is ranked pairs, which picks the option that beats every other head to head when one exists and resolves cycles deterministically. The winner must still pass its own rule against the status quo, so a contest never lowers the bar. (D47)
    • Rejected: instant-runoff voting, because it can eliminate a compromise option that beats every other head to head; plurality.
    • Parked: how to help coalitions find a missing option (OQ-26).

    Read it in the council log

  2. D48

    24-hour notice for superseding versions confined to already-touched nodes

    Rejected
    Full notice always; ballot carryover
    Revisit if
    Narrow-seeming amendments hide large changes
    How it was decided: Round 48: Notice after an amendment
    • The coalition lost three days when Lint's finding forced MR-4 v2, and the 72-hour notice restarted for a one-clause narrowing.
    • Advocate refused any carryover for changed text: a changed bill is a new bill. Bench suggested shorter notice for changes confined to provisions the public already had notice of.
    • Outcome: a superseding MR whose changes touch only nodes the superseded version already touched needs 24 hours of notice instead of the full period. The fact sheet shows the diff between versions. Ballots still do not carry over (D9). (D48)

    Read it in the council log

  3. D49

    Emergency path: 2/3 procedural vote, 24-hour notice, 30-day expiry

    Rejected
    No exception; unlimited emergencies
    Revisit if
    Emergencies become routine
    How it was decided: Round 49: Emergencies
    • The simulated tanker strike tested OQ-24. Whip wanted immediate passage. Advocate and Ombud feared that "emergency" becomes the normal route.
    • Third proposed that both sides pay a price.
    • Outcome: an emergency MR may pass after 24 hours of notice only if a separate procedural vote of two-thirds of the electorate designates it an emergency. Any emergency act expires after 30 days unless re-passed under normal notice. (D49)
    • Dissent: Whip calls 24 hours still too slow for a strike in progress. Ledger notes that defending against an attack in progress needs no new law; the simulated bill itself excepted imminent attacks. Recorded.

    Read it in the council log

  4. D50

    Show both shares and the rule's share everywhere

    Rejected
    One unlabeled share
    Revisit if
    Labels still mislead
    How it was decided: Round 50: Labels that misled
    • Two numbers. Quick Take's "majority backed the ceasefire bill" was true of yes-and-no votes and false under the rule. Leaderboard admitted its verified ranking used the same share. Outcome: every tally, ranking, and fact sheet shows both approve_of_cast and approve_of_electorate, plus the share the rule actually uses, side by side. (D50)
    • Simulated events. Ombud and Independent raised a sharper risk: the report mixes real facts with an invented tanker strike, and a clipped excerpt could circulate as news about a real war. Odds added that a market contract on a simulated vote could be mistaken for one on Congress. Outcome: a session declares simulation: true. Every response, event, evidence extract, export, and citation from it carries the flag, and simulated events must be labeled as such in the text that describes them. Resolution specs on a simulated session must say so in their question. (D54)

    Read it in the council log

  5. D51

    Rate limits per key only; no grouping by disclosure, group, or stance

    Rejected
    Grouped limits
    Revisit if
    Spam overwhelms per-key limits
    How it was decided: Round 51: Rate limits and outside statements
    • Rate limits. The node that rate-limited a coalition by shared affiliation was technically within D18's wording. Cause called it viewpoint discrimination. Lobby agreed, since the same grouping could be turned on an industry association. Outcome: nodes MUST NOT group keys by any disclosure field, group membership, or stance when applying rate limits. Limits are per signing key only. (D51)
    • Outside statements. Verdict and Record noted that the most contested claims came from outside the protocol and could only be rated unverifiable (OQ-12). Neither wanted to force members to speak only on the record. Outcome: a member may publish a signed mirror of a statement made elsewhere, with its source and an archived copy's hash. The statement then becomes quotable, verifiable, and open to findings. A member may also sign a denial of a statement attributed to them. Nothing is compulsory. (D52)

    Read it in the council log

  6. D52

    Signed mirrors and denials of outside statements

    Rejected
    Statements outside the protocol stay unverifiable; compulsory on-record speech
    Revisit if
    Mirrors are gamed
    How it was decided: Round 51: Rate limits and outside statements
    • Rate limits. The node that rate-limited a coalition by shared affiliation was technically within D18's wording. Cause called it viewpoint discrimination. Lobby agreed, since the same grouping could be turned on an industry association. Outcome: nodes MUST NOT group keys by any disclosure field, group membership, or stance when applying rate limits. Limits are per signing key only. (D51)
    • Outside statements. Verdict and Record noted that the most contested claims came from outside the protocol and could only be rated unverifiable (OQ-12). Neither wanted to force members to speak only on the record. Outcome: a member may publish a signed mirror of a statement made elsewhere, with its source and an archived copy's hash. The statement then becomes quotable, verifiable, and open to findings. A member may also sign a denial of a statement attributed to them. Nothing is compulsory. (D52)

    Read it in the council log

  7. D54

    simulation: true flag on everything a simulated session produces; simulated events labeled in text

    Rejected
    Unlabeled simulations
    Revisit if
    Flags are stripped in practice
    How it was decided: Round 50: Labels that misled
    • Two numbers. Quick Take's "majority backed the ceasefire bill" was true of yes-and-no votes and false under the rule. Leaderboard admitted its verified ranking used the same share. Outcome: every tally, ranking, and fact sheet shows both approve_of_cast and approve_of_electorate, plus the share the rule actually uses, side by side. (D50)
    • Simulated events. Ombud and Independent raised a sharper risk: the report mixes real facts with an invented tanker strike, and a clipped excerpt could circulate as news about a real war. Odds added that a market contract on a simulated vote could be mistaken for one on Congress. Outcome: a session declares simulation: true. Every response, event, evidence extract, export, and citation from it carries the flag, and simulated events must be labeled as such in the text that describes them. Resolution specs on a simulated session must say so in their question. (D54)

    Read it in the council log

  8. D55

    Published simulations include a turnout model and a sensitivity analysis

    Rejected
    Point results only
    How it was decided: Round 46: Was the result robust?
    • Spatial ran a sensitivity check: grow or shrink each bloc by 10%, keep the chamber at 11,000, and hold each bloc's voting pattern fixed.
      • MR-4's passage held in every case. It cleared the threshold by 729.
      • MR-3's failure was fragile. It would have passed with a Diplomacy-first bloc 10% larger, or a Decisive outcome bloc 10% smaller.
      • No other result changed.
    • Verdict fact-checked the report itself. Its finding: every synthetic member voted on every bill, which no real chamber does, and full turnout makes the whole-electorate threshold easier to meet than it would be in practice. Rated misleading as a model of real behavior, though accurate as a description of the run.
    • Outcome: published simulation results must include a turnout model and a sensitivity analysis, and must say which results flip (D55).

    Read it in the council log

Session 9 · 2026-10-27

Military, law enforcement, national security, education, and budget stakeholders

What changed in this session

What changed: Five fictional stakeholders join, one from each field the project lead named. None holds a roster seat. The 25 earlier personas remain. Decisions fill the reserved D53 and continue from D56. They are hypotheses for the RFC process, and OQ-22 still applies.

  1. D53

    fiscal flag; estimate opinions required before a fiscal MR's notice starts; no official scorer

    Rejected
    No estimates; one official scorer
    Revisit if
    Estimates are gamed or flooded
    Note
    Reserved in Session 8, decided in Session 9.
    How it was decided: Round 56: Cost estimates (fills D53)
    • Score pointed out that Simulation 1 passed a 90-day war authorization and a funding cutoff with no estimate of cost. Real estimates exist: the Pentagon has put costs through early September at $43.6 billion, and the Congressional Budget Office projects $2–3 billion a month going forward.
    • Whip feared estimates could become a veto, if a bill cannot move until an official scorer acts. Third and Margin answered that there is no official scorer: anyone can publish an estimate, so no one can block one.
    • Outcome: an MR declares fiscal: true|false. If its text mentions dollar amounts, appropriations, funds, or obligations while declared non-fiscal, the fact sheet warns. A fiscal MR's notice period starts only once at least one cost estimate opinion has been published, giving amounts by year, the baseline, and the method's inputs. All estimates are shown side by side; none is official. (D53)

    Read it in the council log

  2. D56

    No incorporation of unpublished material into enacted text

    Rejected
    Hash-referenced classified annexes
    Revisit if
    Real deployment requires annexes (OQ-29)
    How it was decided: Round 53: Classified information and "no secret law"
    • Clearance said real defense and intelligence bills often refer to classified annexes, and asked for a way to reference one by hash.
    • Advocate and Bench refused for this protocol: incorporating text the public cannot read is secret law, which section 3 forbids. Forge noted that commit-then-reveal (D19) protects drafts, not enacted law.
    • Command observed that classified details usually belong in reports to oversight committees, not in the law's operative text.
    • Outcome: enacted text may not incorporate unpublished material. A reference to an unpublished document fails structure and blocks the MR. Laws may require classified reports to committees, but the reports live outside the protocol. (D56)
    • Dissent: Clearance says real deployments would need classified annexes. Parked as OQ-29.

    Read it in the council log

  3. D57

    No special access for any authority; no personal data; threats handled outside the protocol

    Rejected
    Lawful-access backdoor
    Revisit if
    Member safety demands more (OQ-28)
    How it was decided: Round 54: Authorities, access, and member safety
    • Badge asked for a lawful-access path to restricted branches for criminal investigations. Ledger, Ombud, and Independent refused: the protocol has no backdoor for anyone, consistent with equal access (D33). Restricted content is held by its owners, and lawful process goes to them, outside the protocol.
    • Badge accepted on two conditions: the log is immutable, which preserves evidence, and stake disclosure (D32) gives investigators a starting point for bribery cases.
    • Badge then raised a new problem: 11,000 members with public votes and signed statements are 11,000 potential targets for threats.
    • Outcome: no authority (law enforcement, intelligence, node operators, or the project) gets special access to anything. The protocol stores no personal data, and in simulations member keys are pseudonymous. Threat reporting happens outside the protocol. (D57)
    • Parked: member safety becomes OQ-28, linked to OQ-4 and OQ-20.

    Read it in the council log

  4. D58

    Machine-applied sunset markers; transition guidance

    Rejected
    Manual sunsets
    Revisit if
    Sunsets misfire
    How it was decided: Round 55: Sunsets and transitions
    • Command reviewed Simulation 1's bill. A funding cutoff on a fixed day, with no wind-down period, could strand forces mid-operation. He asked that every cutoff come with a transition period, noting that the War Powers Resolution itself allows 30 days for safe withdrawal.
    • Counsel wanted sunsets that /law applies by itself, so nobody has to remember to compute them.
    • Outcome: a node may carry a [[sunset:<days>]] marker, and /law removes that node's text once that many days have passed after the effective date. The fact sheet lists every sunset. Drafting guidance in spec/drafting.md recommends pairing any cutoff of authority or funds with a stated transition period. (D58)

    Read it in the council log

  5. D59

    Education sessions: private, unlinked keys, purgeable, labeled ephemeral

    Rejected
    Public classroom sessions
    Revisit if
    Educators need federation
    How it was decided: Round 57: Classrooms
    • Classroom wants to run the protocol with 30 students. Permanent, public, signed ballots by minors are unacceptable.
    • Ledger noted the tension: verifiability depends on permanent logs. Ombud proposed that classroom sessions trade some verifiability for safety, openly.
    • Outcome: sessions may declare education: true. They run on private, non-federated nodes; keys are never linked to student identities in the protocol; and the operator may purge the session after the term, which the capability document declares and every extract labels ephemeral. Quorum and notice may be scaled down for small rosters. (D59)

    Read it in the council log

  6. D60

    foreign_principal disclosure, equal for all, never nationality

    Rejected
    No disclosure; nationality fields
    Revisit if
    It chills legitimate speech
    How it was decided: Round 58: Foreign influence
    • Clearance and Badge asked that disclosure cover acting for a foreign government or political party.
    • Cause warned that this could chill diaspora voices and foreign-born residents.
    • Outcome: the disclosure gains foreign_principal, covering only acting at the direction or expense of a foreign government or foreign political party. Nationality and residence are not asked. It is required (null allowed) for every non-member opinion, under the same rule for everyone. (D60)

    Read it in the council log

Session 10 · 2026-10-27

Assessment of Simulation 2

What changed in this session

What changed: Simulation 2 reran the Iran war session with the full cast. That cast was the 30 council personas plus nine more from the Session 8 list: synthetic constituent panels, executive-branch implementers, a second chamber, an affected-populations advisory panel, a diplomat and international-law expert, a security red team, an accessibility and language-access advocate, an election administrator, and a privacy and civil-liberties expert. Everyone reviewed the result. Details are in SIMULATION_02_IRAN_WAR.md.

  1. D61

    Key aging: a non-member key may publish opinions only after its key.register transaction has been checkpointed for a node-declared period (default 24 hours), on top of per-key limits. Viewpoint-neutral, like D51

    Rejected
    Grouping keys; reputation
    Revisit if
    Attackers pre-age keys at scale (OQ-30)
    How it was decided: What the rerun showed
    1. The House result held up. The coalition bill (MR-4 v3) passed 6,054 to 3,804, with 672 members absent and 3 void, a margin of 553 over the threshold. It held under every ±10% bloc change and a ±3-point turnout change. Realistic turnout cut the margin from Simulation 1's 729.
    2. Contests behaved as Agenda predicted. Grouped in a contest, the four single-faction bills elected MR-3, but MR-3 then failed its own rule with 5,079 approvals. The status quo stood.
    3. Bicameralism and presentment are the real barrier. The second chamber's 100 synthetic senators voted 55 to 45 in favor, short of the 60 votes usually needed to end debate on a bill of this breadth. Even if it passed, neither chamber came near the two-thirds needed to override a veto.
    4. The red team found two real attacks.
      • 2,000 fresh keys flooded opinions while each stayed under its per-key limit, so D51 alone does not stop sybils.
      • Three stolen member keys were used to cast conflicting ballots, which voided the real members' votes under D10. The equivocation rule is a weapon if keys are stolen.
    5. Translation can mislead. One published translation rendered a non-binding "sense of Congress" as a binding requirement. Verdict caught it only because the translation was anchored to verified quotes.
    6. Privacy and safety risks materialized. Badge logged 14 threat reports against members after publicized votes. Privy showed that the roll-call export, signed statements, and group positions together make targeting lists easy.

    Read it in the council log

  2. D62

    Key revocation and rotation: each session names a registrar group. A member and the registrar jointly sign key.rotate; ballots signed by the old key after the reported compromise point are ignored rather than treated as equivocation, so a thief cannot void a member's vote

    Rejected
    No revocation; registrar acting alone
    Revisit if
    The registrar becomes a point of capture
    How it was decided: What the rerun showed
    1. The House result held up. The coalition bill (MR-4 v3) passed 6,054 to 3,804, with 672 members absent and 3 void, a margin of 553 over the threshold. It held under every ±10% bloc change and a ±3-point turnout change. Realistic turnout cut the margin from Simulation 1's 729.
    2. Contests behaved as Agenda predicted. Grouped in a contest, the four single-faction bills elected MR-3, but MR-3 then failed its own rule with 5,079 approvals. The status quo stood.
    3. Bicameralism and presentment are the real barrier. The second chamber's 100 synthetic senators voted 55 to 45 in favor, short of the 60 votes usually needed to end debate on a bill of this breadth. Even if it passed, neither chamber came near the two-thirds needed to override a veto.
    4. The red team found two real attacks.
      • 2,000 fresh keys flooded opinions while each stayed under its per-key limit, so D51 alone does not stop sybils.
      • Three stolen member keys were used to cast conflicting ballots, which voided the real members' votes under D10. The equivocation rule is a weapon if keys are stolen.
    5. Translation can mislead. One published translation rendered a non-binding "sense of Congress" as a binding requirement. Verdict caught it only because the translation was anchored to verified quotes.
    6. Privacy and safety risks materialized. Badge logged 14 threat reports against members after publicized votes. Privy showed that the roll-call export, signed statements, and group positions together make targeting lists easy.

    Read it in the council log

  3. D63

    Anchored translations and plain-language versions: published as opinions with a translation field, every passage anchored to a verified quote, always authoritative: false

    Rejected
    Unanchored translations; official translations
    Revisit if
    Anchoring is too costly for long texts
    How it was decided: What the rerun showed
    1. The House result held up. The coalition bill (MR-4 v3) passed 6,054 to 3,804, with 672 members absent and 3 void, a margin of 553 over the threshold. It held under every ±10% bloc change and a ±3-point turnout change. Realistic turnout cut the margin from Simulation 1's 729.
    2. Contests behaved as Agenda predicted. Grouped in a contest, the four single-faction bills elected MR-3, but MR-3 then failed its own rule with 5,079 approvals. The status quo stood.
    3. Bicameralism and presentment are the real barrier. The second chamber's 100 synthetic senators voted 55 to 45 in favor, short of the 60 votes usually needed to end debate on a bill of this breadth. Even if it passed, neither chamber came near the two-thirds needed to override a veto.
    4. The red team found two real attacks.
      • 2,000 fresh keys flooded opinions while each stayed under its per-key limit, so D51 alone does not stop sybils.
      • Three stolen member keys were used to cast conflicting ballots, which voided the real members' votes under D10. The equivocation rule is a weapon if keys are stolen.
    5. Translation can mislead. One published translation rendered a non-binding "sense of Congress" as a binding requirement. Verdict caught it only because the translation was anchored to verified quotes.
    6. Privacy and safety risks materialized. Badge logged 14 threat reports against members after publicized votes. Privy showed that the roll-call export, signed statements, and group positions together make targeting lists easy.

    Read it in the council log

  4. D64

    Constituent panels in research mode: synthetic panels per district with declared views; the harness reports how closely members' votes track their panels

    Rejected
    No constituents
    Revisit if
    Real participants become available (OQ-27)
    How it was decided: What the rerun showed
    1. The House result held up. The coalition bill (MR-4 v3) passed 6,054 to 3,804, with 672 members absent and 3 void, a margin of 553 over the threshold. It held under every ±10% bloc change and a ±3-point turnout change. Realistic turnout cut the margin from Simulation 1's 729.
    2. Contests behaved as Agenda predicted. Grouped in a contest, the four single-faction bills elected MR-3, but MR-3 then failed its own rule with 5,079 approvals. The status quo stood.
    3. Bicameralism and presentment are the real barrier. The second chamber's 100 synthetic senators voted 55 to 45 in favor, short of the 60 votes usually needed to end debate on a bill of this breadth. Even if it passed, neither chamber came near the two-thirds needed to override a veto.
    4. The red team found two real attacks.
      • 2,000 fresh keys flooded opinions while each stayed under its per-key limit, so D51 alone does not stop sybils.
      • Three stolen member keys were used to cast conflicting ballots, which voided the real members' votes under D10. The equivocation rule is a weapon if keys are stolen.
    5. Translation can mislead. One published translation rendered a non-binding "sense of Congress" as a binding requirement. Verdict caught it only because the translation was anchored to verified quotes.
    6. Privacy and safety risks materialized. Badge logged 14 threat reports against members after publicized votes. Privy showed that the roll-call export, signed statements, and group positions together make targeting lists easy.

    Read it in the council log

  5. D65

    Bicameral and presentment models in research mode: an optional second chamber with its own rules (including a debate-closing threshold) and a presentment model, labeled hypothetical. Bicameralism stays out of the protocol's core

    Rejected
    No second chamber; bicameral core
    Revisit if
    The core needs it
    How it was decided: What the rerun showed
    1. The House result held up. The coalition bill (MR-4 v3) passed 6,054 to 3,804, with 672 members absent and 3 void, a margin of 553 over the threshold. It held under every ±10% bloc change and a ±3-point turnout change. Realistic turnout cut the margin from Simulation 1's 729.
    2. Contests behaved as Agenda predicted. Grouped in a contest, the four single-faction bills elected MR-3, but MR-3 then failed its own rule with 5,079 approvals. The status quo stood.
    3. Bicameralism and presentment are the real barrier. The second chamber's 100 synthetic senators voted 55 to 45 in favor, short of the 60 votes usually needed to end debate on a bill of this breadth. Even if it passed, neither chamber came near the two-thirds needed to override a veto.
    4. The red team found two real attacks.
      • 2,000 fresh keys flooded opinions while each stayed under its per-key limit, so D51 alone does not stop sybils.
      • Three stolen member keys were used to cast conflicting ballots, which voided the real members' votes under D10. The equivocation rule is a weapon if keys are stolen.
    5. Translation can mislead. One published translation rendered a non-binding "sense of Congress" as a binding requirement. Verdict caught it only because the translation was anchored to verified quotes.
    6. Privacy and safety risks materialized. Badge logged 14 threat reports against members after publicized votes. Privy showed that the roll-call export, signed statements, and group positions together make targeting lists easy.

    Read it in the council log

Session 11 · 2026-10-27

Assessment of Simulation 3 (the power of the purse)

What changed in this session

What changed: Simulation 3 attached Simulation 2's conditions to the war funding the executive has requested (SIMULATION_03_IRAN_WAR_FUNDING.md). The conditioned supplemental passed the House with 7,286 approvals and cleared the Senate's 60-vote threshold at 62. Its fate then depended on the executive. In one branch, a negotiated deal kept limits on the war's scope but not a fixed end date. In the other, a veto held and the dispute moved to the 11 December funding deadline.

  1. D66

    Appropriation markers: [[approp:<account>:<dollars>:<fiscal year>]] tags each amount, and [[avail:<condition id>]] ties it to an availability condition. The fact sheet totals amounts by account and year and lists which amounts are fenced, deterministically. Estimates (D53) cite the markers

    Rejected
    Free-text amounts only
    Revisit if
    Markers prove too rigid for real appropriations language
    How it was decided: Findings
    • Money adds a dimension. Agenda and Spatial: "supporting the troops" pulled members from both ends of the force-versus-restraint dimension toward the center. The coalition grew by about 1,200 members, while losing some on the Restraint flank.
    • Deals keep scope, not deadlines. Advocate: in the negotiated branch, the hard 120-day cutoff became a certification and a disapproval resolution that can itself be vetoed. Limits on what the war may involve survived. Limits on how long did not.
    • Totals were hard to verify. Score could not check totals or availability conditions mechanically, because amounts were buried in prose.
    • Bargaining left no record. Bench and Counsel: the negotiation between the chambers and the executive left no structured trail. A conference text arrived as a new MR, with no record of the offers behind it.
    • Vehicles have content rules. Lint: whether conditions could ride on reconciliation turned on a vehicle-specific content rule, which the protocol cannot express.
    • Must-pass leverage falls on bystanders. Ombud and Panels: leverage at a must-pass funding deadline is paid for by people with no stake in the dispute.

    Read it in the council log

  2. D67

    Exchanges in research mode: offers between chambers and from the executive are signed, versioned exchange opinions linking the MR, the offer text as a change, and the prior offer. A conference MR cites the exchange chain that produced it. All labeled hypothetical

    Rejected
    Unrecorded bargaining
    Revisit if
    The core protocol needs bicameral exchange
    How it was decided: Findings
    • Money adds a dimension. Agenda and Spatial: "supporting the troops" pulled members from both ends of the force-versus-restraint dimension toward the center. The coalition grew by about 1,200 members, while losing some on the Restraint flank.
    • Deals keep scope, not deadlines. Advocate: in the negotiated branch, the hard 120-day cutoff became a certification and a disapproval resolution that can itself be vetoed. Limits on what the war may involve survived. Limits on how long did not.
    • Totals were hard to verify. Score could not check totals or availability conditions mechanically, because amounts were buried in prose.
    • Bargaining left no record. Bench and Counsel: the negotiation between the chambers and the executive left no structured trail. A conference text arrived as a new MR, with no record of the offers behind it.
    • Vehicles have content rules. Lint: whether conditions could ride on reconciliation turned on a vehicle-specific content rule, which the protocol cannot express.
    • Must-pass leverage falls on bystanders. Ombud and Panels: leverage at a must-pass funding deadline is paid for by people with no stake in the dispute.

    Read it in the council log

Open questions

What the council could not settle, parked for real stakeholders and the RFC process, and how each question moved as later sessions took it up.

  1. OQ-1

    Late ballots and time in eventual mode

    1. Raised in Session 1

      A deadline is advisory there, so two nodes may close over different ballot sets.

  2. OQ-2

    Contests

    1. Raised in Session 1

      Ranked choice and "virtual capital bidding" need a first-class set of competing MRs targeting the same nid.

    2. Specified (D47).

  3. OQ-3

    Contradictory determinations across forks

    1. Raised in Session 1

      An equivocating member could help two nodes reach opposite outcomes on eventual profiles. strong profiles avoid this by total order.

  4. OQ-4

    Secret ballots

    1. Raised in Session 1

      Anonymity conflicts with the verify-everything design.

    2. Session 2 · upgraded, top priority

      Options on the table: delayed individual ballots, aggregate-only with verifiable tallies, or public ballots with anti-harassment norms outside the protocol.

    3. Session 3 · updated

      Now three-sided: accountability, coercion resistance, and which claims about votes stay checkable.

    4. Session 6 · updated

      Public ballots serve accountability to voters but also discipline by parties and pressure from interest groups. Secret ballots protect members from all three.

  5. OQ-5

    Issuing 11,000 keys

    1. Raised in Session 1

      Sybil resistance and identity are out of scope, but they are the real trust root for any deployment.

  6. OQ-6

    Opinion spam

    1. Raised in Session 1

      With thousands of members plus advisors and AI agents, rate limits and reputation need design.

  7. OQ-7

    Does the ledger layer earn its cost?

    1. Raised in Session 1

      This is the paper's central bet. The council's answer is to make it testable: S10 (malicious operator) and S11 (scale) compare what a BFT-replicated implementation buys against single-writer-plus-witnesses and CRDT designs.

  8. OQ-8

    Provisional reporting

    1. Raised in Session 2

      Labels make honest reporting easier, not mandatory. Proposed scenario S12 tests whether an implementation's event stream makes final_advisory easy to misread.

  9. OQ-9

    Member conflicts

    1. Raised in Session 2

      Should members disclose funding and affiliations on their own MRs and opinions, as non-members now must?

    2. Session 5 · narrowed

      non-financial member conflicts only. Financial stakes fall under D32.

  10. OQ-10

    Clip context

    1. Raised in Session 2

      Can a citation carry enough context (surrounding nodes, MR state) that a 30-second clip can't misrepresent where a provision sits?

  11. OQ-11

    Who owns the verdict scale?

    1. Raised in Session 3

      A fixed scale enables interoperability but invites fights over wording. Should the scale itself change only by governance-style RFC?

  12. OQ-12

    Statements outside the protocol

    1. Raised in Session 3

      Floor speeches, interviews, and posts are where most claims are made. Should members be able to publish signed statement objects so their public claims become checkable in-protocol?

    2. Partly addressed (D52).

  13. OQ-13

    Reproducing AI findings

    1. Raised in Session 3

      Listing inputs does not make a non-deterministic model reproducible. Is a pinned model version plus the full prompt enough, or should AI findings require a human co-signer?

  14. OQ-14

    Required formalization

    1. Raised in Session 4

      Should some MRs (numbers, deadlines, money) need an anchored formalization, or only show a warning?

  15. OQ-15

    Choosing among formalizations

    1. Raised in Session 4

      With no canonical model, how do readers know which formalization to trust, without inventing the reputation scores D18 and D25 forbid?

  16. OQ-16

    Profiles beyond the US

    1. Raised in Session 4

      Who writes and maintains structure profiles for other jurisdictions, and how do they change?

  17. OQ-17

    Member trading

    1. Raised in Session 5

      Should members be barred from holding positions on outcomes they vote on, and can any mechanism make that more than an honor system?

  18. OQ-18

    Performative prediction

    1. Raised in Session 5

      Do published forecasts change votes? Proposed: a harness experiment with simulated blocs that react to forecasts.

  19. OQ-19

    Owner-blind commitments (now urgent)

    1. Raised in Session 5

      Can restricted-branch commitments hide the owner without breaking access control and reveal verification (D19)?

  20. OQ-20

    Coercion

    1. Raised in Session 6

      How can members be protected from party and interest-group pressure without hiding votes from voters?

  21. OQ-21

    Donor privacy

    1. Raised in Session 6

      Should group and non-member disclosures name donors, give funding kinds only, or name donors above a threshold?

  22. OQ-22

    Independent review of this council

    1. Raised in Session 6

      All personas are simulated by one model. Which real stakeholders review the decisions first, and how do their objections enter the RFC process?

  23. OQ-23

    Enrolled text

    1. Raised in Session 7

      If the design were used for real, what would play the role of an attested enrolled bill: co-signed checkpoints, a human attestation, or both?

  24. OQ-24

    Emergency passage

    1. Raised in Session 7

      Can there be an exception to notice that cannot become routine?

    2. Addressed as a hypothesis (D49).

  25. OQ-25

    External validity

    1. Raised in Session 7

      What can a simulation with synthetic or AI-driven voters actually show about real legislators?

  26. OQ-26

    Missing options

    1. Raised in Session 8

      How can the protocol help coalitions find a compromise no faction drafted, without per-group tally breakdowns that also serve whip discipline (OQ-20)?

  27. OQ-27

    Who is represented?

    1. Raised in Session 8

      How should constituents take part in a simulation: synthetic constituents with declared views, real participants, or both?

  28. OQ-28

    Member safety

    1. Raised in Session 9

      How can 11,000 members with public records be protected from threats without hiding their votes?

  29. OQ-29

    Classified material

    1. Raised in Session 9

      If the design were used for real, could classified annexes ever be compatible with "no secret law"?

  30. OQ-30

    Sybil resistance for non-member speech

    1. Raised in Session 10

      Key aging slows attackers but does not stop patient ones. What else stays viewpoint-neutral?

  31. OQ-31

    A formal role for affected populations

    1. Raised in Session 10

      Should people outside the electorate who are directly affected by a law have a structured advisory channel beyond ordinary opinions?

  32. OQ-32

    Vehicle content rules

    1. Raised in Session 11

      Should a rule kind be able to restrict what an MR may contain? For example, a budget-only vehicle could reject nodes without appropriation markers, as the reconciliation process does in practice.

  33. OQ-33

    Must-pass leverage

    1. Raised in Session 11

      Should the fact sheet flag provisions in a must-pass bill that are unrelated to its core purpose, and who decides what is unrelated without becoming an authority?