Camada L2 · Council

O que o pacote contém

O pacote @alembic/council (em packages/council/src/) implementa: debate.ts (o maker), verifier.ts + verifier-panel.ts (o checker), consensus.ts (quorum + spread), scoring.ts (parse e agregação de notas por eixo) e board.ts (o board loader que ordena os membros e força o contrarian por último).

O ponto central de design: o maker chama modelos e é, por natureza, probabilístico; o checker é uma função pura sobre evidência estruturada (votos, scores, spread, quorum) e nunca re-chama o modelo. É essa assimetria que transforma “o LLM concordou” em “a decisão foi verificada”.

A assinatura que impõe a fronteira

O verifier aceita apenas DebateResult + ContextPack. Não recebe um ModelAdapter, então literalmente não tem como re-chamar um modelo. A fronteira não é uma promessa em comentário — é imposta pelo tipo.

// verifier.ts:19
/** Maker-checker Verifier. READ-ONLY BY ARCHITECTURE.
 *  Aceita só DebateResult + ContextPack. Não pode re-chamar modelo. */

// verifier.ts:84
export type ClaimOracle =
  (evidence: VerifierEvidence) => { proven: boolean; evidence: string };

Um ClaimOracle é uma função pura de VerifierEvidence para { proven, evidence }. É isso que permite ao sistema escrever um VerificationReport auditável, em vez de devolver “o modelo disse que sim”.

O núcleo do loop por membro

// debate.ts:31
/** The DebateEngine. Phases serial, members within phase IN PARALLEL.
 *  Contrarian is forced last by board loader — real sequencing,
 *  not prompt claim. */

// debate.ts:130
const result = await boundMember.adapter.run(input);  // nunca lança
if (!result.ok) { return failure… }
const scores = parseAxisScores(result.text);
const vote = buildVote({ memberId, axes: scores.value, rationale: result.text });

debate.ts:162 — runPhase usa Promise.all para despachar os membros de uma fase em paralelo. As fases entre si permanecem seriais, então a ordenação do board (com o contrarian por último) é respeitada.

O fato de o adapter sempre devolver Result (e nunca lançar) é o que deixa o debate fail-closed sem precisar de try/catch espalhado: um membro que falha é evidência de falha, não um crash.

O contrato do verifier

// verifier.ts:19
/** Maker-checker Verifier. READ-ONLY BY ARCHITECTURE. */

// verifier.ts:49
export const MAX_LOOPS = 3;
// loopCount > 3 → parkedTier = T4 (humano)

// verifier.ts:84
export type ClaimOracle =
  (evidence: VerifierEvidence) => { proven: boolean; evidence: string };

Os oráculos operam sobre VerifierEvidence — uma estrutura derivada de consensus.ts (que conhece MIN_VALID_AGENTS e o spread das notas). Cada oráculo devolve não só proven mas também uma string evidence, que entra no VerificationReport e torna a decisão auditável linha a linha.

verifier.ts:22–37 — o comentário de arquitetura explica a separação maker/checker e por que o verifier é read-only. Vale ler na fonte: é o melhor resumo da filosofia do pacote.

Os pisos e o quorum, na fonte

// verifier-panel.ts:40
export const FAITHFULNESS_CONFIDENCE_FLOOR = 0.5;
export const FAITHFULNESS_STRENGTH_FLOOR = 3;
/** Número padrão de lentes que precisam verificar (de três). */
export const DEFAULT_PANEL_QUORUM = 2;

Cada lente é um VerifierLens: um conjunto de claims mais a lista de quais são hard (hardClaimIds). Em lensVerdict, se qualquer claim hard falha, a lente é rejected; caso contrário, ela só verifica se todos os seus claims passam.

A lente Faithfulness tem hardClaimIds: ['evidence-present'] — então “GO sobre zero evidência” é um hard failure por construção. É essa modelagem que dá força ao veto de preserve-dissent: o quorum agrega, mas um hard failure rejeita o painel inteiro.

verifier-panel.ts:31–33 (comentário): “a HARD failure in ANY lens … rejects the whole panel; otherwise emission needs a quorum of lenses to verify.” Esse é, textualmente, o gate de emissão T3.

Onde isso vive no código

board.ts — o board loader ordena os membros e força o contrarian por último; isso é sequenciamento de execução, não uma instrução de prompt.

consensus.ts — define MIN_VALID_AGENTS e calcula o spread das notas; é a base de evidência sobre a qual os oráculos do verifier operam.

verifier-panel.ts — a agregação por quorum com o preserve-dissent veto: a discordância é reportada no VerificationReport, não eliminada.