Everything you actually need at the desk.

The session checklist

• The question is written out in full — not the topic, the question — before any platform is open.
• The stakes actually warrant a session. If one platform would do, route instead of convening.
• The brief has been checked for loading. Any answer is genuinely possible from how it's phrased.
• Output format is specified, so three responses come back comparable.
• Fresh thread on every platform. No reused conversations carrying old assumptions.
• Identical text dispatched to all three before any of them has responded. Documents uploaded, not summarized.
• All responses read before any is evaluated.
• The pattern is mapped: where they agree, where they diverge, what one raised that you hadn't considered.
• Answers split into atomic claims and laid into a ledger, each row marked flagged, unflagged, or verified.
• Factual claims routed for verification — including, especially, the ones all three agreed on. Unflagged is not verified.
• The synthesis is yours, written by you, not merged by a fourth model.
• The session is logged if you'd want to remember it in six months.

Briefs

CONTEXT:
[Who you are, what situation you are in, and what has already been
established or decided. 2–4 sentences. Be specific.]

QUESTION:
[State your question precisely. One question. Specific enough that a
clear answer is possible.]

OUTPUT FORMAT:
[What kind of response you need: a recommendation with reasoning, a
list of options, a structured analysis, a yes/no with explanation.]

NOTE:
Please approach this independently. I am asking the same question of
several platforms and will compare responses before synthesizing.
Where you are uncertain, say so and say why rather than resolving the
uncertainty for me.

CONTEXT:
[Brief description of the plan, decision, or recommendation to be tested.]

TASK:
I have a tentative direction on the above. Before I commit, I want you
to stress-test it. Please:

· Identify the weakest assumptions in my reasoning
· Describe what could go wrong, and how I would know early
· Surface any angles I have not considered
· Tell me what you would need to see to change your assessment

Do not soften this. I need the friction, not reassurance. If the plan is
sound, say so — but only after you have genuinely tried to break it.

VERIFICATION REQUEST:
Please verify the following specific claims before I act on them. Treat
each independently. I am not asking whether they sound reasonable — I am
asking what the source says.

CLAIMS TO VERIFY:
1. [Specific claim — number, date, reference, current status]
2. [Second claim]
3. [Third claim]

For each claim:
· Confirm or correct it
· Provide the source, with enough detail that I can find it myself
· State the date the source reflects
· Flag anything that has changed recently or may be jurisdiction-specific

If you cannot find a source for a claim, say so explicitly rather than
reasoning toward a plausible answer. "Unverified" is a useful result.

DOCUMENT CONTEXT:
[What this document is and why you are analyzing it.]

TASK:
Please analyze the attached document and:
· [Specific question 1 — e.g. identify clauses that could create risk]
· [Specific question 2 — e.g. flag anything that contradicts X]
· [Specific question 3 — e.g. summarize the key obligations in plain language]

Do not summarize the document generally. Focus on the questions above.
Note anything that requires verification against current sources, and
quote the passage you are relying on for each finding.

RECONVENE NOTE:
I ran a session on [original question] on [date]. New information has
arrived that changes the context:

[Describe what changed — new document, new constraint, new development.]

Given this new context, I am returning to the original question:

[Restate the question, updated if necessary.]

Please approach this fresh, without reference to any prior session.

OUTPUT FORMAT:
[Specify as needed.]

QUESTION:

CLAIM                          | CLAUDE | CHATGPT | GROK | STATE
-------------------------------|--------|---------|------|----------
1.                             |        |         |      |
2.                             |        |         |      |
3.                             |        |         |      |
4.                             |        |         |      |
5.                             |        |         |      |

STATE — use exactly three:
  FLAGGED    they disagree; classify and resolve or report
  UNFLAGGED  they agree; NOT checked, NOT settled — a holding state
  VERIFIED   you took it to a source yourself and it held

DIVERGENCE RATE:  __ flagged / __ claims
  A very low rate on a hard question is a warning, not a result.

ODD ONE OUT (which platform, how often):
  A platform that is never the outlier has stopped earning its chair.

CARRIED INTO THE WRITE-UP:
  Only VERIFIED rows carry weight. Unflagged rows are labelled as such.

DATE:
QUESTION (as briefed, verbatim):

PLATFORMS CONSULTED:
  · Claude      — [reasoning mode / research mode used]
  · ChatGPT     — [   ]
  · Grok        — [   ]
  · [Grounded]  — [   ]

WHERE THEY AGREED:

WHERE THEY DIVERGED:
  Type: factual / framing / judgment / time-skew
  Resolution:

RAISED THAT I HADN'T CONSIDERED:

VERIFIED:
  Claim → source → date
UNVERIFIED (flagged, not dropped):

SYNTHESIS (mine):

OPEN ITEMS:

The rules, compressed

The ten Council Rules — the methodology in its most compressed form. Post them, argue with them, return to them when a session goes sideways.

1. The council advises. You decide.

   Every platform can reason about the decision. None of them will live with the outcome. That asymmetry of consequence is why the final call is always yours.

   "The council expands the field of judgment. It does not transfer the burden of it."

2. Brief independently. Always.

   Every platform receives the same prompt, word for word, before any has responded. Not a procedural detail — the structural foundation of the whole method.

   "Identical inputs. Independent outputs. That is the briefing."

3. Neutral phrasing or nothing.

   A loaded prompt produces a loaded answer — not because the platforms are sycophantic, but because you structured the question to make any other answer difficult.

   "If you find yourself rewriting a prompt because it sounds too negative, stop. That instinct is the sycophancy trap from the inside."

4. Divergence is information. Read it.

   Disagreement is a map of genuine uncertainty. Factual splits tell you where to verify; framing splits reveal real conceptual complexity. Quality of disagreement matters more than quantity.

   "The disagreement is the information — it tells you where the genuine uncertainty lives and where you need to look harder."

5. Unanimous confidence is a warning, not a comfort.

   Fast convergence on a question you know is hard is the blind-spot signal. If the error is structural, further deliberation cannot surface it — only your outside perspective can.

   "Not that the answer is certainly right, but that if it is wrong, the council cannot tell you."

6. Verify before you act on what matters.

   Specific numbers, named references, current-status claims, and anything harmful if wrong go through a grounded, source-citing check before they become decisions.

   "Triangulation catches divergence. Verification loops catch confident shared errors. The council uses both."

7. Know when to close.

   A session that never closes is not deliberation — it is avoidance. Convergence, diminishing returns, or a decision already made: any two together mean stop.

   Deliberation serves the decision. It does not replace it.

8. Document the divergences.

   Keep a simple log of where the ensemble agreed, where it diverged, and where your final decision differed from the synthesis.

   That last field — where you overrode the ensemble — is the one that teaches you the most in six months.

9. Invest in the conductorship, not just the tools.

   The limiting factor in human-AI collaboration is not the capability of the platforms. It is the quality of the humans working with them.

   Every failure mode in Chapter 08 is a conductor failure, not a platform failure. That is not a coincidence.

10. The baton was always yours.

    The methodology exists to help you remember to use it. Whether this shapes the future depends on practitioners like you — starting with one disciplined session at a time.

Sources

• Kim, E., Garg, A., Peng, K., & Garg, N. — "Correlated Errors in Large Language Models." arXiv:2506.07962. Over 350 models across two leaderboards and a resume-screening task. The source of the 60%-agreement-in-error figure and the finding that larger, more accurate models have highly correlated errors even across distinct architectures and providers.
  arxiv.org/abs/2506.07962
• Pendarvis, L. Leon — Thinking With AI: The High Council — A Bandleader's Guide to Orchestrating Artificial Intelligence. Pinwheel Productions, Inc. The Council methodology this guide operationalizes: the three cognitive modes, the briefing discipline, the Verification Protocol, the Specialist Protocol, and the Council Rules.
• Platform capabilities. Described as of July 2026 from vendor documentation and current reporting. These change constantly and without notice — treat every capability claim here as a hypothesis to re-audition rather than a fact to rely on.