Structured Output Format for Council Verdicts: Complete Template Guide

The Council of High Intelligence produces its decisions in a rigorously defined Markdown template encoded in the repository's SKILL.md file, ensuring every verdict includes problem statements, council composition, kill criteria, and machine-readable session metadata.

The 0xNyk/council-of-high-intelligence repository implements a multi-agent deliberation system that outputs decisions through a standardized structured output format for council verdicts. This format ensures consistency, auditability, and machine-readability across all deliberation modes including full, quick, and duo configurations. The template specification resides in SKILL.md under the Output Templates section, defining mandatory headings and metadata fields that every council session must populate.

Full Mode Verdict Structure

The complete structured output format for council verdicts contains seventeen distinct sections, each serving a specific analytical purpose. These sections transform raw deliberation into an auditable decision record.

Problem and Composition

The template begins with foundational context:

• ### Problem – Restates the original problem statement verbatim to maintain alignment between the query and the resulting decision.

• ### Council Composition – Lists convened members, the deliberation mode (full/quick/duo), and the rationale for panel selection.

• ### Chairman – Identifies the synthesizing model with provider details, model name, and selection rationale (override, config, auto-selected, or fallback).

• ### Provider Routing – Displays a table mapping each council member to their specific provider and model, including any fallback assignments.

Decision Mechanics

Central sections capture the decision logic and constraints:

• ### Acceptable Compromises – Enumerates trade-offs accepted to reach consensus, with one bullet per compromise.

• ### Kill Criteria – Defines concrete, observable conditions that would invalidate the verdict, formatted as "If X observed by date, the verdict is falsified."

• ### Concrete Next Step – Specifies a single actionable task following the format "<verb> <object> by <date>."

• ### Unresolved Questions – Captures open-ended queries the council could not answer.

• ### Recommended Next Steps – Lists additional prioritized actions or states "N/A" if the concrete step suffices.

Consensus and Voting

The template records the deliberation outcome through structured voting data:

• ### Consensus & Agreement – States the final position that survived deliberation, or a "No consensus reached" statement with explanation.

• ### Vote Tally – Shows the weighted tally from STEP 6, displaying each option's weight, backers, domain-weight seat, threshold, and clearance status (e.g., "monorepo — 3.5 (Aristotle [1.5×, domain], Ada, Feynman) ✅ cleared 2/3 threshold").

Analysis and Dissent

Meta-cognitive sections capture the deliberation quality:

• ### Key Insights by Member – One-sentence highlight of each member's most valuable contribution.

• ### Points of Disagreement – Summarizes positions that remained irreconcilable.

• ### Minority Report – Documents dissenting positions and strongest arguments, including any "dealbreaker" flags.

• ### Epistemic Diversity Scorecard – Scores perspective spread, provider spread, evidence mix, and convergence risk on defined scales.

Session Closure

Final sections ensure accountability and automation:

• ### Follow-Up – Prompts the user to reflect after acting on the verdict.

• ### Session Metadata – Contains a machine-readable YAML-style block with fields including schema_version, mode, panel_size, rounds_run, tools_used, provider_count, and fallbacks_triggered.

Quick and Duo Verdict Variations

The Quick Verdict and Duo Verdict formats follow the same structural philosophy but trim sections for brevity. These abbreviated versions retain essential fields—Problem, Panel, Chairman, Recommended Action, Kill Criteria, Concrete Next Step, Vote Tally, Key Disagreement, and Session Metadata—while omitting extensive sections like Acceptable Compromises, Key Insights by Member, and Epistemic Diversity Scorecard.

According to the SKILL.md specifications, these variations appear in the "Quick Verdict" and "Duo Verdict" subsections under Output Templates, optimizing for speed while maintaining decision rigor.

Example Council Verdict

Below is a minimal illustration of a full-mode verdict as generated by the council coordinator after deliberation rounds:

## Council Verdict

### Problem

Should we adopt a monorepo architecture for our new platform?

### Council Composition

Full mode – members: Aristotle, Ada, Feynman (triad 'architecture').

### Chairman

Chairman: gemini (provider google · model gemini-2.5-pro). Selection rationale: auto-selected.

### Provider Routing

| Member   | Provider | Model |
|----------|----------|-------|
| Aristotle| anthropic| opus  |
| Ada      | sonnet   | sonnet|
| Feynman  | anthropic| opus  |

### Acceptable Compromises

- **Build-time overhead** – we accept longer CI pipelines in exchange for tighter code coupling.

### Kill Criteria

- If CI build time exceeds 30 minutes for > 3 consecutive runs, re-evaluate.

### Concrete Next Step

Create a prototype monorepo at `repo/monorepo` by **2026-08-15**.

### Unresolved Questions

- How will versioning be managed across teams?

### Recommended Next Steps

1. Draft a monorepo layout proposal.  
2. Run a pilot migration on the `auth` service.

### Consensus & Agreement

Monorepo – the council agrees on adopting a monorepo architecture.

### Vote Tally

- monorepo — 3.5 (Aristotle [1.5×, domain], Ada, Feynman) ✅ cleared 2/3 threshold  
- W_total 3.5 · threshold 2.333

### Key Insights by Member

- **Aristotle**: Classification of modules simplifies dependency management.  
- **Ada**: Formal verification of interface contracts is easier in a single repo.  
- **Feynman**: First-principles suggest tighter integration reduces latency.

### Points of Disagreement

- None – all members aligned after cross-examination.

### Minority Report

N/A — unanimous support.

### Epistemic Diversity Scorecard

- Perspective spread (1-5): 4  
- Provider spread (1-5): 1 (single provider)  
- Evidence mix: 30% empirical | 40% mechanistic | 30% strategic  
- Convergence risk: Low – strong argument overlap.

### Follow-Up

After the prototype is built, revisit the verdict: Did the monorepo improve build times and code cohesion?

### Session Metadata

```yaml
schema_version: 1
mode: full
panel_size: 3
rounds_run: 3
chairman_failed_fallback: no
tools_used: yes
input_tokens_estimate: ~12k
output_tokens_estimate: ~8k
duration_seconds: ~45
provider_count: 2
fallbacks_triggered: none

## Key Implementation Files

The structured output format for council verdicts relies on specific repository components:

- **[`SKILL.md`](https://github.com/0xNyk/council-of-high-intelligence/blob/main/SKILL.md)** – Contains the full execution sequence, the *Output Templates* section defining the structured verdict format, and all routing and panel logic.
- **`agents/*.md`** – Defines each council member's identity, grounding protocol, and output format that feed into the verdict synthesis.
- **[`README.md`](https://github.com/0xNyk/council-of-high-intelligence/blob/main/README.md)** – Provides overview documentation, example commands, and quick start instructions for invoking the council.

## Summary

- The **structured output format for council verdicts** is defined in [`SKILL.md`](https://github.com/0xNyk/council-of-high-intelligence/blob/main/SKILL.md) under the *Output Templates* section, specifying seventeen mandatory Markdown sections for full-mode deliberations.
- Each verdict includes **problem restatement**, **council composition**, **provider routing tables**, **kill criteria**, and **concrete next steps** with specific deadlines.
- The **Vote Tally** section uses weighted voting with domain multipliers and threshold clearance indicators to quantify consensus.
- **Quick** and **Duo** verdict variations retain essential sections while omitting extended analysis fields like Epistemic Diversity Scorecards and detailed compromise lists.
- **Session Metadata** provides machine-readable YAML fields including `schema_version`, `panel_size`, `rounds_run`, and `fallbacks_triggered` for downstream automation.

## Frequently Asked Questions

### Where is the structured output format for council verdicts defined?

The format is encoded in the repository's [`SKILL.md`](https://github.com/0xNyk/council-of-high-intelligence/blob/main/SKILL.md) file under the *Output Templates* section. This file contains the complete execution sequence, template specifications, and routing logic for all deliberation modes.

### What distinguishes the Quick Verdict format from the Full Verdict format?

The Quick Verdict format follows the same structural philosophy but trims sections for brevity. It retains essential fields including Problem, Panel, Chairman, Recommended Action, Kill Criteria, Concrete Next Step, Vote Tally, Key Disagreement, and Session Metadata, while omitting Acceptable Compromises, Key Insights by Member, and Epistemic Diversity Scorecard sections.

### How does the Vote Tally section structure its data?

The Vote Tally displays weighted results from STEP 6, showing each option's total weight, individual backers, domain-weight seat assignments, threshold requirements, and clearance status. For example: "monorepo — 3.5 (Aristotle [1.5×, domain], Ada, Feynman) ✅ cleared 2/3 threshold" with metadata showing W_total and threshold values.

### What fields are included in the Session Metadata YAML block?

The Session Metadata contains machine-readable fields including `schema_version`, `mode` (full/quick/duo), `panel_size`, `rounds_run`, `tools_used`, `provider_count`, `fallbacks_triggered`, `input_tokens_estimate`, `output_tokens_estimate`, and `duration_seconds`, enabling automated tracking and auditing of council deliberations.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}