Documento de construção
PRD recebido no pacote de 2026-09-18. Ver Análise PRDs × v0.3 antes de implementar: a taxonomia deste pacote ainda está em conflito com as notas do v0.3.
Orquestro
Incremento 07 — Inteligência e Aprendizado
Código: Orquestro-LRN
Versão: 1.0 — Freeze Candidate
Dependências: Incrementos 1–6
Início: dados reais acumulados no ciclo comercial
Fim: informação → padrão → hipótese → teste → aprendizado → possível mudança humana
Novo Human Gate comercial: nenhum
1. Objetivo
O Orquestro não termina quando uma oportunidade vira WON, LOST ou PARKED.
A última pergunta do produto é:
O que podemos aprender com aquilo que aconteceu nas nossas vendas?
O sistema deve aprender com:
- quem entrou;
- quem avançou;
- quem não avançou;
- necessidades encontradas;
- soluções sugeridas;
- sugestões aceitas, ajustadas e rejeitadas;
- propostas;
- preços;
- condições;
- negociações;
- ganhos;
- perdas;
- negócios estacionados;
- recorrência;
- novas propostas;
- indicações;
- reativações.
A IA pode pesquisar, organizar, comparar, identificar padrões, levantar hipóteses e sugerir testes.
A validação do aprendizado e qualquer mudança relevante continuam humanas.
2. Regra central
Dado
↓
Padrão observado
↓
Hipótese
↓
Sugestão
↓
Humano decide que vale testar
↓
Teste
↓
Resultado
↓
Learning
↓
Possível mudançaRegras:
Padrão não é verdade.
Hipótese não é aprendizado.
Learning não é regra automática.
O sistema nunca muda sua metodologia silenciosamente.
3. Duas camadas de aprendizado
3.1 Aprendizado comercial do cliente Orquestro
Exemplo:
“As oportunidades vindas de indicação estão chegando à proposta mais rápido.”
Esse aprendizado pertence à empresa que usa o Orquestro.
3.2 Aprendizado do próprio produto Orquestro
Exemplo:
“Usuários estão ajustando frequentemente a primeira sugestão de Solution.”
Esse aprendizado pertence à evolução do produto/metodologia.
As duas camadas não devem ser misturadas.
4. Jornada do Incremento
dados do ciclo
↓
Dashboard
↓
Resumo em uma página
↓
Padrões observados
↓
O que merece atenção?
↓
Possível hipótese
↓
Vale testar?
↓
humano decide
↓
teste
↓
resultado
↓
Learning
↓
manter / descartar / investigar mais
↓
possível mudança proposta
↓
humano aprova ou rejeita5. Dashboard comercial
Tela:
Como está seu comercial?
O Dashboard deve priorizar poucos indicadores úteis.
Blocos recomendados:
Movimento comercial
Leads → Needs → Opportunities → Propostas → Won/Lost/Parked
Ciclo
Onde demora mais.
Negócios
Ticket, condições e propostas.
Ofertas
O que vende e quanto consome.
Mercado
Quem está avançando e comprando.
Atenções
Gargalos, pendências e capacidade.
Regra:
Não transformar o Dashboard em painel de vaidade.
6. One Page executivo
Alternativa ao Dashboard:
Resumo do período
Estrutura:
O que aconteceu
O que está funcionando
Onde estamos perdendo tempo
O que merece atenção
Oportunidade para investigar
Próximo teste sugerido
Permitir:
- mês;
- trimestre;
- período personalizado.
Não comparar períodos incomparáveis sem aviso.
7. Tempo do ciclo
Acompanhar:
ciclo médio
Lead → Need Validated
Need Validated → Pré-Proposta
Pré-Proposta → Proposta
Proposta → DecisãoPergunta:
Onde suas vendas estão levando mais tempo?
Exemplo adequado:
A maior parte do ciclo está acontecendo depois da proposta.
Não:
Seu processo de proposta está errado.
Tempo maior pode ser sinal, não conclusão automática.
8. Conversão
Acompanhar:
Leads
↓
Needs validados
↓
Opportunities
↓
Pré-Propostas
↓
Propostas
↓
Won
Lost
ParkedConversão não é sinônimo de qualidade.
Venda fechada também não prova negócio saudável.
9. Ofertas
Analisar:
- mais vendida;
- maior faturamento;
- maior ticket;
- maior recorrência;
- maior esforço;
- mais fácil de fechar;
- ciclo;
- capacidade consumida;
- contrapropostas;
- perdas.
Exemplo:
Oferta A gera mais faturamento.
Oferta B exige menos esforço e apresenta maior recorrência.
O sistema mostra os fatos.
Não decide automaticamente qual oferta deve ser priorizada.
10. Origem dos negócios
Comparar:
- indicação;
- networking;
- evento;
- inbound;
- outbound;
- cliente atual;
- ex-cliente;
- outros.
Não apenas por volume.
Também comparar:
- conversão;
- ticket;
- duração do ciclo;
- recorrência;
- qualidade percebida;
- esforço.
11. Mercado e perfis
O Orquestro pode observar padrões transversais como:
- porte;
- empresa familiar;
- crescimento;
- sucessão;
- maturidade;
- estrutura de liderança;
- decisor próximo da operação;
- tamanho da equipe;
- tipo de necessidade;
- recorrência;
- origem;
- modelo de negócio.
Sempre como:
Isso apareceu nos seus dados. Vale observar?
Nunca como nova verdade automática ou alteração automática de ICP.
12. Bom cliente × realidade observada
Comparar percepção inicial com dados posteriores.
Exemplo:
Percepção inicial:
“Cliente estratégico”
↓
Histórico real:
recomprou
indicou
bom ticket
baixo retrabalho
boa relaçãoou:
Percepção inicial:
“Ótimo cliente”
↓
Histórico real:
preço apertado
alto esforço
muito retrabalho
sem continuidadeO Orquestro ajuda a confrontar percepção com evidência.
13. Clientes problemáticos
Possíveis sinais recorrentes:
- escopo muda muito;
- esforço alto;
- retrabalho;
- preço apertado;
- pagamento problemático;
- relação difícil;
- pouca autonomia;
- pouco potencial de continuidade.
Nunca criar blacklist automática.
Padrão observado continua sendo objeto de interpretação humana.
14. Ganhos
Aprender com os motivos conhecidos de fechamento.
Possíveis sinais:
- confiança;
- solução;
- indicação;
- relacionamento;
- expertise;
- prazo;
- condição;
- preço.
Pergunta:
O que apareceu nos negócios que ganhamos?
Não apenas:
Quantos ganhamos?
15. Perdas
Analisar:
- preço;
- timing;
- orçamento;
- prioridade;
- concorrência;
- solução interna;
- valor percebido insuficiente;
- escopo;
- decisão interna;
- outros;
- motivo desconhecido.
“Desconhecido” continua sendo dado válido.
Nunca preencher automaticamente motivo ausente.
16. Parked
PARKED deve ser analisado separadamente de LOST.
Pode ensinar:
- por que não era o momento;
- o que precisava mudar;
- tempo médio até retomada;
- quantos foram reativados;
- quantos viraram Opportunity novamente;
- quantos fecharam depois.
17. Relacionamento com a carteira
Considerar:
ACTIVE
INACTIVE_WITH_POTENTIAL
INACTIVEAnalisar:
- clientes ativos que geram novas Opportunities;
- clientes ativos que recompram;
- inativos com potencial que são retomados;
- inativos que são reativados;
- clientes que indicam novos leads.
Status de relacionamento não deve ser confundido com resultado de uma única Opportunity.
18. Potencial estratégico previsto × realizado
No Incremento 5 registramos:
- recorrência potencial;
- nova proposta;
- cross-sell;
- expansão;
- indicação;
- novos decisores;
- entrada estratégica.
Agora podemos observar o que realmente ocorreu.
Exemplo:
Potencial de expansão: Alto
Confiança: Média
↓
8 meses depois
nova Opportunity em outra unidadeOu:
Potencial de indicação: Alto
↓
nenhuma indicação observada até agoraImportante:
Ainda não aconteceu não significa automaticamente hipótese errada.
Preservar a janela de observação.
19. Preço sugerido × definido × apresentado × aceito
Registrar:
Preço sugerido pela IA
↓
Preço definido pelo humano
↓
Preço apresentado
↓
Preço final aceitoIsso permite observar diferenças recorrentes.
Mas o sistema não conclui automaticamente:
“A IA estava certa.”
ou:
“O vendedor estava errado.”
O padrão pode gerar hipótese para investigar.
20. Condição inicial × contraproposta × condição final
Registrar:
condição inicial
↓
contraproposta
↓
condição finalAnalisar:
- parcelamento;
- escopo;
- prazo;
- fases;
- forma de entrega;
- responsabilidades.
Padrão de negociação não vira desconto automático.
21. Solution sugerida × Solution validada
Registrar:
Solution sugerida pela IA
↓
aceita?
ajustada?
rejeitada?Quando houver ajuste:
por quê?
Preservar diferença entre versão sugerida e versão validada.
22. Qualidade das sugestões da IA
Pode medir:
- sugestão aceita sem mudança;
- aceita com ajustes;
- rejeitada;
- motivo do ajuste;
- etapa em que mais ocorrem correções.
Exemplo:
Pesquisa pré-abordagem útil
Solution sugerida muito ajustada
Precificação frequentemente mantida
Follow-up frequentemente editadoNão transformar isso em “nota de inteligência” opaca.
23. Métricas especiais de aprendizado
Registrar:
- sugestões rejeitadas;
- sugestões ajustadas;
- motivo do ajuste;
- preço sugerido × definido;
- preço definido × aceito;
- contrapropostas;
- condição inicialmente proposta × final;
- Solution sugerida × aprovada;
- motivos de perda.
Essas métricas são parte obrigatória do aprendizado.
24. Métricas de uso e eficiência
Uso
- usuários ativos;
- Leads processados;
- Opportunities;
- propostas geradas;
- retornos ao sistema.
Eficiência
- tempo de preparação;
- tempo de criação de proposta;
- redução de retrabalho, quando houver base comparável;
- tempo de consolidação pós-reunião.
Qualidade percebida
- utilidade da pesquisa;
- preparação;
- Solution sugerida;
- precificação;
- roteiros.
Comercial
- Needs validados;
- propostas;
- ganhos;
- perdas;
- ciclo.
Proteção:
Não atribuir causalidade ao Orquestro sem desenho de validação.
25. Gargalos
Tela:
Onde parece haver um gargalo?
Exemplos:
Muitos Leads entram, mas poucos chegam à necessidade validada.
Muitas Opportunities chegam à proposta, mas ficam aguardando decisão.
A capacidade da especialista principal está limitando novos negócios.
Sempre distinguir:
DADO
↓
INSIGHT
↓
HIPÓTESE26. Dado, padrão, hipótese e teste
A interface pode traduzir TruthMode assim:
O que aconteceu
Dado.
O que apareceu nos dados
Padrão.
Uma possível explicação
Hipótese.
O que poderíamos testar
Sugestão.
27. De padrão para hipótese
Exemplo:
Padrão observado:
Propostas vindas de indicação apresentam ciclo menor nesta amostra.Hipótese sugerida:
Talvez a confiança transferida pela indicação esteja reduzindo parte do ciclo.Padrão e hipótese permanecem separados.
28. De hipótese para teste
Tela:
Vale testar isso?
Exemplo:
Hipótese
Leads indicados parecem avançar mais rápido.
Teste sugerido
Durante as próximas Opportunities indicadas, registrar explicitamente nível de confiança inicial e comparar com outras origens.
Botões:
- Vale testar
- Não agora
- Descartar hipótese
Humano decide.
29. PatternObservation
PatternObservation
id
organization_id
topic
description
period_start
period_end
sample_size
evidence_refs[]
scope
limitations[]
status
created_at
reviewed_by
reviewed_atStatus:
OBSERVED
REVIEWED
DISMISSED30. LearningHypothesis
LearningHypothesis
id
organization_id
pattern_id
statement
supporting_evidence[]
contradicting_evidence[]
limitations[]
status
created_by_ai
reviewed_by
reviewed_atStatus:
SUGGESTED
APPROVED_FOR_TEST
REJECTED31. LearningTest
LearningTest
id
organization_id
hypothesis_id
question
test_description
start_at
end_at
success_observation
data_to_collect[]
status
created_by
approved_byO MVP não exige desenho estatístico sofisticado.
Exige teste rastreável.
32. Resultado do teste
Estados:
SUPPORTS_HYPOTHESIS
DOES_NOT_SUPPORT
INCONCLUSIVENa tela:
- Os dados apoiaram a hipótese
- Os dados não apoiaram a hipótese
- Ainda não dá para concluir
Evitar Verdadeiro/Falso.
33. Learning
Learning
id
organization_id
hypothesis_id
test_id
statement
evidence_refs[]
limitations[]
status
validated_by
validated_atExemplo adequado:
Nesta amostra, Opportunities indicadas chegaram à proposta em menos tempo que Opportunities outbound.
Evitar:
Indicação sempre vende mais rápido.
Learning exige validação humana.
34. Proposed Change
Um Learning pode sugerir uma mudança.
Exemplo:
Dar mais prioridade comercial a indicações qualificadas.
Mas não altera nenhuma regra automaticamente.
ProposedChange
id
organization_id
learning_ids[]
area
MARKET
OFFER
SALES_PROCESS
PRICING
CAPACITY
COMMUNICATION
PRODUCT
METHODOLOGY
description
expected_effect
status
proposed_by
approved_by
approved_at
implemented_atStatus:
DRAFT
IN_REVIEW
APPROVED
REJECTED
IMPLEMENTED35. Mudanças que a IA não pode fazer sozinha
Nenhum Learning pode automaticamente:
- mudar ICP;
- alterar preço-base;
- reclassificar ofertas;
- mudar regras de Business Fit;
- alterar metodologia;
- classificar tipo de cliente;
- modificar scripts;
- mudar Human Gates;
- alterar pesos/heurísticas relevantes.
O sistema propõe.
Humano decide.
36. Amostra e confiança
Sempre mostrar:
Casos analisados: X
Período: ...Quando necessário:
Amostra pequena. Trate como sinal para observar.
Não congelar número mágico de casos para definir um padrão.
37. Evidência contrária
Um PatternObservation deve poder guardar evidências que sustentam e evidências que contrariam a hipótese.
Não precisamos criar falsa uniformidade.
38. Aprendizados por dimensão
Organizar em seis gavetas:
Mercado
Quem parece aderir melhor?
Oferta
O que vende, gera valor e consome esforço?
Origem
De onde vêm negócios mais interessantes?
Processo comercial
Onde avançamos ou travamos?
Negócio
Preço, condição, capacidade e esforço.
Inteligência Orquestro
Onde as sugestões da IA ajudam ou são corrigidas?
39. Aprendizado de preço
Perguntas possíveis:
- Estamos frequentemente abaixo da faixa sugerida?
- Valores acima da faixa também são aceitos?
- Que condições aparecem junto?
- Quais ofertas sofrem mais contraproposta?
- Qual diferença entre preço definido e aceito?
Sem transformar correlação em causalidade.
40. Aprendizado de capacidade
Cruzar:
oferta
+
esforço previsto
+
esforço observado, quando disponível
+
capacidade
+
resultado comercialSe esforço real não estiver disponível:
não inventar.
41. Aprendizado de recorrência
Cliente ativo
↓
nova Opportunity?
↓
nova Proposal?
↓
novo contrato?Isso diferencia primeira compra de relacionamento comercial recorrente.
42. Aprendizado de indicação
Preservar quando:
Cliente A
↓
indicou
↓
Lead BObservar:
- quem indica;
- quantas indicações viram Need;
- quantas viram Opportunity;
- quantas viram Proposal;
- quantas viram contrato.
Sem score de influência automático no MVP.
43. Aprendizado de reativação
Para INACTIVE_WITH_POTENTIAL:
data prevista
↓
reativação ocorreu?
↓
Opportunity criada?
↓
WON / LOST / PARKED?Isso ajuda a testar se o feeling de “pode fechar mais tarde” se sustentou.
44. Dashboard não é BI gigante
O Orquestro não vira ferramenta genérica de BI.
Princípio:
Poucos indicadores + explicação + ação possível.
45. Cliente Zero
A LC Verum funciona como Cliente Zero.
Objetivos:
- percorrer fluxo inteiro;
- registrar fricções;
- medir esforço;
- identificar gaps;
- testar saídas;
- verificar utilidade.
Cliente Zero não equivale a validação externa.
46. Pilotos externos
Depois do fluxo mínimo navegável.
Registrar:
Evidence
↓
Learning
↓
Proposed ChangeNão alterar produto por impressão isolada.
47. Aprendizado do produto
As métricas especiais podem ajudar a entender:
Pesquisa
Usuários aproveitam ou descartam?
Solution
Quanto a direção inicial precisa ser ajustada?
Precificação
Quanto preço sugerido difere do definido?
Condições
Quais cenários precisam mais ajuste?
Roteiros
São utilizados e considerados úteis?
Follow-up
A sugestão realmente ajuda?
Esse aprendizado serve para melhorar produto e metodologia, sempre com validação humana.
48. Não atribuir causalidade
Se:
antes do Orquestro
taxa de fechamento = X
depois
taxa de fechamento = Yo sistema não pode concluir:
Orquestro causou o aumento.
Pode dizer:
A taxa observada neste período foi maior que no período anterior.
Causalidade exige desenho de validação específico.
49. O que não entra no Incremento 7
- Machine Learning preditivo;
- previsão automática de fechamento;
- scoring opaco;
- benchmark avançado;
- IA alterando a própria metodologia;
- mudança automática de ICP;
- otimização autônoma de preço;
- agentes comerciais autônomos;
- Customer Success completo;
- fidelização automatizada.
50. Objetos novos
CommercialMetricSnapshot
DashboardView
OnePageReport
PatternObservation
LearningHypothesis
LearningTest
LearningTestResult
Learning
ProposedChange
AIContributionMetric
StrategicPotentialOutcomeReutilizados:
Lead
Need
Opportunity
Solution
BusinessFit
PricingScenario
Proposal
CommercialDecision
LossReason
ParkedContext
ContractRecord
CustomerRelationship
SalesToDeliveryHandoff
CommercialEvidence
AuditEvent51. Permissões
Usuário comercial
Pode ver Dashboard, One Page e aprendizados permitidos da própria organização.
Responsável autorizado
Pode aprovar:
- teste;
- Learning;
- Proposed Change;
- implementação de mudança relevante.
Sem criar burocracia excessiva para simples consulta.
52. Rastreabilidade
Eventos importantes:
METRIC_SNAPSHOT_CREATED
PATTERN_OBSERVED
PATTERN_REVIEWED
PATTERN_DISMISSED
HYPOTHESIS_SUGGESTED
HYPOTHESIS_APPROVED_FOR_TEST
HYPOTHESIS_REJECTED
LEARNING_TEST_STARTED
LEARNING_TEST_COMPLETED
LEARNING_RECORDED
LEARNING_VALIDATED
PROPOSED_CHANGE_CREATED
PROPOSED_CHANGE_APPROVED
PROPOSED_CHANGE_REJECTED
PROPOSED_CHANGE_IMPLEMENTEDPreservar a cadeia:
Evidence
→ Pattern
→ Hypothesis
→ Test
→ Learning
→ Proposed Change53. TruthMode do aprendizado
DADO:
7 de 10 Opportunities Won vieram de indicação.
→ EVIDENCEPADRÃO:
Indicações aparecem com mais frequência entre Won nesta amostra.
→ PATTERN_OBSERVATIONHIPÓTESE:
Confiança transferida pela indicação pode ajudar no avanço.
→ AI_HYPOTHESISTESTE:
Observar próximas Opportunities registrando nível de confiança inicial.
→ HUMAN_APPROVED_TESTRESULTADO:
O padrão voltou a aparecer.
→ TEST_RESULTAPRENDIZADO:
Nesta amostra, indicações apresentam associação com ciclos menores.
→ HUMAN_VALIDATED_LEARNINGNunca:
Indicação sempre fecha mais.
54. Requisitos Funcionais
A. Fundamentos do aprendizado
| ID | Requisito | Prioridade |
|---|---|---|
| LRN-REQ-001 | O aprendizado deve utilizar dados produzidos pelos Incrementos 1–6. | MUST |
| LRN-REQ-002 | O sistema deve preservar a origem das informações utilizadas. | MUST |
| LRN-REQ-003 | Evidência deve permanecer distinguível de percepção. | MUST |
| LRN-REQ-004 | Percepção deve permanecer distinguível de hipótese. | MUST |
| LRN-REQ-005 | Hipótese deve permanecer distinguível de Learning validado. | MUST |
| LRN-REQ-006 | Padrão observado não pode virar verdade automática. | MUST |
| LRN-REQ-007 | Learning não pode virar regra automática. | MUST |
| LRN-REQ-008 | Mudança de metodologia não pode ocorrer silenciosamente. | MUST |
| LRN-REQ-009 | IA pode identificar padrões. | MUST |
| LRN-REQ-010 | IA pode levantar hipóteses. | MUST |
| LRN-REQ-011 | IA pode sugerir testes. | MUST |
| LRN-REQ-012 | IA pode organizar resultados. | MUST |
| LRN-REQ-013 | IA não valida Learning sozinha. | MUST |
| LRN-REQ-014 | IA não aprova Proposed Change sozinha. | MUST |
| LRN-REQ-015 | O sistema deve preservar limitações da análise. | MUST |
B. Dashboard comercial
| ID | Requisito | Prioridade |
|---|---|---|
| LRN-REQ-016 | Disponibilizar Dashboard de visão contínua. | MUST |
| LRN-REQ-017 | Dashboard deve priorizar poucos indicadores úteis. | MUST |
| LRN-REQ-018 | Evitar painel de vaidade. | MUST |
| LRN-REQ-019 | Permitir filtro por período. | MUST |
| LRN-REQ-020 | Permitir período mensal. | MUST |
| LRN-REQ-021 | Permitir período trimestral. | MUST |
| LRN-REQ-022 | Permitir período personalizado. | MUST |
| LRN-REQ-023 | Mostrar volume de Leads. | MUST |
| LRN-REQ-024 | Mostrar Needs validados. | MUST |
| LRN-REQ-025 | Mostrar Opportunities. | MUST |
| LRN-REQ-026 | Mostrar pré-propostas. | MUST |
| LRN-REQ-027 | Mostrar propostas. | MUST |
| LRN-REQ-028 | Mostrar Won. | MUST |
| LRN-REQ-029 | Mostrar Lost. | MUST |
| LRN-REQ-030 | Mostrar Parked. | MUST |
| LRN-REQ-031 | Mostrar Decision Pending quando útil. | MUST |
| LRN-REQ-032 | Mostrar principais gargalos. | MUST |
| LRN-REQ-033 | Mostrar propostas aguardando decisão. | MUST |
| LRN-REQ-034 | Mostrar capacidade quando pertinente. | MUST |
| LRN-REQ-035 | Cada indicador deve permitir contexto suficiente para interpretação. | MUST |
C. One Page executivo
| ID | Requisito | Prioridade |
|---|---|---|
| LRN-REQ-036 | Disponibilizar One Page como alternativa ao Dashboard. | MUST |
| LRN-REQ-037 | Permitir gerar One Page por período. | MUST |
| LRN-REQ-038 | Incluir O que aconteceu. | MUST |
| LRN-REQ-039 | Incluir O que está funcionando. | MUST |
| LRN-REQ-040 | Incluir Onde estamos perdendo tempo. | MUST |
| LRN-REQ-041 | Incluir O que merece atenção. | MUST |
| LRN-REQ-042 | Incluir Oportunidade para investigar. | MUST |
| LRN-REQ-043 | Incluir Próximo teste sugerido quando houver base. | MUST |
| LRN-REQ-044 | Não obrigar existência de teste sugerido. | MUST |
| LRN-REQ-045 | One Page deve usar linguagem simples. | MUST |
| LRN-REQ-046 | Não expor taxonomia interna desnecessariamente. | MUST |
| LRN-REQ-047 | Comparações entre períodos devem informar diferenças relevantes de amostra. | MUST |
D. Tempo do ciclo
| ID | Requisito | Prioridade |
|---|---|---|
| LRN-REQ-048 | Calcular ciclo comercial médio quando houver dados suficientes. | MUST |
| LRN-REQ-049 | Calcular Lead → Need Validated. | MUST |
| LRN-REQ-050 | Calcular Need Validated → Pré-Proposta. | MUST |
| LRN-REQ-051 | Calcular Pré-Proposta → Proposta. | MUST |
| LRN-REQ-052 | Calcular Proposta → Decisão. | MUST |
| LRN-REQ-053 | Identificar etapa com maior tempo médio. | MUST |
| LRN-REQ-054 | Identificar Opportunities estacionadas. | MUST |
| LRN-REQ-055 | Diferenciar Opportunity estacionada de Parked deliberado. | MUST |
| LRN-REQ-056 | Não interpretar tempo maior automaticamente como falha. | MUST |
| LRN-REQ-057 | Preservar datas usadas nos cálculos. | MUST |
| LRN-REQ-058 | Indicar quando a amostra é pequena. | MUST |
E. Conversão
| ID | Requisito | Prioridade |
|---|---|---|
| LRN-REQ-059 | Calcular Lead → Need Validated. | MUST |
| LRN-REQ-060 | Calcular Need Validated → Opportunity. | MUST |
| LRN-REQ-061 | Calcular Opportunity → Pré-Proposta. | MUST |
| LRN-REQ-062 | Calcular Pré-Proposta → Proposta. | MUST |
| LRN-REQ-063 | Calcular Proposta → Won. | MUST |
| LRN-REQ-064 | Separar Lost. | MUST |
| LRN-REQ-065 | Separar Parked. | MUST |
| LRN-REQ-066 | Conversão não pode ser tratada automaticamente como qualidade do negócio. | MUST |
| LRN-REQ-067 | Venda fechada não implica negócio saudável. | MUST |
| LRN-REQ-068 | Permitir análise por período. | MUST |
| LRN-REQ-069 | Permitir análise por origem. | MUST |
| LRN-REQ-070 | Permitir análise por oferta. | MUST |
F. Aprendizado por oferta
| ID | Requisito | Prioridade |
|---|---|---|
| LRN-REQ-071 | Identificar oferta mais vendida. | MUST |
| LRN-REQ-072 | Identificar oferta de maior faturamento. | MUST |
| LRN-REQ-073 | Identificar maior ticket médio. | MUST |
| LRN-REQ-074 | Identificar maior recorrência. | MUST |
| LRN-REQ-075 | Identificar maior esforço estimado. | MUST |
| LRN-REQ-076 | Identificar maior facilidade de fechamento com base nos dados disponíveis. | MUST |
| LRN-REQ-077 | Cruzar oferta com ciclo. | MUST |
| LRN-REQ-078 | Cruzar oferta com conversão. | MUST |
| LRN-REQ-079 | Cruzar oferta com capacidade consumida. | MUST |
| LRN-REQ-080 | Cruzar oferta com contrapropostas. | MUST |
| LRN-REQ-081 | Cruzar oferta com perdas. | MUST |
| LRN-REQ-082 | Não recomendar automaticamente retirar uma oferta. | MUST |
| LRN-REQ-083 | Não presumir rentabilidade quando os dados não existirem. | MUST |
G. Origem dos negócios
| ID | Requisito | Prioridade |
|---|---|---|
| LRN-REQ-084 | Analisar indicação. | MUST |
| LRN-REQ-085 | Analisar networking. | MUST |
| LRN-REQ-086 | Analisar evento. | MUST |
| LRN-REQ-087 | Analisar inbound. | MUST |
| LRN-REQ-088 | Analisar outbound. | MUST |
| LRN-REQ-089 | Analisar cliente atual. | MUST |
| LRN-REQ-090 | Analisar ex-cliente. | MUST |
| LRN-REQ-091 | Suportar outras origens. | MUST |
| LRN-REQ-092 | Comparar volume por origem. | MUST |
| LRN-REQ-093 | Comparar conversão por origem. | MUST |
| LRN-REQ-094 | Comparar ticket por origem. | MUST |
| LRN-REQ-095 | Comparar ciclo por origem. | MUST |
| LRN-REQ-096 | Comparar recorrência por origem. | MUST |
| LRN-REQ-097 | Comparar qualidade percebida por origem quando houver dado. | MUST |
| LRN-REQ-098 | Comparar esforço por origem quando houver dado. | MUST |
| LRN-REQ-099 | Não declarar causalidade entre origem e fechamento apenas por correlação. | MUST |
H. Mercado e perfis
| ID | Requisito | Prioridade |
|---|---|---|
| LRN-REQ-100 | Observar padrões de porte. | MUST |
| LRN-REQ-101 | Observar contexto de empresa familiar quando conhecido. | MUST |
| LRN-REQ-102 | Observar momento de crescimento. | MUST |
| LRN-REQ-103 | Observar sucessão quando legitimamente registrada. | MUST |
| LRN-REQ-104 | Observar maturidade quando sustentada pelos dados utilizados no produto. | MUST |
| LRN-REQ-105 | Observar proximidade do decisor com a operação. | MUST |
| LRN-REQ-106 | Observar modelo de negócio. | MUST |
| LRN-REQ-107 | Observar necessidade recorrente. | MUST |
| LRN-REQ-108 | Observar padrões compartilhados pelos melhores clientes. | MUST |
| LRN-REQ-109 | Padrão transversal deve indicar período e amostra. | MUST |
| LRN-REQ-110 | IA não altera ICP automaticamente. | MUST |
| LRN-REQ-111 | IA pode sugerir mercado para investigar. | MUST |
| LRN-REQ-112 | Humano decide se mercado merece investigação. | MUST |
I. Bom cliente × realidade observada
| ID | Requisito | Prioridade |
|---|---|---|
| LRN-REQ-113 | Comparar percepção inicial de bom cliente com dados posteriores. | MUST |
| LRN-REQ-114 | Observar recompra. | MUST |
| LRN-REQ-115 | Observar indicação. | MUST |
| LRN-REQ-116 | Observar recorrência. | MUST |
| LRN-REQ-117 | Observar ticket. | MUST |
| LRN-REQ-118 | Observar esforço. | MUST |
| LRN-REQ-119 | Observar retrabalho quando registrado. | MUST |
| LRN-REQ-120 | Observar comportamento de pagamento quando existir dado legítimo. | MUST |
| LRN-REQ-121 | Observar mudanças frequentes de escopo. | MUST |
| LRN-REQ-122 | Não criar blacklist automática. | MUST |
| LRN-REQ-123 | Não reclassificar cliente definitivamente sem ação humana. | MUST |
J. Ganhos
| ID | Requisito | Prioridade |
|---|---|---|
| LRN-REQ-124 | Analisar motivos de fechamento registrados. | MUST |
| LRN-REQ-125 | Preservar origem do motivo de ganho. | MUST |
| LRN-REQ-126 | Permitir motivo desconhecido quando não houver dado. | MUST |
| LRN-REQ-127 | Observar padrões de Solution entre Won. | MUST |
| LRN-REQ-128 | Observar padrões de preço entre Won. | MUST |
| LRN-REQ-129 | Observar padrões de condição entre Won. | MUST |
| LRN-REQ-130 | Observar padrões de origem entre Won. | MUST |
| LRN-REQ-131 | Observar padrões de ciclo entre Won. | MUST |
| LRN-REQ-132 | Não assumir que característica recorrente causou o ganho. | MUST |
K. Perdas
| ID | Requisito | Prioridade |
|---|---|---|
| LRN-REQ-133 | Analisar motivos de perda. | MUST |
| LRN-REQ-134 | Separar investimento. | MUST |
| LRN-REQ-135 | Separar timing. | MUST |
| LRN-REQ-136 | Separar prioridade. | MUST |
| LRN-REQ-137 | Separar orçamento. | MUST |
| LRN-REQ-138 | Separar concorrente. | MUST |
| LRN-REQ-139 | Separar solução interna. | MUST |
| LRN-REQ-140 | Separar escopo. | MUST |
| LRN-REQ-141 | Separar valor percebido insuficiente. | MUST |
| LRN-REQ-142 | Separar decisão interna. | MUST |
| LRN-REQ-143 | Separar outros motivos. | MUST |
| LRN-REQ-144 | Manter motivo desconhecido como desconhecido. | MUST |
| LRN-REQ-145 | IA não pode preencher motivo ausente por inferência. | MUST |
| LRN-REQ-146 | Analisar objeções recorrentes. | MUST |
| LRN-REQ-147 | Objeção recorrente não significa automaticamente causa da perda. | MUST |
L. Parked e reativação
| ID | Requisito | Prioridade |
|---|---|---|
| LRN-REQ-148 | Analisar Parked separadamente de Lost. | MUST |
| LRN-REQ-149 | Analisar principais razões para não ser o momento. | MUST |
| LRN-REQ-150 | Analisar condições que precisavam mudar. | MUST |
| LRN-REQ-151 | Medir tempo até retomada quando houver retomada. | MUST |
| LRN-REQ-152 | Registrar se Parked voltou a Lead/Opportunity. | MUST |
| LRN-REQ-153 | Registrar se Parked posteriormente virou Won. | MUST |
| LRN-REQ-154 | Registrar se permaneceu sem retomada. | MUST |
| LRN-REQ-155 | Não tratar ausência de retomada imediata como falha da hipótese. | MUST |
| LRN-REQ-156 | Permitir análise de INACTIVE_WITH_POTENTIAL reativado. | MUST |
M. Relacionamento e recorrência
| ID | Requisito | Prioridade |
|---|---|---|
| LRN-REQ-157 | Analisar novas Opportunities originadas de Cliente Ativo. | MUST |
| LRN-REQ-158 | Analisar novos contratos por cliente. | MUST |
| LRN-REQ-159 | Analisar recorrência contratual. | MUST |
| LRN-REQ-160 | Diferenciar recompra de uma Opportunity isolada. | MUST |
| LRN-REQ-161 | Analisar reativação de cliente inativo. | MUST |
| LRN-REQ-162 | Analisar reativação de Inativo com potencial. | MUST |
| LRN-REQ-163 | Não confundir status da Opportunity com relacionamento do cliente. | MUST |
N. Indicações
| ID | Requisito | Prioridade |
|---|---|---|
| LRN-REQ-164 | Preservar vínculo entre indicador e Lead indicado quando disponível. | MUST |
| LRN-REQ-165 | Medir indicações que viram Need validado. | MUST |
| LRN-REQ-166 | Medir indicações que viram Opportunity. | MUST |
| LRN-REQ-167 | Medir indicações que viram Proposal. | MUST |
| LRN-REQ-168 | Medir indicações que viram contrato. | MUST |
| LRN-REQ-169 | Não criar score de influência automático no MVP. | MUST |
O. Potencial estratégico previsto × realizado
| ID | Requisito | Prioridade |
|---|---|---|
| LRN-REQ-170 | Recuperar potencial estratégico registrado no Business Fit. | MUST |
| LRN-REQ-171 | Recuperar confiança atribuída ao potencial. | MUST |
| LRN-REQ-172 | Observar se houve recorrência posterior. | MUST |
| LRN-REQ-173 | Observar se houve nova proposta. | MUST |
| LRN-REQ-174 | Observar se houve cross-sell. | MUST |
| LRN-REQ-175 | Observar se houve expansão para outra área. | MUST |
| LRN-REQ-176 | Observar se houve expansão para outra unidade. | MUST |
| LRN-REQ-177 | Observar se houve acesso a novo decisor. | MUST |
| LRN-REQ-178 | Observar se houve indicação. | MUST |
| LRN-REQ-179 | Observar se o cliente se tornou case/referência quando aplicável. | MUST |
| LRN-REQ-180 | Distinguir OBSERVED, NOT_OBSERVED_YET e NOT_APPLICABLE. | MUST |
| LRN-REQ-181 | Não considerar potencial falso apenas porque ainda não se realizou. | MUST |
| LRN-REQ-182 | Preservar janela de tempo observada. | MUST |
P. Preço sugerido × definido × aceito
| ID | Requisito | Prioridade |
|---|---|---|
| LRN-REQ-183 | Registrar faixa/preço sugerido pela IA. | MUST |
| LRN-REQ-184 | Registrar preço definido pelo humano. | MUST |
| LRN-REQ-185 | Registrar preço apresentado. | MUST |
| LRN-REQ-186 | Registrar preço final aceito. | MUST |
| LRN-REQ-187 | Calcular diferença sugerido × definido. | MUST |
| LRN-REQ-188 | Calcular diferença definido × aceito. | MUST |
| LRN-REQ-189 | Separar casos sem preço aceito. | MUST |
| LRN-REQ-190 | Analisar por oferta. | MUST |
| LRN-REQ-191 | Analisar por origem. | MUST |
| LRN-REQ-192 | Analisar por contexto quando houver amostra. | MUST |
| LRN-REQ-193 | Não concluir automaticamente que IA ou humano estava certo. | MUST |
Q. Condições e contrapropostas
| ID | Requisito | Prioridade |
|---|---|---|
| LRN-REQ-194 | Registrar condição inicialmente definida. | MUST |
| LRN-REQ-195 | Registrar contrapropostas. | MUST |
| LRN-REQ-196 | Registrar condição final aceita. | MUST |
| LRN-REQ-197 | Comparar condição inicial × final. | MUST |
| LRN-REQ-198 | Identificar quais elementos mudaram. | MUST |
| LRN-REQ-199 | Permitir analisar parcelamento. | MUST |
| LRN-REQ-200 | Permitir analisar escopo. | MUST |
| LRN-REQ-201 | Permitir analisar prazo. | MUST |
| LRN-REQ-202 | Permitir analisar fases. | MUST |
| LRN-REQ-203 | Permitir analisar forma de entrega. | MUST |
| LRN-REQ-204 | Não transformar padrão de negociação em desconto automático. | MUST |
R. Solution sugerida × validada
| ID | Requisito | Prioridade |
|---|---|---|
| LRN-REQ-205 | Registrar Solution inicialmente sugerida pela IA. | MUST |
| LRN-REQ-206 | Registrar se foi aceita. | MUST |
| LRN-REQ-207 | Registrar se foi ajustada. | MUST |
| LRN-REQ-208 | Registrar se foi rejeitada. | MUST |
| LRN-REQ-209 | Registrar motivo do ajuste quando disponível. | MUST |
| LRN-REQ-210 | Preservar diferença entre versão sugerida e validada. | MUST |
| LRN-REQ-211 | Permitir análise por tipo de Need. | MUST |
| LRN-REQ-212 | Permitir análise por oferta. | MUST |
| LRN-REQ-213 | Taxa de aceitação não pode virar score de inteligência opaco. | MUST |
S. Qualidade das sugestões da IA
| ID | Requisito | Prioridade |
|---|---|---|
| LRN-REQ-214 | Registrar sugestões aceitas sem alteração. | MUST |
| LRN-REQ-215 | Registrar sugestões ajustadas. | MUST |
| LRN-REQ-216 | Registrar sugestões rejeitadas. | MUST |
| LRN-REQ-217 | Registrar motivo do ajuste quando informado. | MUST |
| LRN-REQ-218 | Registrar motivo da rejeição quando informado. | MUST |
| LRN-REQ-219 | Permitir análise por etapa do ciclo. | MUST |
| LRN-REQ-220 | Permitir análise de pesquisa pré-abordagem. | MUST |
| LRN-REQ-221 | Permitir análise de Solution. | MUST |
| LRN-REQ-222 | Permitir análise de precificação. | MUST |
| LRN-REQ-223 | Permitir análise de condições. | MUST |
| LRN-REQ-224 | Permitir análise de roteiro. | MUST |
| LRN-REQ-225 | Permitir análise de follow-up. | MUST |
| LRN-REQ-226 | Não utilizar taxa de aceitação isoladamente para alterar prompts/metodologia. | MUST |
T. Métricas de uso e eficiência
| ID | Requisito | Prioridade |
|---|---|---|
| LRN-REQ-227 | Medir usuários ativos quando pertinente. | MUST |
| LRN-REQ-228 | Medir Leads processados. | MUST |
| LRN-REQ-229 | Medir Opportunities trabalhadas. | MUST |
| LRN-REQ-230 | Medir propostas geradas. | MUST |
| LRN-REQ-231 | Medir retornos ao sistema. | MUST |
| LRN-REQ-232 | Medir tempo de preparação quando tecnicamente disponível. | MUST |
| LRN-REQ-233 | Medir tempo de criação de Proposal. | MUST |
| LRN-REQ-234 | Medir tempo de consolidação pós-reunião. | MUST |
| LRN-REQ-235 | Redução de retrabalho só deve ser apresentada quando houver base comparável. | MUST |
| LRN-REQ-236 | Métricas devem separar medição objetiva de percepção do usuário. | MUST |
U. Qualidade percebida
| ID | Requisito | Prioridade |
|---|---|---|
| LRN-REQ-237 | Permitir registrar utilidade percebida da pesquisa. | MUST |
| LRN-REQ-238 | Permitir registrar utilidade da preparação. | MUST |
| LRN-REQ-239 | Permitir registrar utilidade da Solution sugerida. | MUST |
| LRN-REQ-240 | Permitir registrar utilidade da precificação. | MUST |
| LRN-REQ-241 | Permitir registrar utilidade dos roteiros. | MUST |
| LRN-REQ-242 | Feedback percebido não pode ser apresentado como desempenho objetivo. | MUST |
V. PatternObservation
| ID | Requisito | Prioridade |
|---|---|---|
| LRN-REQ-243 | Pattern deve possuir descrição. | MUST |
| LRN-REQ-244 | Registrar período observado. | MUST |
| LRN-REQ-245 | Registrar tamanho da amostra. | MUST |
| LRN-REQ-246 | Preservar evidências de suporte. | MUST |
| LRN-REQ-247 | Preservar limitações. | MUST |
| LRN-REQ-248 | Permitir evidências contraditórias. | MUST |
| LRN-REQ-249 | IA pode criar PatternObservation sugerido. | MUST |
| LRN-REQ-250 | Humano pode revisar. | MUST |
| LRN-REQ-251 | Humano pode descartar. | MUST |
W. LearningHypothesis
| ID | Requisito | Prioridade |
|---|---|---|
| LRN-REQ-252 | Hipótese deve derivar de PatternObservation ou investigação explícita. | MUST |
| LRN-REQ-253 | Registrar evidência de suporte. | MUST |
| LRN-REQ-254 | Registrar evidência contrária quando existir. | MUST |
| LRN-REQ-255 | Registrar limitações. | MUST |
| LRN-REQ-256 | IA pode sugerir hipótese. | MUST |
| LRN-REQ-257 | Humano decide se vale testar. | MUST |
| LRN-REQ-258 | Hipótese rejeitada deve permanecer histórica. | MUST |
| LRN-REQ-259 | Hipótese não testada não vira Learning. | MUST |
X. LearningTest
| ID | Requisito | Prioridade |
|---|---|---|
| LRN-REQ-260 | Teste deve estar ligado a uma hipótese. | MUST |
| LRN-REQ-261 | Registrar pergunta do teste. | MUST |
| LRN-REQ-262 | Registrar como será observado. | MUST |
| LRN-REQ-263 | Registrar dados a coletar. | MUST |
| LRN-REQ-264 | Registrar período quando aplicável. | MUST |
| LRN-REQ-265 | Humano deve aprovar início do teste. | MUST |
| LRN-REQ-266 | Não exigir desenho estatístico sofisticado no MVP. | MUST |
| LRN-REQ-267 | Teste deve ser rastreável. | MUST |
Y. Resultado do teste
| ID | Requisito | Prioridade |
|---|---|---|
| LRN-REQ-268 | IA pode organizar o resultado. | MUST |
| LRN-REQ-269 | Humano deve revisar o resultado. | MUST |
| LRN-REQ-270 | Suportar resultado que apoia. | MUST |
| LRN-REQ-271 | Suportar resultado que não apoia. | MUST |
| LRN-REQ-272 | Suportar inconclusivo. | MUST |
| LRN-REQ-273 | Inconclusivo é resultado válido. | MUST |
| LRN-REQ-274 | Resultado não pode ser alterado silenciosamente para gerar Learning. | MUST |
Z. Learning
| ID | Requisito | Prioridade |
|---|---|---|
| LRN-REQ-275 | Learning deve possuir evidência. | MUST |
| LRN-REQ-276 | Learning deve registrar limitações. | MUST |
| LRN-REQ-277 | Learning deve usar linguagem proporcional aos dados. | MUST |
| LRN-REQ-278 | Evitar sempre, nunca e causalidade sem base. | MUST |
| LRN-REQ-279 | Learning exige validação humana. | MUST |
| LRN-REQ-280 | IA não valida Learning. | MUST |
| LRN-REQ-281 | Learning pode permanecer específico a uma amostra/período. | MUST |
AA. Proposed Change
| ID | Requisito | Prioridade |
|---|---|---|
| LRN-REQ-282 | Proposed Change deve referenciar Learning. | MUST |
| LRN-REQ-283 | Pode existir mais de um Learning como suporte. | MUST |
| LRN-REQ-284 | Registrar área impactada. | MUST |
| LRN-REQ-285 | Registrar mudança proposta. | MUST |
| LRN-REQ-286 | Registrar efeito esperado. | MUST |
| LRN-REQ-287 | Humano deve aprovar mudança relevante. | MUST |
| LRN-REQ-288 | Humano pode rejeitar mudança. | MUST |
| LRN-REQ-289 | Mudança rejeitada permanece histórica. | MUST |
| LRN-REQ-290 | Registrar quando foi implementada. | MUST |
| LRN-REQ-291 | Implementação deve preservar origem da decisão. | MUST |
AB. Mudanças proibidas automaticamente
| ID | Requisito | Prioridade |
|---|---|---|
| LRN-REQ-292 | IA não pode mudar ICP automaticamente. | MUST |
| LRN-REQ-293 | IA não pode mudar preço-base automaticamente. | MUST |
| LRN-REQ-294 | IA não pode reclassificar ofertas automaticamente. | MUST |
| LRN-REQ-295 | IA não pode alterar regra de Business Fit automaticamente. | MUST |
| LRN-REQ-296 | IA não pode alterar Human Gates. | MUST |
| LRN-REQ-297 | IA não pode alterar metodologia automaticamente. | MUST |
| LRN-REQ-298 | IA não pode alterar heurísticas relevantes sem aprovação. | MUST |
| LRN-REQ-299 | IA não pode alterar scripts oficiais silenciosamente. | MUST |
AC. Cliente Zero
| ID | Requisito | Prioridade |
|---|---|---|
| LRN-REQ-300 | Permitir registrar execuções de Cliente Zero. | MUST |
| LRN-REQ-301 | Registrar fricções. | MUST |
| LRN-REQ-302 | Registrar esforço observado. | MUST |
| LRN-REQ-303 | Registrar gaps. | MUST |
| LRN-REQ-304 | Registrar saídas testadas. | MUST |
| LRN-REQ-305 | Registrar utilidade percebida. | MUST |
| LRN-REQ-306 | Identificar dados de Cliente Zero separadamente de piloto externo. | MUST |
| LRN-REQ-307 | Não apresentar Cliente Zero como validação externa. | MUST |
AD. Pilotos externos
| ID | Requisito | Prioridade |
|---|---|---|
| LRN-REQ-308 | Piloto externo só deve ocorrer após fluxo mínimo navegável. | MUST |
| LRN-REQ-309 | Registrar evidências do piloto. | MUST |
| LRN-REQ-310 | Registrar Learnings do piloto. | MUST |
| LRN-REQ-311 | Registrar Proposed Changes. | MUST |
| LRN-REQ-312 | Não alterar produto por impressão isolada sem registro. | MUST |
| LRN-REQ-313 | Preservar identificação de qual piloto originou a evidência. | MUST |
| LRN-REQ-314 | Permitir comparar aprendizados entre pilotos sem generalizar automaticamente. | MUST |
AE. Causalidade
| ID | Requisito | Prioridade |
|---|---|---|
| LRN-REQ-315 | Comparação temporal não deve ser descrita automaticamente como causalidade. | MUST |
| LRN-REQ-316 | Não afirmar que Orquestro aumentou vendas apenas por melhora posterior. | MUST |
| LRN-REQ-317 | Não afirmar que Orquestro reduziu ciclo sem desenho adequado. | MUST |
| LRN-REQ-318 | Pode mostrar diferença observada entre períodos. | MUST |
| LRN-REQ-319 | Deve preservar contexto das amostras. | MUST |
| LRN-REQ-320 | Alegação causal futura exige desenho específico de validação. | MUST |
AF. Segurança, tenant e permissões
| ID | Requisito | Prioridade |
|---|---|---|
| LRN-REQ-321 | Todo aprendizado comercial deve respeitar organization_id. | MUST |
| LRN-REQ-322 | Dados de empresas diferentes não podem ser misturados no aprendizado do cliente. | MUST |
| LRN-REQ-323 | Benchmark externo não entra no MVP. | MUST |
| LRN-REQ-324 | Usuário deve ver apenas dados permitidos. | MUST |
| LRN-REQ-325 | Dados financeiros sensíveis devem respeitar permissões vigentes. | MUST |
| LRN-REQ-326 | Dashboard pode ocultar dados sensíveis mantendo insight permitido. | MUST |
| LRN-REQ-327 | Aprovação de Proposed Change deve respeitar papel autorizado. | MUST |
| LRN-REQ-328 | Alteração de metodologia/produto deve exigir responsável autorizado. | MUST |
AG. Auditoria
| ID | Requisito | Prioridade |
|---|---|---|
| LRN-REQ-329 | Registrar snapshot de métricas quando necessário. | MUST |
| LRN-REQ-330 | Registrar Pattern observado. | MUST |
| LRN-REQ-331 | Registrar revisão/descarte de Pattern. | MUST |
| LRN-REQ-332 | Registrar hipótese sugerida. | MUST |
| LRN-REQ-333 | Registrar hipótese aprovada para teste. | MUST |
| LRN-REQ-334 | Registrar hipótese rejeitada. | MUST |
| LRN-REQ-335 | Registrar início de teste. | MUST |
| LRN-REQ-336 | Registrar conclusão de teste. | MUST |
| LRN-REQ-337 | Registrar Learning. | MUST |
| LRN-REQ-338 | Registrar validação humana do Learning. | MUST |
| LRN-REQ-339 | Registrar Proposed Change. | MUST |
| LRN-REQ-340 | Registrar aprovação/rejeição. | MUST |
| LRN-REQ-341 | Registrar implementação. | MUST |
| LRN-REQ-342 | Preservar cadeia Evidence → Pattern → Hypothesis → Test → Learning → Proposed Change. | MUST |
55. Casos de Teste
Dashboard e One Page
| ID | Resultado esperado |
|---|---|
| LRN-TEST-001 | Dashboard mostra indicadores essenciais. |
| LRN-TEST-002 | Dashboard não exige dezenas de métricas. |
| LRN-TEST-003 | Usuário gera One Page mensal. |
| LRN-TEST-004 | One Page contém seis blocos previstos. |
| LRN-TEST-005 | Período personalizado funciona. |
| LRN-TEST-006 | Comparação com amostra muito diferente traz alerta. |
Ciclo e conversão
| ID | Resultado esperado |
|---|---|
| LRN-TEST-007 | Lead → Need é calculado corretamente. |
| LRN-TEST-008 | Need → Pré-Proposta é calculado. |
| LRN-TEST-009 | Pré-Proposta → Proposta é calculado. |
| LRN-TEST-010 | Proposta → Decisão é calculado. |
| LRN-TEST-011 | Parked não é contado como Lost. |
| LRN-TEST-012 | Gargalo temporal é apresentado como dado/insight, não julgamento. |
| LRN-TEST-013 | Amostra pequena é sinalizada. |
Ofertas
| ID | Resultado esperado |
|---|---|
| LRN-TEST-014 | Oferta mais vendida é identificada. |
| LRN-TEST-015 | Maior faturamento é identificado. |
| LRN-TEST-016 | Maior recorrência é identificada. |
| LRN-TEST-017 | Maior esforço é identificado. |
| LRN-TEST-018 | Maior faturamento não vira automaticamente melhor oferta. |
Origem
| ID | Resultado esperado |
|---|---|
| LRN-TEST-019 | Indicação é comparada por conversão. |
| LRN-TEST-020 | Outbound é comparado por ciclo. |
| LRN-TEST-021 | Cliente atual é comparado por recorrência. |
| LRN-TEST-022 | Sistema não conclui causalidade a partir de origem. |
Mercado e bons clientes
| ID | Resultado esperado |
|---|---|
| LRN-TEST-023 | Padrão transversal pode ser identificado. |
| LRN-TEST-024 | Pattern informa amostra. |
| LRN-TEST-025 | Mercado potencial permanece investigação. |
| LRN-TEST-026 | ICP não muda sozinho. |
| LRN-TEST-027 | Percepção de bom cliente pode ser confrontada com dados. |
| LRN-TEST-028 | Cliente problemático não entra automaticamente em blacklist. |
Ganhos, perdas e Parked
| ID | Resultado esperado |
|---|---|
| LRN-TEST-029 | Motivos de ganho conhecidos são agrupados. |
| LRN-TEST-030 | Motivos de perda conhecidos são agrupados. |
| LRN-TEST-031 | Motivo desconhecido permanece desconhecido. |
| LRN-TEST-032 | IA não inventa motivo. |
| LRN-TEST-033 | Parked é analisado separadamente. |
| LRN-TEST-034 | Parked reativado é reconhecido. |
| LRN-TEST-035 | Parked posteriormente Won pode ser medido. |
Relacionamento e indicações
| ID | Resultado esperado |
|---|---|
| LRN-TEST-036 | Cliente Ativo com nova Opportunity é contabilizado como continuidade. |
| LRN-TEST-037 | Recompra é distinguida da primeira venda. |
| LRN-TEST-038 | Inativo com potencial reativado é identificado. |
| LRN-TEST-039 | Indicação preserva vínculo com indicador. |
| LRN-TEST-040 | Indicação que vira contrato é mensurável. |
Potencial estratégico
| ID | Resultado esperado |
|---|---|
| LRN-TEST-041 | Potencial alto de expansão é recuperado. |
| LRN-TEST-042 | Nova Opportunity em outra unidade registra expansão observada. |
| LRN-TEST-043 | Potencial ainda não realizado fica NOT_OBSERVED_YET. |
| LRN-TEST-044 | Não realização imediata não converte hipótese em falsa. |
| LRN-TEST-045 | Janela de observação permanece visível. |
Preço e condições
| ID | Resultado esperado |
|---|---|
| LRN-TEST-046 | Preço sugerido é preservado. |
| LRN-TEST-047 | Preço definido é preservado separadamente. |
| LRN-TEST-048 | Preço aceito é preservado separadamente. |
| LRN-TEST-049 | Diferenças são calculadas corretamente. |
| LRN-TEST-050 | IA não conclui automaticamente que vendedor errou. |
| LRN-TEST-051 | Condição inicial é preservada. |
| LRN-TEST-052 | Contraproposta é preservada. |
| LRN-TEST-053 | Condição final é preservada. |
| LRN-TEST-054 | Padrão de desconto não vira desconto automático. |
Solution e IA
| ID | Resultado esperado |
|---|---|
| LRN-TEST-055 | Solution sugerida é preservada. |
| LRN-TEST-056 | Solution validada é preservada. |
| LRN-TEST-057 | Ajuste é mensurável. |
| LRN-TEST-058 | Rejeição é mensurável. |
| LRN-TEST-059 | Motivo do ajuste pode ser analisado. |
| LRN-TEST-060 | Taxa de aceitação não altera metodologia sozinha. |
Pattern e hipótese
| ID | Resultado esperado |
|---|---|
| LRN-TEST-061 | IA cria PatternObservation sugerido. |
| LRN-TEST-062 | Pattern inclui período e amostra. |
| LRN-TEST-063 | Evidência contraditória pode ser registrada. |
| LRN-TEST-064 | IA sugere hipótese ligada ao Pattern. |
| LRN-TEST-065 | Humano aprova hipótese para teste. |
| LRN-TEST-066 | Humano rejeita hipótese. |
| LRN-TEST-067 | Hipótese rejeitada permanece histórica. |
Teste e Learning
| ID | Resultado esperado |
|---|---|
| LRN-TEST-068 | Teste exige hipótese relacionada. |
| LRN-TEST-069 | Humano aprova início do teste. |
| LRN-TEST-070 | Resultado pode apoiar hipótese. |
| LRN-TEST-071 | Resultado pode não apoiar. |
| LRN-TEST-072 | Resultado pode ser inconclusivo. |
| LRN-TEST-073 | Inconclusivo não é forçado para Learning. |
| LRN-TEST-074 | Learning exige validação humana. |
| LRN-TEST-075 | IA não valida Learning. |
| LRN-TEST-076 | Learning preserva limitações. |
Proposed Change
| ID | Resultado esperado |
|---|---|
| LRN-TEST-077 | Proposed Change referencia Learning. |
| LRN-TEST-078 | Mudança pode ser rejeitada. |
| LRN-TEST-079 | Mudança rejeitada fica histórica. |
| LRN-TEST-080 | Mudança aprovada registra humano. |
| LRN-TEST-081 | IA não altera ICP automaticamente. |
| LRN-TEST-082 | IA não altera preço-base automaticamente. |
| LRN-TEST-083 | IA não altera Human Gate automaticamente. |
| LRN-TEST-084 | IA não muda metodologia silenciosamente. |
Cliente Zero e pilotos
| ID | Resultado esperado |
|---|---|
| LRN-TEST-085 | Cliente Zero registra fricção. |
| LRN-TEST-086 | Cliente Zero registra gap. |
| LRN-TEST-087 | Cliente Zero permanece identificado como validação interna. |
| LRN-TEST-088 | Piloto externo preserva Evidence. |
| LRN-TEST-089 | Piloto externo gera Learning rastreável. |
| LRN-TEST-090 | Proposed Change referencia piloto. |
| LRN-TEST-091 | Uma impressão isolada não altera produto. |
Causalidade e segurança
| ID | Resultado esperado |
|---|---|
| LRN-TEST-092 | Melhora após adoção não é descrita como causada pelo Orquestro. |
| LRN-TEST-093 | Comparação entre períodos usa linguagem observacional. |
| LRN-TEST-094 | Tenant A não entra no aprendizado comercial do Tenant B. |
| LRN-TEST-095 | Usuário sem permissão não vê dado financeiro restrito. |
| LRN-TEST-096 | Cadeia completa de aprendizado aparece na auditoria. |
56. E2Es obrigatórios
LRN-E2E-001 — Padrão → hipótese → teste → Learning
- Empresa acumula 30 Opportunities.
- Dashboard identifica que indicações aparecem com ciclo menor.
- Pattern registra período, amostra e evidências.
- IA sugere hipótese sobre confiança inicial.
- Humano escolhe Vale testar.
- LearningTest é criado.
- Novas Opportunities são observadas.
- Resultado apoia parcialmente a hipótese.
- IA organiza resultado.
- Humano revisa.
- Learning é validado com linguagem limitada à amostra.
- Nenhuma regra comercial muda automaticamente.
PASS: ciclo de aprendizado respeita todas as camadas.
LRN-E2E-002 — Amostra pequena não vira regra
- Existem apenas 3 negócios de um perfil.
- Os 3 fecharam.
- Orquestro identifica um sinal.
- Mostra amostra pequena.
- Não altera ICP.
- Não marca o perfil como “cliente ideal”.
- Sugere continuar observando.
PASS: correlação inicial não vira verdade.
LRN-E2E-003 — Preço sugerido × definido × aceito
- IA sugere R$ 35 mil.
- Humano define R$ 32 mil.
- Cliente contrapropõe R$ 30 mil.
- Negociação termina em R$ 31 mil.
- Os quatro momentos permanecem registrados.
- Depois de vários casos, Orquestro mostra diferença recorrente.
- Não conclui que IA ou vendedor está errado.
- Pode sugerir hipótese para investigar.
PASS: aprendizado de preço não vira otimização autônoma.
LRN-E2E-004 — Potencial estratégico previsto × realizado
- Business Fit registrou “expansão para outras unidades” como potencial Alto, confiança Média.
- Primeiro contrato é fechado.
- Seis meses depois surge nova Opportunity de outra unidade.
StrategicPotentialOutcome = EXPANSION_OBSERVED.- O dado passa a enriquecer análises futuras.
- Não transforma automaticamente todo cliente semelhante em estratégico.
PASS: hipótese futura pode ganhar evidência sem generalização automática.
LRN-E2E-005 — Parked reativado
- Opportunity foi
PARKED. - CustomerRelationship ficou
INACTIVE_WITH_POTENTIAL. - Data de retomada chega.
- Comercial reativa a conversa.
- Nova Opportunity é criada.
- Posteriormente vira contrato.
- Orquestro registra Parked → Retomado → Won.
- Esse caso passa a compor aprendizado de reativação.
PASS: “não agora” produz conhecimento próprio, separado de perda.
LRN-E2E-006 — Hipótese rejeitada
- IA identifica Pattern.
- Sugere hipótese.
- Responsável considera a explicação inadequada.
- Hipótese é marcada
REJECTED. - Motivo pode ser registrado.
- Pattern permanece.
- Produto não muda.
- Rejeição também entra no aprendizado da contribuição da IA.
PASS: humano pode contradizer a inteligência sem perder histórico.
LRN-E2E-007 — Teste inconclusivo
- Hipótese é aprovada.
- Teste roda por período definido.
- Amostra continua pequena e resultados contraditórios.
- Resultado =
INCONCLUSIVE. - Nenhum Learning conclusivo é forçado.
- Humano pode continuar observando ou encerrar.
PASS: o Orquestro aceita não saber.
LRN-E2E-008 — Cliente Zero → piloto → Proposed Change
- LC Verum percorre fluxo como Cliente Zero.
- Fricção é registrada.
- Não é tratada como validação externa.
- Fluxo mínimo fica navegável.
- Piloto externo encontra evidência semelhante.
- Evidence é registrada.
- Learning é validado.
- Proposed Change é criado.
- Responsável humano aprova.
- Mudança é implementada e auditada.
PASS: produto evolui por evidência registrada, não por impressão isolada.
57. Gate de saída
O Incremento 7 só está concluído quando:
- Dashboard enxuto funciona.
- One Page funciona.
- Tempo de ciclo é mensurável.
- Conversão é mensurável.
- Won, Lost e Parked são separados.
- Origem é analisada além de volume.
- Ofertas podem ser analisadas por venda, ticket, recorrência e esforço.
- Mercado potencial permanece investigação.
- Bom cliente pode ser confrontado com dados reais.
- Recorrência e reativação são mensuráveis.
- Indicações são rastreáveis.
- Potencial estratégico previsto × realizado funciona.
- Preço sugerido × definido × aceito funciona.
- Condição inicial × final funciona.
- Contrapropostas entram no aprendizado.
- Solution sugerida × validada funciona.
- Sugestões aceitas, ajustadas e rejeitadas são mensuráveis.
- Motivo de ajuste pode ser preservado.
- Pattern registra amostra e período.
- Evidência contrária é suportada.
- Hipótese não vira Learning sem teste/revisão adequada.
- Humano decide se vale testar.
- Teste inconclusivo é legítimo.
- Learning exige humano.
- Proposed Change exige humano.
- ICP não muda automaticamente.
- Metodologia não muda silenciosamente.
- Cliente Zero permanece validação interna.
- Piloto usa Evidence → Learning → Proposed Change.
- O produto não atribui causalidade ao Orquestro sem desenho de validação.
- Os 8 E2Es passam.
58. Resumo quantitativo
Requisitos: 342
Testes: 96
E2Es obrigatórios: 8
Novo Human Gate comercial: nenhum
59. Freeze do Incremento 7
Consideram-se congelados:
- Dashboard enxuto
- One Page executivo
- Tempo do ciclo
- Conversão
- Ofertas
- Mercados e perfis
- Origem dos negócios
- Ganhos / Perdas / Parked
- Gargalos
- Bom cliente × dados reais
- Preço sugerido × definido × aceito
- Condição inicial × final
- Contrapropostas
- Solution sugerida × validada
- Sugestões aceitas / ajustadas / rejeitadas
- Motivo do ajuste
- Potencial estratégico previsto × realizado
- Recorrência
- Expansão
- Indicação
- Reativação
- Dado → Padrão → Hipótese
- Humano decide testar
- Teste → Resultado → Learning
- Proposed Change
- Nenhuma mudança silenciosa
- Cliente Zero
- Pilotos externos
- Sem causalidade artificial
- Sem ML preditivo no MVP
60. Encerramento dos 7 incrementos
Com este Incremento 7, os sete incrementos do Orquestro ficam fechados em conteúdo:
- Fundação
- Configuração Comercial
- Lead e Necessidade
- Solução
- Negócio
- Proposta e Decisão
- Inteligência e Aprendizado
O próximo passo não é um novo incremento funcional.
É a Revisão Transversal Final do MVP, incluindo:
- patch formal dos Gates 8–13;
- mapa completo de telas;
- objetos principais;
- permissões;
- dados sensíveis;
- regras centrais da IA;
- TruthMode;
- versionamento;
- auditoria;
- dependências entre incrementos;
- critérios globais de aceite;
- revisão de duplicidades e inconsistências;
- consolidação do MVP como Freeze Candidate geral.