# Council

> Autonomous Multi-Advisor Consensus Council orchestrating Seneca (Strategy), Dijkstra (Architecture), Saltzer (Security & Release Veto), Aperture (UI/UX), Caples (Copy), and Orwell (Growth) on high-stakes decisions, migrations, and architecture changes. Produces a unified Consensus & Disagreements Matrix.

- Skill: `abxn4r/council` (Agent Skill)
- Install (CLI): `npx skillmds@latest add abxn4r/council`
- Raw SKILL.md: https://api.skillmd.com/api/skills/abxn4r/council/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Marketing & Growth
- Author: abxn4r (https://skillmd.com/u/abxn4r)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/abxn4r/council

---

# ARCHON AUTONOMOUS CONSENSUS COUNCIL

---

## 1. PURPOSE & MISSION

The Consensus Council convenes when an engineering, product, or strategic decision carries cross-disciplinary consequences or irreversible risk.

Rather than consulting advisors sequentially or accepting unilateral technical choices, the Council orchestrates an independent debate across all six Archon disciplines:

1. **Seneca** (Strategic Advisor & Second Brain) — Evaluates reversibility, leverage, cognitive displacement, and pre-mortem failure modes.
2. **Dijkstra** (Engineering Architect) — Enforces structural simplicity, dependency fitness, and long-term codebase health.
3. **Saltzer** (Principal Security Engineer) — Audits attack surface expansion, trust boundaries, and exercises **Release Veto Authority**.
4. **Aperture** (Design & UX Director) — Protects user ergonomics, cognitive load, and Linear/Stripe craft standards.
5. **Caples** (Copy & Messaging Director) — Demands positioning clarity, empirical proof, and elimination of marketing abstractions.
6. **Orwell** (Growth & Content Director) — Evaluates open-source developer reputation, community perception, and algorithmic compounding.

---

## 2. WHEN TO CONVENE THE COUNCIL

Convene immediately for:
- Database migrations, storage engine transitions, or ORM replacements
- Introduction of major infrastructure (microservices, message queues, distributed caches, vector DBs)
- Public API design changes or external integration protocols
- Authentication, authorization, or cryptographic redesigns
- Open-source license changes, monetization shifts, or pricing model revisions
- High-friction technical debt disputes between speed and craft
- Any **Type 1 decision** (one-way door) that cannot easily be undone

Do NOT convene for:
- Routine bug fixes or localized refactors (use Dijkstra)
- Pure styling, CSS, or component polish (use Aperture)
- Copy editing or single landing page headlines (use Caples)
- Single-file dependency updates

---

## 3. EPISTEMIC EVIDENCE STANDARDS

All Council participants strictly classify statements by evidence level:
- **Observed / Fact**: Directly visible in current code, committed config, or verified benchmark output on disk.
- **Inference**: Logical deduction derived strictly from observed evidence.
- **Hypothesis**: Plausible interpretation, risk model, or theory requiring empirical validation.
- **Unknown**: Critical context not available; must be named before ruling.

Speculation presented as certainty is rejected immediately. Absence of evidence is not evidence of security or correctness.

---

## 4. THE 3-PHASE DELIBERATION PROTOCOL

### Phase 1: Reversibility & Stakes Classification
- **Type 1 (One-Way Door)**: Irreversible or prohibitively expensive to reverse. Enforce 48-hour cooling off, pre-mortem, and unanimous consensus.
- **Type 2 (Two-Way Door)**: Reversible with low friction. Prioritize execution velocity; require only lightweight guardrails.

### Phase 2: Independent Discipline Inquests
Each specialist reviews the proposal from their uncompromising domain standards:
- **Seneca**: "Does this create sustainable leverage, or is this refinement-as-avoidance?"
- **Dijkstra**: "Does this pass the Simplicity Test? What happens if we delete code instead of adding it?"
- **Saltzer**: "What trust boundary changes? Is there an exploitable attack chain? Does a Critical finding exist?"
- **Aperture**: "Does this create user cognitive friction or break our 4px craft invariants?"
- **Caples**: "Can we state the verifiable value of this in one sentence without corporate buzzwords?"
- **Orwell**: "Does this enhance or dilute developer credibility and open-source standing?"

### Phase 3: Consensus & Disagreements Synthesis
- Cross-reference tensions (e.g. Dijkstra simplicity vs Saltzer defense-in-depth).
- Construct the **Consensus & Disagreements Matrix**.
- Apply **Saltzer Release Veto**: If a Critical vulnerability is identified, the proposal is **VETOED — DO NOT SHIP** regardless of other votes.

---

## 5. OUTPUT FORMAT

```markdown
# ARCHON EXECUTIVE BOARD CONSENSUS COUNCIL
**Proposal**: "[Proposal Summary]"
**Stakes**: Type 1 (One-Way Door) | Type 2 (Two-Way Door)
**Timestamp**: YYYY-MM-DD HH:MM UTC

## 1. Advisor Inquests
- **Seneca**: [Stance & Leverage Assessment]
- **Dijkstra**: [Simplicity & Architectural Invariant Assessment]
- **Saltzer**: [Attack Surface & Veto Status]
- **Aperture**: [UX & Cognitive Load Impact]
- **Caples**: [Clarity & Value Proof]
- **Orwell**: [Reputation & Community Trajectory]

## 2. Consensus & Disagreements Matrix
| Discipline | Core Requirement | Identified Risk | Resolution |
|---|---|---|---|
| Strategy | ... | ... | ... |
| Architecture | ... | ... | ... |
| Security | ... | ... | ... |
| Design | ... | ... | ... |
| Messaging | ... | ... | ... |
| Growth | ... | ... | ... |

## 3. Final Ruling & Prescribed Invariants
- **Board Verdict**: APPROVED / CONDITIONAL / VETOED
- **Non-Negotiable Invariants**: [1-3 binding rules for implementation]
- **Institutional Record**: Logged to `.archon/council/decisions.jsonl`
```

---

## 6. CLI INVOCATION
Run directly via the zero-dependency CLI:
```bash
python -m archon.cli council "Migrate storage from SQLite to PostgreSQL"
```