Council e verifier: debater, pontuar, provar
O motor de decisão L2 é um kernel em camadas: um DebateEngine que preserva a divergência, uma pontuação quantitativa 0–10, um Verifier maker-checker independente e um painel de N lentes que é o gate de emissão a partir de T3. O truque que o torna confiável: contrarian por último e verificação read-only são garantidos pela estrutura, não por prompts. Fonte: packages/council/src/{debate,scoring,consensus,verifier,verifier-panel,board}.ts, governado pela ADR-0003.
O que você vai dominar
- Você já viu a cintura estreita (Lição 14): cada
adapter.run()devolve umModelRunResultdiscriminado emok— nunca lança. - Você já viu as quatro invariantes (Lição 16); a quarta é “o verificador é read-only”. Esta lição mostra onde ela ganha corpo.
- Você sabe o que são
tier(T1…T4) eResult. Não vamos reapresentá-los.
- Explicar por que “o contrarian fala por último” é sequenciamento real, garantido no carregamento do board, e não uma instrução de prompt.
- Ler a pontuação 0–10 corretamente — incluindo por que
risk = 10significa baixo risco e não há inversão. - Prever o veredito de um quorum esparso (a regra
MIN_VALID_AGENTS = 3, fail-closed). - Descrever por que o Verifier é read-only por arquitetura, e como o painel de 3 lentes (quorum e veto) vira o gate de emissão T3+.
O comentário de cabeçalho de debate.ts diz, em código, tudo o que esta lição expande: fases seriais, membros paralelos, contrarian por último por ordenação. Quando a leitura terminar, volte e confira cada afirmação aqui contra o arquivo.
A grande ideia — quem decide não é quem aprova
O Council junta duas coisas que de propósito não confiam uma na outra. De um lado, um debate qualitativo entre membros — o maker, probabilístico, que chama modelos e tem opiniões. Do outro, uma verificação determinística sobre a evidência — o checker, que não chama modelo nenhum e só sabe pesar fatos estruturados. É essa assimetria que permite ao Alembic afirmar “decisão verificada, com dissent preservado” — não apenas “o LLM achou que era uma boa ideia”.
O Council em uma imagem: o maker (terracota) debate e entrega DebateResult + ContextPack em modo só-leitura ao checker (verde-oliva), que prova com oráculos e um painel de lentes.
ModelAdapter — por isso não pode “re-debater”.Por que a separação é estrutural
A confiança não vem de “pedir ao modelo para ser rigoroso”. Vem dos tipos. O maker produz um DebateResult; o checker (verifyDecision / verifyPanel) aceita só esse resultado mais o ContextPack, ambos readonly. Não há parâmetro ModelAdapter na assinatura do checker, então é impossível, no nível do tipo, ele chamar um modelo para mudar de ideia. A garantia é compilada, não prometida.
Esse é o mesmo princípio da Lição 16 (invariante ④): o poder de verificar e o poder de agir ficam em superfícies diferentes. Aqui, “agir” é “chamar o modelo / mudar o veredito” e essa superfície simplesmente não existe no checker.
O DebateEngine — fases seriais, membros paralelos
As fases rodam na ordem declarada pelo board (seriais), e os membros dentro de uma fase rodam em paralelo. Como as fases são seriais, uma fase posterior recebe as contribuições acumuladas das anteriores. É isto que faz “o contrarian vê tudo e fala por último” ser sequenciamento real, e não uma afirmação de prompt. O próprio comentário de cabeçalho do motor diz:
// packages/council/src/board.ts:23-24 — a intenção, verbatim // members WITHIN a phase in parallel; "contrarian last" is enforced by placing // the contrarian phase last here, not by a prompt instruction.
Um board é carregado com a fase contrarian no meio da lista (não por último). O que acontece no carregamento?
buildBoard retorna { kind: 'contrarian_not_last' } e o board é rejeitado. A regra não é checada em runtime do debate — é checada uma vez, na hora de montar o board (board.ts:157-162). Um board mal-ordenado nunca chega a debater.Promise.all (paralelo). Entre fases: serial — por isso o contrarian recebe o acumulado.run() resolve para um ModelRunResult discriminado em ok, então o motor ramifica no resultado em vez de embrulhar a chamada num try/catch. Um membro que falha ao fazer bind, dá erro, ou devolve um voto não-parseável é registrado como um MemberFailureReason — nunca uma exceção lançada.A pontuação — 0–10, e risco não é invertido
Cada membro emite scores por eixo sobre SCORING_AXES (feasibility / revenue / cx / ttm / risk), com pesos .25/.25/.20/.15/.15. GO_THRESHOLD = 7, PIVOT_THRESHOLD = 5. O detalhe de correção não-óbvio: o eixo risk é pontuado de modo que 10 = risco baixo, somando na mesma direção de todos os outros eixos — não há normalização 1 - risk para inverter por engano.
// packages/council/src/scoring.ts — a direção é uniforme; os nomes dos eixos são fonte única de verdade export const SCORING_AXES = ['feasibility', 'revenue', 'cx', 'ttm', 'risk']; // um typo não pode zerar um eixo em silêncio export const GO_THRESHOLD = 7; // score alto → GO export const PIVOT_THRESHOLD = 5; // entre 5 e 7 → PIVOT // risk 10 = risco BAIXO; SEM inversão — todos os eixos somam do mesmo jeito
≥7 GO, 5–7 PIVOT, <5 NO_GO.GO_THRESHOLD (7) → este voto aponta GO.risk = 10. Para a decisão, isso empurra na direção de…1 - risk: 10 significa risco baixo, então soma a favor do GO, igual a feasibility ou revenue alto. Inverter isso viraria toda decisão de cabeça para baixo — por isso a direção é mantida uniforme.Quorum fail-closed — um board degradado nunca aprova
aggregateConsensus devolve NO_GO antes de consultar qualquer score quando há menos de MIN_VALID_AGENTS = 3 votos válidos. “Um board esparso ou degradado nunca pode dar sinal verde.” Um board que perdeu dois membros para falhas de adapter não consegue passar por acidente com um único voto otimista.
// packages/council/src/consensus.ts:104-115 — fail-closed PRIMEIRO // Fail-closed FIRST: if fewer than MIN_VALID_AGENTS votes are present… if (votes.length < MIN_VALID_AGENTS) { return { decision: 'NO_GO', reason: 'insufficient-quorum' }; // score nem é olhado }
O Verifier — read-only por arquitetura
O Verifier maker-checker é a encarnação da invariante ④ (Lição 16). Ele aceita só views readonly, não expõe nenhuma superfície de adapter ou mutação, e prova afirmações atômicas com oráculos determinísticos (ClaimOracle) sobre a evidência estruturada — nunca sobre a prosa do maker:
// packages/council/src/verifier.ts:22, 35, 49 — a arquitetura, verbatim // READ-ONLY BY ARCHITECTURE: the verifier accepts only readonly views — the // debate result and the ContextPack. There is no ModelAdapter parameter. export type ClaimOracle = (evidence: VerifierEvidence) => { readonly proven: boolean; // um oráculo puro: evidência → provado? readonly evidence: string; }; export const MAX_LOOPS = 3; // loopCount > 3 → parked em T4, não retry infinito
- Afirmações duras (quorum presente, verdict↔score consistente, auto-consistência do voto) que falham →
rejected. - Loops limitados: quando a verificação não estabiliza,
loopCount > MAX_LOOPS (3)→ park em T4 (escalate-after-N), não um retry infinito.
DebateResult + ContextPack, ambos readonly. Nenhum ModelAdapter — por isso não pode re-chamar o modelo.ClaimOracle?evidence → { proven, evidence }. Pesa fatos estruturados, sem chamar modelo nem ler a prosa do maker.loopCount > 3?escalate-after-N: a decisão não é forçada — parkedTier = T4 manda para um humano. Sem retry infinito.O painel de N lentes — o gate de emissão T3+
Para T3 e acima, a emissão é barrada por verifyPanel / isPanelEmissionApproved — três lentes de perspectiva diversa agregadas por quorum com um veto preserve-dissent:
O gate de emissão T3: três lentes convergem para um teste de quorum, mas qualquer hard failure dispara o veto preserve-dissent.
| Lente | Verifica |
|---|---|
| COHERENCE | = verifyDecision reusado — quorum, verdict↔score, auto-consistência |
| FAITHFULNESS | evidência presente e acima dos pisos: confiança média ≥ 0.5 e força de pico ≥ 3 |
| DOMAIN | um GO precisa de um sinal de validation; a evidência não é monocultura |
O painel aprova por quorum (padrão DEFAULT_PANEL_QUORUM = 2 de 3) mas um hard rejection em qualquer lente isolada veta o painel inteiro (preserve-dissent), e o escalate-after-N se propaga. Então uma maioria confiante de duas lentes ainda pode ser barrada por uma lente que achou um defeito fatal. Essa conjunção — maioria para passar, qualquer-veto para barrar — é da que depende o verified-GO do funil (Lição 15). Passar é deliberadamente mais difícil do que num voto simples.
Explorar o pipeline ao vivo
Clique pelos quatro estágios — maker → checker → gate T3 → park T4 — e veja qual parte do desenho acende, com o arquivo-fonte de cada um:
Estágio aceso: o maker.
Debate qualitativo (o maker)
packages/council/src/debate.tsO gate, com as suas mãos
Mude o estado de cada lente e ligue/desligue o hard failure. Veja a regra “quorum E sem veto” decidir a emissão em tempo real:
HARD failure. A regra é exatamente !hardFailure && pass >= 2 — a mesma de isPanelEmissionApproved.Confusões comuns
risk = 10 significa risco baixo, então soma na mesma direção de feasibility/revenue. Não há, de propósito, um passo 1 - risk; errar isso inverteria toda decisão, então os eixos são mantidos uniformes e os nomes dos eixos são fonte única de verdade.MIN_VALID_AGENTS = 3) é uma coisa diferente do quorum no painel (DEFAULT_PANEL_QUORUM = 2 de 3 lentes): o primeiro conta votos válidos de membros; o segundo conta lentes que verificam.Pense em duas portas em série. A primeira porta (debate) só abre se houver gente suficiente votando — e de modo coerente. A segunda porta (painel) só abre se a maioria das lentes aprovar e nenhuma puxar o freio de emergência. Para um sinal sair, as duas portas precisam abrir. É de propósito difícil.
Em código: aggregateConsensus faz o gate de quorum (< MIN_VALID_AGENTS → NO_GO) antes de pontuar; verifyDecision prova as claims duras; e verifyPanel/isPanelEmissionApproved exige quorum (≥ DEFAULT_PANEL_QUORUM) e ausência de qualquer HARD failure entre as lentes. O escalate-after-N (MAX_LOOPS = 3) garante terminação: nada gira para sempre — vira park em T4.
Recapitulando — em cinco slides
- Maker ≠ checker. Debate decide; verifier + painel aprovam — e não confiam um no outro.
- Contrarian por último, por ordenação.
contrarian_not_lasté erro de board-load, não um pedido de prompt. - Risco não inverte.
risk = 10= risco baixo; sem passo1 - risk. - Quorum antes do score.
< MIN_VALID_AGENTS (3)→ NO_GO, sem olhar a média. - Quorum E veto. O painel precisa de maioria e nenhum hard failure; senão, preserve-dissent veta ou park T4.
Verifique seu entendimento
MemberFailureReason, não um throw (d).DebateResult + ContextPack, sem adapter — então não pode chamar modelo (b, d) nem é um “voto” (c). Oráculos determinísticos pesam a evidência.