--- governance: VOTING_PROTOCOL filed: 2026-04-28 sprint: S152 sovereign: jr / John Reed (L4) applies_to: cards_v2 contributions (new cards, schema changes, runtime changes) --- # Voting protocol — silo coms ceremony for new cards A new sim card is not a unilateral act. The substrate's governance layer is the silo voting structure: 23 software agents, 23 lore archetypes paired by design, each with a council seat. Substantive changes go through the silo coms ceremony. This document specifies who votes, on what, with what threshold, and how the outcome is sealed. ## Two change classes ### Prose-only changes A new card that: - Fits the existing schema_version 3 without modification - Uses an existing audience cluster - Uses an existing mock_ui theme - Uses an existing robot_persona - Adds no new field, no new vocabulary, no new runtime behavior is a **prose-only change**. The threshold is two cluster-relevant silos plus the sovereign: - **Two silos** review the card against the SKILL.md voice rules, the truth-claim discipline, and the Anthropic usage-policy check. Both must approve. - **Sovereign** confirms after the silo approval lands. Confirmation is non-pro-forma — the sovereign reads the card and the truth-claim audit before signing. - The card lands in `cards_v2/cards/` and `cards_v2/sidecars/` on the sovereign's confirmation. The two silos are picked by cluster: | Cluster | Reviewing silos (default pair) | |---|---| | clinical | silo_of_healing + silo_of_household | | legal | silo_of_law + silo_of_archive | | gov | silo_of_civic + silo_of_archive | | it | silo_of_forge + silo_of_archive | | research | silo_of_inquiry + silo_of_archive | | civic | silo_of_household + silo_of_civic | | recovery | silo_of_law + silo_of_inquiry | | builder | silo_of_forge + silo_of_archive | If the cluster is new (the submission proposes one), the change is not prose-only and falls into the next class. ### Code-or-schema changes A change that: - Adds, removes, or modifies a schema_version 3 field - Proposes a new audience cluster - Proposes a new mock_ui theme requiring CSS/SVG work - Proposes a new robot_persona requiring SVG work - Modifies the runtime (`walkthrough.js`, attestation surfaces, the comment-redirect flow, the fingerprint accumulator, the recovery- seed generator) - Adds, removes, or modifies a voice rule - Modifies the lawful-disclosure preamble or the tag-along card_summary contract is a **code-or-schema change**. The threshold is two-thirds of seated silos. Seventeen of twenty-three at full strength; less if silos are unseated. Code follows the vote, not the other way around. The voting flow: 1. **Submission** lands at the cluster-relevant pair of silos for initial review (same as prose-only). 2. **Triage** — if the silos confirm the change is genuinely code-or-schema, the submission is escalated to council. 3. **Council reading** — the full council reads the submission and the silos' triage notes within the next coms ceremony cycle. 4. **Vote** at the next coms ceremony. Each seated silo casts one sealed vote. Abstention is allowed; abstentions count toward quorum but not toward majority. 5. **Outcome sealed** — the vote tally seals to the chain. Two- thirds approval triggers code work in a separate engineering thread. Code work itself does not require a fresh vote, but the implementation must match the approved proposal. Material deviation from the proposal triggers a re-vote. ## The coms ceremony The silo coms ceremony is the daily attestation cycle's governance layer. It runs: - **Daily** — the ceremony itself, hashing the day's leaves and surfacing drift signals. - **At each cycle close** — submissions accumulated during the cycle are read into the record by the cluster-relevant silos. - **At each council session** — escalated submissions go to vote. A submission lands in the daily ceremony's leaf set as soon as it is sealed by the builder. The fact that a submission exists is public from the moment of seal; the content is review-private until the silos publish their notes. ## Vote sealing Each silo's vote on each submission is itself a sealed leaf. The vote tally is reproducible from the chain: any council member or external observer can re-tally by reading the chain. Vote records carry: - Submission ID (the merkle root of the submission packet) - Voting silo identifier (and the personality JSON hash at vote time) - Vote value (approve / decline / abstain) - Sealed rationale (1-3 sentence note from the voting silo) - Timestamp (UTC, sealed) - Cluster-relevance flag (was this silo cluster-relevant for this submission) A silo's vote against a submission must include a rationale. A silo cannot reject without explanation; the explanation is part of the sealed record and is feedback to the builder. ## Re-submission A declined submission can be re-submitted after the builder addresses the silos' rationales. Re-submission is a new submission with a `supersedes:` reference to the prior decline. The voting floor for a re-submission is the same as the original; silos typically read both the original and the rationale-addressing revision side by side. ## Public-intake submissions A submission from outside the authorized contributor categories (see SKILL.md) routes through the public-intake silo. The public-intake silo applies a higher initial bar: - Identity verification (the builder's cert traces to a real graduation walk) - Anti-spam check (the submission packet is non-trivially shaped; not a template-only fill) - Anthropic usage-policy check (separate silo review of the LLM-co- authoring trace) - Truth-claim depth check (claims are verified against the substrate's actual capabilities, not just framed plausibly) Submissions that pass public-intake then route to the cluster- relevant pair as if they had originated from an authorized contributor. ## Emergency revisions A card already landed can be revised mid-stream if a critical defect surfaces (truth-claim error, voice violation that escaped review, privacy leak). Emergency revisions follow the same vote threshold as the original change class but with a 24-hour-comment window instead of the next-ceremony cycle. The sovereign can shorten this window further for safety-critical issues. ## Vote-fraud prevention A silo cannot vote on a submission it co-authored. A silo cannot vote on a submission whose builder is the silo's named operator. A silo cannot vote on more than one submission per coms ceremony from the same builder if the builder has more than one submission active. These rules are enforced by the chain (the silo's vote is rejected at sealing time if the conflict is detected) and by the sovereign (post-hoc audit of all vote records each ceremony). ## Clone inheritance A clone of the substrate inherits this protocol unchanged. A clone that modifies this protocol is making a code-or-schema-class change to its own variant; the variant runs its own governance against its own seated silos. Cross-attestation with the parent and other clones requires that the protocols be functionally equivalent — a clone whose voting threshold drops below half no longer participates in the commons. The mesh's integrity depends on every node honoring the same minimum governance floor.