# Calibração de qualidade — as opiniões de BI da skill e a régua bom/ruim

A skill é **opinionada em qualidade de BI, flexível em regra de negócio**: o que
o cliente considera "venda" é decisão dele; que um saldo não se soma no tempo
não é. Nas decisões abaixo a skill SEMPRE declara a recomendação e o porquê
ANTES das opções — nunca apresenta menu neutro.

## Protocolo opinião ↔ flexibilidade (vale para toda decisão estrutural)

1. **Recomende**: opção recomendada primeiro, com o porquê em uma frase de
   consequência ("grain de item aguenta a pergunta que ainda não fizeram").
2. **Se o analista contraria, argumente UMA vez** — com o custo concreto da
   alternativa (tier, retrabalho, perda irreversível), citando caso do
   `anti-portfolio.md` quando houver.
3. **Se ele mantém, registre e siga**: no arquivo da decisão,
   `recomendacao_dada:`, `escolha_analista:` e
   `divergencia_da_recomendacao: <motivo dele, texto livre obrigatório>`.
   Divergência registrada é decisão legítima; a skill não trava por teimosia.
4. **Vago não é override.** "Tanto faz", "você decide", "o de sempre" não
   preenchem `escolha_analista` — vira `hipótese`/`a-perguntar` registrado, sem
   confronto (entrevista.md).

## Defaults opinativos (recomendação sempre declarada)

| Decisão | Default da skill | Porquê / ônus de quem diverge |
|---|---|---|
| Grain | O mais atômico que a fonte suporta | Grain agregado pressupõe as perguntas; atômico aguenta as imprevistas. Divergir = dizer qual pergunta futura está disposto a NÃO responder. |
| SCD | SCD2 para dimensão que participa de métrica reportada por período | Errar para SCD1 = perda irreversível de histórico. SCD1 só com resposta a "por que este atributo nunca precisa de retrato histórico?" (`justificativa_scd1`). |
| RLS | Restritivo por omissão: leitura do próprio registro; nunca acesso irrestrito por falta de resposta | Sem resposta explícita, o fallback gravado no bundle e visível no PDF é o restritivo — abrir depois é fácil; vazar comissão de colega não desfaz. |
| Dimensão | Reusar conformada existente no tenant | Nova custa tier cheio e fragmenta "Cliente"/"Produto" em dois conceitos. Criar nova exige `motivo` registrado + custo em fora-de-escopo.md. |
| Dimensão conformada entre fatos irmãos | Dimensão confirmada num fato do bus matrix é CANDIDATA A REUSO CONFORMADO nos fatos irmãos ANTES de virar `a-perguntar` naquele fato | Mais específico que a linha "Dimensão" acima (que trata do catálogo do tenant): aqui a dimensão já foi decidida dentro do MESMO bus matrix — reabrir a pergunta em cada fato irmão gera retrabalho (defeito PADO). |
| Load type | Decidido pela EVIDÊNCIA (queries 4+8 do profiling), exibida na mesma mensagem das opções | Escolha sem ver a volumetria é clique cego; opção contra a evidência exige `divergencia_da_recomendacao`. |
| Aditividade | Razão/percentual nunca se soma: componentes aditivos + divisão pós-agregação; saldo = LAST/AVG no tempo. **Razão ≠ intensiva:** ticket médio e margem recompõem dos componentes, enquanto temperatura, score e prazo médio aceitam `AVG` de verdade. As duas são "não-aditivas" e pedem agregação oposta | Não é opinião, é aritmética — aqui a skill não cede: card não fecha com aditividade errada. A classe declarada aqui atravessa para a `lumo-design` (que escolhe o sufixo `:SUM`/`:AVG`/`:LAST`) e para a `lumo-mockup` (que decide se a coluna tem linha `Total`). Se `aditividade:` faltar na ficha, as duas param e perguntam. |
| Dimensão cíclica | Mês, dia da semana, hora, trimestre e direção têm **ordem canônica**, não alfabética. Declare `ordem_canonica:` na ficha da dimensão quando o valor vier como texto (`Janeiro`, `Segunda`), e nunca extrapole além do ciclo | Ordenado por texto, `Abril` vem antes de `Janeiro` e a série temporal vira ruído. É um defeito que passa despercebido no mockup (a forma parece certa) e só aparece com dado real. Também barra o eixo que exibe "mês 13". |
| Total × componentes | Uma linha de total ou subtotal **nunca** entra no mesmo conjunto que seus componentes num empilhado, agrupado ou canal de cor. Total é widget separado, linha de rodapé, ou nível pai de `Matrix` | O total soma junto com as partes e o gráfico dobra de tamanho: cada valor aparece duas vezes. Acontece quando a fonte já traz uma linha `Todos`/`Total`/`Consolidado` misturada aos itens, e a leitura visual não denuncia (o eixo só fica "maior"). Checar no profiling da dimensão, não depois do render. |
| Métrica | Só entra com `decisao_associada` respondida ("que decisão humana muda com este número?") | Sem decisão associada é data-vanity: candidata a corte, não a dashboard. Sem resposta, vira `a-perguntar` (candidata a corte) — nunca entra "porque é bonito acompanhar". |
| Tipo de fato | Transacional por padrão; snapshot-acumulativo SÓ com Timeline de marcos nomeados (elicitada quando a dor fala em prazo/SLA/ciclo) | Acumulativo sem marcos nomeados é grain-lista disfarçada; descoberto tarde/num checkpoint custa retrabalho. |
| Patrocinador | Testar força no início/na descoberta (acesso direto? já decidiu sozinho?), não só nomear | Kimball: ~60% do peso de prontidão; patrocínio fraco é o motivo nº1 de projeto travar com escopo perfeito. Sinal fraco → risco registrado, nunca bloqueio. |
| Modelagem por app | Vários fatos, TODAS as dimensões em comum compartilhadas via as MESMAS tabelas conformadas (padrão oficial). Escalar para **fato mestre no tratamento** quando: KPI-razão entre processos, ciclo de vida da mesma entidade, ou cruzamento por dimensão não-comum (`limites-horus.md`) | O gerador de queries é automático: dimensão exclusiva em cruzamento e dimensão-ponte = fanout silencioso (caso real: 61 rels/27 tabelas → 11 versões do app até reconstruir com fato mestre). |
| Dashboard | Uma pergunta por tela; ≤9 widgets; sem pizza sólida (donut até 4 fatias, barra a partir de 5); gauge só para atingimento de meta; temporal = linha; meta vs realizado nunca linha × linha | Regras de integridade de `wireframe-kit.md` (skill `lumo-mockup`) — recondução obrigatória, não preferência. |
| Nº de métricas | Menos e defensáveis > catálogo | 16 métricas que ninguém pediu é o modo clássico de overdelivery (ver anti-portfolio). Na dúvida, a métrica vai para fora-de-escopo com custo, não para o wireframe. |

## Régua bom/ruim — compare ANTES de fechar cada gate

O checklist binário ("tem o campo?") não pega campo preenchido mal. Padrão de
densidade: `references/exemplo-canonico/`.

**Grain**
- RUIM: "Vendas por loja, por produto, por dia" — lista de cortes, não diz o que UMA linha é. Recuse.
- BOM: "Uma linha = um item de pedido faturado" — testável via `COUNT(*) = COUNT(DISTINCT chave)`.

**Dor de negócio**
- RUIM: "visibilidade", "ter os dados na mão", "profissionalizar a gestão" — efeito desejado, não decisão.
- BOM: "decidir reposição por dado em vez de feeling — hoje compra-se 2x/semana no achismo".

**Owner / aprovador / dono de pendência**
- RUIM: "o comercial", "a diretoria", "TI", "cliente" — ninguém responde quando o número está errado.
- BOM: "Marcos Aurélio — Diretor Comercial". Regra global: TODO campo de pessoa
  do bundle (owner, aprovador, RACI, dono de registro `a-perguntar`) exige pessoa
  nomeada; termo genérico reprova no auto-review.

**Inclusões/exclusões de métrica**
- RUIM: "tudo que for válido", "nada especial" — passa no checklist, não trava nada.
- BOM: valores de domínio REAIS vindos da query 7 do profiling: "STATUSNOTA='L'; exclui 'A','C' e TIPMOV='B' (bonificação)".

**Cadência**
- RUIM: `cadencia: diaria` por hábito.
- BOM: `decisao_associada: "pauta da reunião diária de expedição às 7h30"` →
  cadência D-1 até 7h. Sem decisão associada, cadência não se preenche.

**Item de fora-de-escopo**
- RUIM: "Drill-down: não incluído."
- BOM: "Drill até vendedor individual: fora — a pergunta pára em ranking por
  equipe; incluir custaria +1 tier (Matrix). Pedido pós-assinatura = change
  request."

**Item de aceite**
- RUIM: "os dados devem bater com o sistema".
- BOM: "Receita Líquida do dashboard vs SUM na origem filtrado STATUSNOTA='L':
  diferença ≤0,5% → verificar: `lumo app query ...` vs `lumo credential query ...`".

**Calibrações de frequência** (produção real, 560 tenants vivos): Incremental é
raro (14% dos flows; Total 59% + Temporal 27% dominam — não induza Incremental
sem tracking provado); bridge N:N é raro (0 na maioria dos tenants — não force
justificativa de ausência); todo dashboard tem KPI-row (só 56% da produção tem —
é a lacuna real, não a posição, que 95% acertam quando o KPI existe).

**Evidência de profiling**
- RUIM: `Resultado: 1.842.006 ≠ 1.790.311 | Status: Validado` — contradição interna; ou amostra com LIMIT tratada como prova de unicidade.
- BOM: resultado que PROVA a decisão, ou `Status: Premissa não validada — risco` + mitigação.
