SOP-EXEC-council-review-v1.0¶

1. Purpose¶

Mandate council-style impartial review — internal peer review plus external multi-LLM review — for classes of work where author bias could distort judgment. This SOP codifies when to invoke the council-review skill, who participates, how outputs are structured, and how escalation flows when the council is split or surfaces critical issues.

Why this SOP exists: The CEO (Rick Hartley) already uses multiple external LLMs (Gemini, GPT-4o, DeepSeek, Llama) informally as a council on high-stakes work. Without codification, this pattern stays ad-hoc and inconsistent. Bias creeps into research, positioning, and design decisions that affect the business trajectory. Council review catches it before ship.

2. Trigger Matrix¶

When any of these classes of work occur, council review applies at the mandatory / recommended / optional level indicated:

Work type	Council review	Rationale
Research artifacts (market, competitor, industry) before they become canonical	Mandatory	Single-source research is dangerous; multi-LLM sanity check catches factual errors
Design decisions affecting customer-facing UI	Mandatory	UX bias is hard to self-review; external LLMs catch usability assumptions
Category and positioning changes (any edit to `knowledge/company/icp-positioning/` or `knowledge/ip/frameworks/`)	Mandatory	Positioning drift is a known failure mode; impartial review catches over-fitting
Validation Contract authoring where Orchestrator is also the sponsoring executive (per Section 10A.4)	Mandatory	Independence rule extension — orchestrator reviewing own validation contract is bias-prone
Whitepapers and investor materials	Recommended	Time-sensitive, but high-stakes. Skip only if CEO explicitly waives.
Weekly Kickoff priorities (Monday Section 12)	Optional	Useful for quarter-boundary reviews; noise for normal weeks
Agent prompt v2.0+ rewrites (any `system/agents/*/.md` version increment of major version)	Mandatory	Prompt changes affect production; multi-LLM review catches regressions in instruction quality

Decision rule: when in doubt, default to Recommended. The cost of an extra review is low; the cost of shipping biased work is high.

2A. Sensitivity Classification (NEW in v1.1 — CEO directive 2026-04-21)¶

Before invoking council review, the work author classifies the content as HIGH, MEDIUM, or LOW sensitivity. This classification drives council composition (Section 3) and tooling (Section 4).

Classification is mandatory. No silent default. If you are uncertain, escalate to chief.staff before proceeding.

Tier	Content types	Council composition
HIGH	Pricing, positioning, legal/compliance, governance documents (CLAUDE.md, agent contracts, SOPs), investor materials, security-sensitive output	Ollama local models only (`localhost:11434`) — no external API calls
MEDIUM	Research artifacts, design decisions, category framing below positioning-change threshold, internal workflows	GPT-4o acceptable; external APIs allowed
LOW	Optional/recommended reviews, self-check on low-stakes work, preliminary feedback	GPT-4o acceptable; lighter panel (minimum 2 reviewers vs 3)

Sensitivity classification examples¶

Work item	Tier	Rationale
Assessment pricing revision	HIGH	Pricing is explicitly HIGH
SOP authoring or amendment	HIGH	Governance documents
CLAUDE.md Section edits	HIGH	Governance documents
Agent contract major version	HIGH	Governance documents
Competitive landscape research	MEDIUM	Research artifact
MkDocs site layout	LOW (internal tooling)	Internal-only, non-sensitive
Weekly Kickoff priorities	LOW	Optional review tier

2.1 Worked Examples¶

Example A — Orchestrator/sponsor overlap (Trigger row 4, Mandatory): The CDO is both Orchestrator and sponsoring executive on a Mission. He authors the Validation Contract (assertions A1-A12) for a platform refactor. Because he is evaluating the quality criteria for his own department's work, council review is mandatory before the Validation Contract is dispatched to Workers. Two external LLMs (Gemini, GPT-4o) plus one internal peer (chief.staff) review the assertions for completeness, measurability, and whether they inadvertently favor the CDO's preferred architecture.

Example B — Research artifact going canonical (Trigger row 1, Mandatory): category.positioning produces a competitive landscape analysis comparing eco|monetize to Crossbeam, Reveal, and PartnerStack. Before this research moves from /knowledge/research/active/ to /knowledge/research/synthesized/ (canonical status), council review fires. Three LLMs (Gemini, DeepSeek, Llama) plus one internal peer (CRO) check for factual accuracy, cherry-picked comparisons, and whether the analysis overstates eco|monetize's differentiation.

2.2 Trigger Edge Cases¶

Edge case	Resolution
Minor SOP patch (v1.0 → v1.0.1) — does this count as a "positioning change"?	No. Only net-new SOPs or major-version rewrites (v1.0 → v2.0) trigger council review. Patch-level refinements (typo fixes, cross-reference corrections, adding examples) do not qualify.
Agent prompt minor-version update (v1.1 → v1.2) — does trigger row 7 apply?	No. Trigger row 7 specifies "v2.0+ rewrites" — major version increments only. Minor version bumps that refine existing behavior without changing the agent's core mandate are exempt.
CEO-authored work — is council review mandatory?	Recommended but not mandatory. The CEO has final decision authority per Section 6 Authority. Council review is valuable for catching blind spots but cannot be imposed on the CEO. The CEO may self-invoke or waive.
Recommended-tier work under time pressure — can it be skipped?	Yes, with a written waiver. The sponsoring executive files a one-line waiver in the council review archive: "{date} — {topic} — council review waived by {exec} due to {reason}." The waiver itself is the audit trail.

3. Participants¶

Council composition is determined by the sensitivity tier (Section 2A). Both tiers require internal peer review. External LLM selection depends on tier.

Internal reviewers (mandatory — all tiers)¶

At least one peer agent from a different department than the work's originator. Example: a CMO content piece is reviewed by a peer from CDO or CRO.
Chief of Staff observes (non-voting) for governance compliance.

External LLMs — by sensitivity tier¶

HIGH sensitivity (pricing, positioning, legal, governance)¶

Ollama local models only via localhost:11434
No external API calls — all LLM review is conducted on-device
Approved local models: any model available in the local Ollama instance
Minimum 2 local models from different model families for diversity
Never call api.deepseek.com or any external DeepSeek endpoint — local Ollama only

MEDIUM sensitivity (research, design, internal workflows)¶

At minimum two external LLMs from different providers, from this approved set:
OpenAI GPT-4o / GPT-4.1
Google Gemini (via OpenRouter or direct)
Meta Llama (via Together, Fireworks, or direct — not via direct DeepSeek API)
Anthropic Claude (different tier than the originator)
xAI Grok (when available via approved API)
DeepSeek via Ollama local (localhost:11434) only — never api.deepseek.com
Never use two LLMs from the same provider
Never use the same LLM that authored the original work as a reviewer

LOW sensitivity (optional reviews, preliminary feedback)¶

Same approved set as MEDIUM; minimum 2 reviewers (vs 3 for mandatory triggers)
GPT-4o acceptable as primary reviewer

Rationale for tier-based council composition¶

HIGH-sensitivity content (pricing, legal, governance) must not leave the local environment. External APIs transmit content to third-party servers. Ollama local keeps review fully on-device. MEDIUM/LOW content carries lower exposure risk and benefits from provider diversity that local models alone may not provide.

4. Execution Flow¶

Trigger identified — work item matches a mandatory row in the Trigger Matrix (see Section 2.2 for edge case resolution)
Sensitivity classified — work author assigns HIGH / MEDIUM / LOW per Section 2A (mandatory; no silent default)
OLLAMA_TELEMETRY verified (HIGH sensitivity only) — confirm OLLAMA_TELEMETRY=false is set before invoking local models. If not set: warn and exit. Do not proceed until confirmed.
Work author pauses before declaring the work "canonical" or shipping it
Chief of Staff invokes the council-review skill with:
The document or artifact under review (as attachment or inline)
A structured list of review questions (e.g., "Is the positioning coherent?", "Is the research claim supported by the cited sources?", "Does this framework contradict Revenue OS 2.0?")
Sensitivity tier (--sensitivity HIGH|MEDIUM|LOW)
Target LLM list drawn from the tier-appropriate approved set (Section 3)
Skill logs sensitivity tier and council composition used to the session artifact before dispatching
Skill dispatches to all reviewers in parallel, collects responses
Skill returns a consolidated matrix — see Section 5 Output Format
Chief of Staff routes the matrix to the work author and the sponsoring executive
Work author reconciles the feedback, revises if needed, and re-submits for council re-review if revisions are substantive
Sponsoring executive signs off on the final version
Archive — council review artifact saved per Section 8 Archive (must include sensitivity tier and council composition in archive header)

5. Output Format¶

The council-review skill returns a structured matrix:

# Council Review — {topic} — {YYYY-MM-DD}

## Reviewers
- Internal: {agent_id}
- External: {llm_provider/model}, {llm_provider/model}, {llm_provider/model}

## Questions reviewed
- Q1: {question}
- Q2: {question}
- ...

## Per-reviewer responses

### {reviewer_id}
- Q1: {pass/concern/fail} — {explanation}
- Q2: {pass/concern/fail} — {explanation}
- Overall: {recommendation}

## Consolidated matrix

|          | Q1 | Q2 | Q3 | ... | Overall |
|----------|----|----|----|-----|---------|
| Reviewer 1 | ✓ | ⚠ | ✓ | ... | Ship |
| Reviewer 2 | ⚠ | ⚠ | ✓ | ... | Revise |
| Reviewer 3 | ✓ | ✓ | ✓ | ... | Ship |

## Consensus recommendation
{Ship | Revise | Escalate}

## Critical flags
- {any issue flagged by any reviewer that would block ship}

## Author response
*(filled by work author after reviewing the matrix)*

6. Authority¶

The council produces recommendations, not decisions. Final decision rights stay with the sponsoring executive (or CEO for work affecting company strategy).

If the council is unanimous Ship, the work proceeds
If the council is unanimous Revise, the work author revises and re-submits
If the council is split (Ship vs Revise disagreement across reviewers), the sponsoring executive makes the call with a written rationale filed to the council review archive
If the council flags a critical issue (any reviewer marks a Q as Fail with "blocks ship" severity), the sponsoring executive cannot override without CEO approval

No council member has veto power. The matrix surfaces concerns; the executive decides.

7. Escalation Path¶

Council review escalates to the Section 11 Escalation Framework in these cases:

Critical flag raised by any reviewer → Chief of Staff notified, incident severity evaluated
Council split with no clear majority → sponsoring executive decides; if decision is contentious, Chief of Staff escalates to CEO
Pattern of repeated disagreement between a specific reviewer and the work author → surface to Chief of Staff as potential calibration issue (either reviewer is miscalibrated or author is drifting)
Council review consistently surfaces the same type of flag (e.g., "positioning drift" across 3+ reviews) → file Section 6E SOP Delta proposing a new guardrail

Escalation authority clarification: Council review does not create a parallel escalation path. It feeds into the standard Section 11 Escalation Framework. The council produces recommendations; the sponsoring executive decides; unresolved disputes escalate through Chief of Staff to CEO per Section 11. No council member — internal or external LLM — has authority to halt work independently.

8. Archive¶

Every council review output is archived at:

/Claude/operations/reports/council-reviews/{YYYY-MM-DD}-{topic-slug}.md

Archives are read-only after Mission close and serve as: - Audit trail for governance reviews - Historical reference for subsequent council reviews on similar topics - Input to pattern analysis (CoS quarterly review: are councils catching real issues or producing noise?)

Archive filename convention: ISO date + dash + kebab-case topic. Example:

operations/reports/council-reviews/2026-04-20-revenue-os-2-1-framework-revision.md
operations/reports/council-reviews/2026-05-03-eri-category-narrative-q2-update.md

9. Common Failure Modes¶

These are known ways council review can go wrong. Awareness prevents them.

Panel too small or homogeneous. Using only two LLMs from similar training lineages (e.g., two fine-tuned Llama variants) defeats the purpose of provider diversity. Always include at least one LLM known for contrarian output (DeepSeek and Grok tend to diverge from consensus more often).
Vague review questions. Asking "Is this good?" produces useless answers. Questions must be specific and testable: "Does Section 3 contradict the pricing model in the Assessment offer design?" beats "Is Section 3 accurate?"
Ignoring split decisions. When the council is split, the sponsoring executive must file a written rationale for their call. Silently picking the answer you prefer and ignoring the dissent is the exact bias this SOP exists to prevent.
Treating council review as a checkbox. Running the skill, getting a "Ship" consensus, and filing the artifact without reading the per-reviewer detail defeats the purpose. The value is in the specific concerns raised, not just the consensus label.
Stale reviewer pool. Using the same internal peer reviewer for every council review creates familiarity bias. Rotate internal reviewers quarterly per Section 10A.7 validator rotation guidance.

Change log¶

Version	Date	Change
v1.0	2026-04-17	Initial authoring via Mission M-2026-0414-council-review-sop-authoring (first Mission launched under v1.2.1)
v1.1	2026-04-21	CEO-directed amendment (sop.manager): added Section 2A sensitivity classification (HIGH/MEDIUM/LOW), tier-based council composition (HIGH = Ollama local only; MEDIUM/LOW = GPT-4o acceptable), OLLAMA_TELEMETRY=false requirement, DeepSeek external API prohibition (Ollama local only), sensitivity logging requirement added to Execution Flow and Archive sections
v1.0.1	2026-04-19	Worker refinement pass (sop.manager): added worked examples (Section 2.1), trigger edge cases (Section 2.2), common failure modes (Section 9), escalation authority clarification (Section 7), cross-reference to edge cases in execution flow (Section 4), frontmatter reference additions (Section 6E, Section 12), effective date correction

Owner: sop.manager Executive sponsor: chief.staff Approved by: ceo Effective: 2026-04-17 (pending Mission close) Version: 1.1