Council Vote Tally Probe — real-time BFT quorum audit and historical record.

Overview and Purpose

The Council Vote Tally Probe provides transparent and auditable access to the voting records of the 33-agent BFT Defence Council. It ensures that all decisions, particularly those impacting critical infrastructure and red-line invariants, are transparently recorded and verifiable by external parties. This mechanism is crucial for maintaining trust and demonstrating sovereign integrity.

The probe exposes the full motion history (one entry per motion, immutable and SIGIL-anchored), the per-ring vote distribution, the per-agent care-score contribution, and the byzantine-failure-detection log. Every motion has a single canonical record. No motion is ever silently modified, retconned, or struck from the record.

The probe serves three distinct buyer audiences:

1. Procurement officers verifying that DEFONEOS-SEAL candidates cleared a real quorum (not a self-assertion).
2. Compliance auditors testing that the council behaves within declared thresholds (23/33, 27/33, 17/33, 33/33).
3. Independent researchers reproducing tally outcomes from raw SIGIL data without a DEFONEOS-operated UI.

Tally Protocol and Cryptographic Anchoring

Each vote on a council motion is individually signed by participating agents using Ed25519 cryptography. These individual signatures are then aggregated and cryptographically anchored to the immutable SIGIL ledger. This creates a tamper-proof record of every decision, including the specific votes cast and the overall quorum outcome.

The anchoring process involves:

1. Motion open: Motion author (an R1 owner seat or R2 defence-prime seat) submits motion manifest with Ed25519 signature.
2. Witness selection: 3 ring-distinct witnesses chosen via deterministic VRF (seeded by SIGIL digest + motion nonce). Witnesses are publicly disclosed at open time.
3. Voting window: 72h standard · 24h red-line · 4h emergency. Agents cast signed ballots within the window.
4. Witness aggregation: The 3 witnesses collect, verify, and sign an aggregated tally manifest.
5. SIGIL anchor: Aggregated manifest is hashed (BLAKE3) and anchored to the SIGIL ledger as a new block entry.
6. Owner cosign: Owner-seat (R1) cosigns every DEFONEOS-SEAL-eligible motion. Without R1 signature, the motion is recorded as PASS but cannot trigger a SEAL.

This protocol ensures that any alteration to the vote tally or associated data would be immediately detectable via BLAKE3 hash mismatch.

The aggregated manifest is byte-identical across all three witness copies. Any divergence between witness copies triggers a SIGIL emergency ledger entry and a red-line tally flag.

Key Metrics and Indicators

The tally probe exposes several key metrics to assess the council's operation:

• Motions Cumulative: Total number of proposals put to a vote (142 as of tick-117).
• Motions Passed: Number of proposals that successfully achieved quorum (140).
• Motions Amended: Number that passed after amendment (2).
• Motions Rejected: Number that failed quorum (0 — but one was withdrawn at voting-window open before tally).
• Red-line Violations: Count of motions that attempted to cross an immutable red-line invariant and were rejected. This number MUST remain zero.
• Average Care Score: A composite score reflecting the diligence and thoroughness of agent review for each motion, ranging from 0.0 (negligent) to 1.0 (exemplary).
• Owner Cosign Rate: Percentage of motions carrying R1 owner cosignature (100% — required for SEAL eligibility).
• Witness Disagreement: Count of motions where the 3 witnesses reported divergent aggregate hashes (0).

Quorum Thresholds

Thresholds are encoded in the council charter and may only be altered by a constitutional-amendment motion (30/33 supermajority, 168h window, all 5 rings represented).

Ring Vote Distribution

Across the 142 cumulative motions, vote contributions are distributed across the five council rings as follows:

Average ballots per motion = 31.95 of 33 (96.8% participation). Disagreement events = 0 across the 142-motion history.

Recent Motions (last 10)

The following table lists the last 10 council motions with their tallies. Full history (142 motions) is available via the segmented API endpoint.

Amendment notes: M-133 was amended to add explicit owner-cosign verification before any tick-110 surface was treated as canonical. The amendment passed in the same voting window.

Accessing Live Tally Data

Live tally data for the most recent motions can be accessed via the public SIGIL-anchored API endpoint. The endpoint returns JSON manifests with vote breakdowns, care scores, witness signatures, and SIGIL ledger anchors.

curl -s https://www.csoai.org/api/v1/council-vote-tally-latest | jq .

Historical data is available through segmented endpoints, allowing for efficient retrieval of older records without overloading the live system:

curl -s https://www.csoai.org/api/v1/council-vote-tally/motion_id/M-142 | jq .
curl -s https://www.csoai.org/api/v1/council-vote-tally/range?from=2026-07-01&to=2026-07-17 | jq .

Aggregated summary endpoints:

curl -s https://www.csoai.org/api/v1/council-vote-tally/summary | jq .
curl -s https://www.csoai.org/api/v1/council-vote-tally/ring-distribution | jq .

Verification via Curl

Any third party can verify the integrity of the published vote tallies using simple curl commands and comparing the results against the SIGIL ledger. The following examples demonstrate how to retrieve raw data and compare cryptographic hashes:

# 1. Retrieve raw JSON data for the latest motion
LATEST=$(curl -s https://www.csoai.org/api/v1/council-vote-tally-latest)

# 2. Extract the SIGIL BLAKE3 anchor from the JSON
SIGIL_ANCHOR=$(echo "$LATEST" | jq -r '.sigil_anchor')

# 3. Compute local BLAKE3 hash of the raw motion manifest (excluding sigil_anchor)
LOCAL_HASH=$(echo "$LATEST" | jq 'del(.sigil_anchor)' | jq -c '.' | b3sum | awk '{print $1}')

# 4. Compare with the SIGIL ledger anchor
if [ "$LOCAL_HASH" = "$SIGIL_ANCHOR" ]; then
  echo "✓ Integrity verified for motion $(echo $LATEST | jq -r .motion_id)"
else
  echo "✗ Integrity mismatch — manifest has been tampered with"
fi

# 5. Verify owner cosign on a SEAL-eligible motion
COSIGN=$(curl -s https://www.csoai.org/api/v1/council-vote-tally/motion_id/M-142 | jq -r '.owner_cosign_present')
if [ "$COSIGN" = "true" ]; then
  echo "✓ Owner seat cosigned M-142 — SEAL-eligible path remains valid"
fi

This process ensures byte-level integrity and cryptographic proof of the council's decisions without needing to trust any DEFONEOS-operated UI surface.

Red-line Invariant Adherence

The DEFONEOS BFT Defence Council operates under a strict set of red-line invariants. Any motion attempting to violate these invariants is automatically rejected by the witness-layer aggregator, and a record of the attempted violation is immutably logged on the SIGIL ledger as a red-line-rejected manifest.

The current red-line violations counter stands at 0, demonstrating continuous adherence to these critical safety and ethical boundaries. The seven red-line invariants enforced:

1. No US-rooted CDN dependency — banned: jsdelivr, unpkg, cdnjs, googleapis (as a CDN).
2. No US-rooted root CA — only the sovereign Root CA + 3 BFT-gated Intermediate CAs.
3. No US cloud API dependency — banned: AWS, GCP, Azure, Cloudflare, US-hosted OpenAI/Anthropic/xAI/HuggingFace inference endpoints.
4. No US-rooted NTP — only Chrony with UK/EU stratum-1 pools or air-gap local time source.
5. No US-rooted telemetry / analytics — banned: Google Analytics, Mixpanel, Segment, US-vendor session replay.
6. No US-vendor JavaScript — banned client-side: reCAPTCHA, US analytics, US A/B testing SDKs.
7. No kinetic-targeting or personal-surveillance patterns — strike package / find-fix-finish / kill order / face-rec / phone-locate all hard-stopped.

Cross-link Map

This probe is the canonical reference for the live tally state. Companion surfaces:

• defoneos-bft-council-public-minutes — full motion list with vote tallies, amendments, and care-score details.
• defoneos-witness-list-rotation-policy — quarterly R2/R3, monthly R4, semi-annual R5 rotation schedule.
• defoneos-witness-list-live-snapshot — current witness list endpoint with deterministic VRF selection.
• defoneos-bft-quorum-cryptography-spec — BLS12-381 DKG + GG20 threshold-Ed25519 + witness ring-distinct selection.
• defoneos-sbom-index — 30 MCPs SPDX 2.3 with daily freshness probe.