Hot Path: Council T3 + Verifier Panel — o Gate de Emissão

Fluxo T3 (SVG)

Estágios do T3 (Stepper)

108|const bound = bindMember(member, options.adapters);
130|const result = await boundMember.adapter.run(input);
147|const scores = parseAxisScores(result.text);
153|const vote = buildVote({ memberId, axes: scores.value, rationale: result.text });

// 5 eixos: feasibility, revenue, cx, ttm, risk (risk invertido)
// GO ≥ 7.0 | PIVOT ≥ 5.0
// aggregateConsensus exige MIN_VALID_AGENTS=3 + spread baixo

84|export type ClaimOracle = (evidence: VerifierEvidence) => { proven: boolean; evidence: string };
...
// oráculos determinísticos sobre votos, scores, spread, quorum
// NUNCA lê o rationale em prosa do maker

// Lente 1: COHERENCE (reusa verifyDecision)
// Lente 2: FAITHFULNESS (evidence presente + confidence ≥ 0.5 + strength ≥ 3)
// Lente 3: DOMAIN (GO precisa de validation evidence + diversidade)

DEFAULT_PANEL_QUORUM = 2
MAX_LOOPS = 3
// loopCount > 3 → parkedTier = T4 (humano obrigatório)

Anotações Linha-a-Linha Críticas

Como Verificar Este Hot Path

# No contexto de um run T3 (normalmente via harness ou factory)
# Inspecione o VerificationReport e LensReport

# Chaves para olhar:
# - verdict === 'verified'
# - provenCount / totalClaims por lente
# - parkedTier (se presente = T4)
# - hardClaimIds que falharam

Common Confusions + Practice Task

Confusão 1: "O verifier é só mais um LLM julgando". Falso. É um checker programático com oráculos determinísticos que só olham evidência estruturada (votos, scores, spread, quorum). O texto livre do debate nunca é usado como prova (ver verifier.ts:31-32: "The maker's rationale text is never trusted as proof").

Confusão 2: "Panel é só rodar o verifier 3 vezes". Falso. Cada lente (coherence, faithfulness, domain) tem claims diferentes e oráculos diferentes. Isso dá diversidade de perspectiva que múltiplas runs do mesmo verifier não dariam.

Confusão 3: "T3 sempre emite". Falso. Qualquer hard failure em qualquer lente + falta de quorum = não emite. Ou parked em T4 após 3 loops.

Prática: 1. Leia council/src/verifier.ts:84-92 (ClaimOracle definition) e verifier.ts:19-37 (comentário de arquitetura maker-checker). 2. Veja como verifyDecision decompõe a decisão em claims atômicos com oráculos puros. 3. Rode um council T3 real (via harness em um run de ETL ou teste) e capture o VerificationReport + LensReport completo. 4. Identifique manualmente qual claim hard falhou em um caso de NO-GO ou parked.

Exercício avançado: Por que o painel usa 3 lentes diferentes em vez de rodar o mesmo verifier 3 vezes? Qual o risco de não ter o preserve-dissent veto? O que aconteceria se o verifier pudesse chamar modelo novamente?

Fontes para aprofundamento: council/src/debate.ts:108-159 (fluxo completo de um membro, bind + run + parse), council/src/scoring.ts (limiares GO/PIVOT e pesos dos 5 eixos), council/src/consensus.ts (MIN_VALID_AGENTS=3 e spread threshold), council/src/context-pack.ts (como o pack chega ao verifier e é usado nas lentes de faithfulness), council/src/board.ts (como os membros e workflows são carregados de YAML).

Este hot path é o principal mecanismo de qualidade do sistema em tiers pagos. Quase todo sinal de negócio de alto valor passa por ele. Entender suas ~400 linhas de lógica de verificação é entender por que o Alembic pode afirmar "decisões com dissent preservado e grounded evidence" em vez de "LLM achou que era boa ideia".

Deep walkthrough adicional: Em debate.ts:130 o adapter é chamado. O resultado vai para parseAxisScores (response.ts). Depois buildVote (scoring.ts). O conjunto de votos vai para verifyDecision (verifier.ts), que constrói VerifierEvidence e roda os oráculos. O resultado vai para o panel em verifier-panel.ts, que aplica as 3 lentes (coherence reutiliza verifyDecision; faithfulness e domain têm seus próprios CheckedClaim + oráculos). O agregador final aplica quorum + preserve-dissent. Se loopCount > MAX_LOOPS (verifier.ts:49), parkedTier = escalateTier(T3) → T4. Todo esse fluxo é puro em relação a efeitos colaterais de modelo — a única coisa que toca LLM é o debate maker inicial. Isso é o que permite afirmar que o gate T3 é mais confiável que um simples "LLM decide". A separação maker/checker + oráculos determinísticos + multi-lens panel é uma das contribuições arquiteturais mais importantes do projeto para tomada de decisão de alto custo e alto valor. Dominar estas linhas é essencial para qualquer pessoa que queira estender ou auditar o sistema de decisão do Alembic em produção real hoje.