Orquestro™ — Fonte Arquitetural Consolidada

Versão: 0.3
Data-base: 22/08/2026
Status: arquitetura consolidada aprovada pelas Founders para especificação, desenvolvimento incremental, operação assistida, testes e pilotos
Classificação: fonte-mestra do Domain Pack Sales Intelligence dentro do Orquestro v3
Posição no Orquestro: primeiro produto, wedge comercial, primeiro Domain Pack e primeira fatia ponta a ponta da Minimum Viable Platform
Núcleo intelectual: Commercial Decision Engine™
Governança: decisões das Founders prevalecem conforme regra de precedência do Orquestro Master Context
Substitui como fonte consolidada: Orquestro_Sales_Intelligence_Modulo_v0.2_2026-08-21.md
Preserva como especificações de aprofundamento: E0.CORE v0.1, E0.SALES v0.2, E2 v0.2, E3 v0.1, E4 v0.1, E5 v0.1 e E6 v0.1
Fonte metodológica aplicada: PRODUCT_PROMPT.md — Product Markdown Rail

Aviso de maturidade: este documento consolida arquitetura, método, contratos entre etapas, estados, objetos, gates, outputs e regras aprovadas. Ele não comprova implementação funcional ponta a ponta, integração completa de IA, prontidão de produção, segurança validada, Product-Market Fit, pricing validado, clientes pagantes ou qualquer efeito comercial. Arquitetura documentada não equivale a software funcionando.

Regra de autoridade interna deste arquivo: quando houver conflito entre a síntese consolidada v0.3 e um bloco detalhado incorporado de versão anterior, prevalece a síntese consolidada v0.3, seguida da decisão explícita mais recente das Founders.

1. Finalidade da v0.3

A v0.3 transforma a jornada comercial construída entre E0 e E6 em uma única fonte arquitetural coerente. Seu objetivo não é criar novas etapas, mas eliminar fontes concorrentes e tornar explícito como contexto, oferta, lead, Discovery, necessidade, fit, comunicação, decisão, handoff, outcome e learning se conectam.

A partir desta versão:

E0.CORE é a fundação transversal de contexto, readiness, segregação e ativação;
E0.SALES governa Offer Truth, Value Architecture, Commercial Configuration, Promise Integrity e boundaries;
E1 prepara contexto de conta, relacionamento, triggers, hipóteses e gaps;
E2 conduz Human Discovery e produz Customer Need Truth governado;
Need Isolation Gate e Opportunity Gate impedem avanço prematuro;
E3 compara Need Truth e Offer Truth para produzir Responsible Solution Fit, Responsible Commercial Promise e Proposal Readiness;
E4 estrutura proposta protegida e apresentação humana da decisão;
E5 opera somente quando a decisão não se encerra na apresentação, estruturando feedback, fricções, objeções, negociação autorizada e ciclos subsequentes;
E6 começa na resolução, estacionamento legítimo ou encerramento da decisão e fecha handoff, Value Reality e learning governado;
resultados e learnings retroalimentam E0.SALES, E1, E2, E3, E4, E5 e a Commercial Decision Engine™ por mudanças revisadas e versionadas.

2. Decisões de consolidação que resolvem conflitos anteriores

2.1 Sales é wedge, não o único domínio permitido no MVP

A regra antiga que tratava Sales Intelligence como único produto permitido no MVP foi superada pela DEC-MVP-001 de 22/08/2026.

Posição vigente:

o MVP v3 é uma Minimum Viable Platform;
Foundation, E0, Knowledge & Decision Core, os nove Domain Packs aprovados e capacidades transversais podem compor o MVP por Minimum Viable Domain Slices;
Sales Intelligence continua sendo o primeiro produto, a wedge comercial e a primeira prova ponta a ponta;
inclusão arquitetural de outros Domain Packs não significa implementação simultânea, validação, maturidade ou demanda comprovada.

2.2 E5 possui o momentum ativo; E6 não duplica follow-up

A nomenclatura histórica E6 — Decision Momentum, Outcome & Learning é substituída pela fronteira aprovada:

enquanto existe próximo compromisso ativo, feedback a processar, objeção a explorar ou decisão ainda em ciclo, o caso permanece em E5;
E6 começa quando existe decisão, encerramento, POSTPONED com trigger legítimo, NO_DECISION, WITHDRAWN_BY_SELLER, CLOSED_NO_OPPORTUNITY ou NO_FIT;
E6 não executa follow-up infinito.

2.3 A apresentação é humana; o sistema trabalha antes e depois

A primeira apresentação da proposta acontece de forma humana, prioritariamente presencial quando esse for o contexto comercial aprovado.

Regra operacional:

Orquestro prepara
→ pessoa apresenta
→ pessoa escuta
→ decisão?
   ├─ fechou: registrar, enviar versão autorizada e seguir para E6
   └─ não fechou: registrar Presentation Debrief e iniciar E5

O Orquestro não deve competir com o cliente pela atenção durante a apresentação nem atuar como whisper engine invasivo.

2.4 Objeções seguem CRR + Open Question

No E5, a resposta preparada a objeções segue:

CONCORDA
→ REFORÇA
→ REITERA
→ PERGUNTA ABERTA

CONCORDA legitima a preocupação sem confirmar premissa falsa;
REFORÇA reconhece a validade do critério decisório;
REITERA retorna a Need Truth, Responsible Promise e Value Architecture autorizada;
PERGUNTA ABERTA devolve a palavra ao cliente e gera novo conhecimento.

2.5 USF1 + USF2 + USP pertencem à verdade comercial de E0.SALES

USF1 representa valor tangível / O QUE;
USF2 representa valor intangível da forma de entrega / COMO, sem revelar HOW proprietário;
USP sintetiza a diferença que pode ser responsavelmente defendida;
E4 e E5 selecionam valor relevante; não inventam valor;
Relevant Value Stack é projeção contextual, não nova verdade canônica.

2.6 Customer Need Truth e Offer Passport são projeções, não verdades concorrentes

NeedInstance → Customer Need Truth
OfferVersion → Offer Passport

NeedInstance permanece canônico para necessidade;
OfferVersion permanece canônico para oferta;
snapshots/projeções são governados, versionados e pinados ao caso;
E3 compara as duas verdades contextuais sem reescrever suas fontes.

3. Definição executiva do Orquestro™

O Orquestro™ é o Domain Pack de Engenharia Comercial do Orquestro. Ele estrutura conhecimento comercial disperso para apoiar decisões de vendas consultivas com evidência, rastreabilidade, gates, revisão humana e aprendizado.

Mensagem de valor:

Transformamos conhecimento em decisões comerciais inteligentes.

Princípio de experiência:

O Orquestro prepara a conversa. A pessoa conduz a conversa. O sistema estrutura o aprendizado depois.

Não é:

CRM generalista como objetivo principal;
prospecção em massa;
chatbot de vendas;
gerador autônomo de diagnóstico;
máquina de proposta antes da necessidade;
perfil psicológico de comprador;
engine de pressão, falsa urgência ou escassez;
previsão infalível de fechamento;
substituto do julgamento do seller ou do cliente.

4. Tese comercial consolidada

Em vendas B2B intensivas em conhecimento, a fragilidade não nasce apenas da falta de leads. Ela surge quando:

contexto fica na memória dos founders;
relacionamento é confundido com oportunidade;
pedido de solução é confundido com necessidade;
percepção vira fato;
hipótese vira diagnóstico;
oferta é escolhida antes do Discovery;
preço ou customização fogem daquilo que foi autorizado;
proposta entrega HOW demais ou verdade de menos;
objeções são tratadas como inimigos em vez de informação;
oportunidades permanecem artificialmente abertas;
o que foi vendido não chega íntegro ao delivery;
win/loss não retorna à oferta e à metodologia como aprendizado governado.

A tese do Sales Intelligence é construir uma cadeia rastreável:

KNOW
→ ISOLATE NEED
→ DECIDE OPPORTUNITY
→ EVALUATE FIT
→ PROMISE RESPONSIBLY
→ COMMUNICATE CLEARLY
→ LISTEN AND DECIDE
→ HANDOFF
→ OBSERVE VALUE
→ LEARN
→ KNOW BETTER

5. Jornada funcional consolidada E0–E6

flowchart TB
    C["E0.CORE\nOrganizational Context & Readiness"] --> O["E0.SALES\nOffer Intelligence & Commercial Readiness"]
    O --> E1["E1\nLead Intelligence"]
    E1 --> P["E2.1\nMeeting Preparation"]
    P --> H["E2.2\nHuman Discovery"]
    H --> PM["E2.3\nPost-Meeting Intelligence"]
    PM --> CNT["Customer Need Truth"]
    CNT --> NG{"Need Isolation Gate"}
    NG --> OG{"Opportunity Gate"}
    OG --> E3["E3\nResponsible Solution Fit"]
    E3 --> PRG{"Proposal Readiness Gate"}
    PRG --> E4["E4\nDecision & Communication"]
    E4 --> PRES["Human Presentation"]
    PRES --> DEC{"Decision closed?"}
    DEC -->|Yes| E6["E6\nDecision Outcome, Handoff & Learning"]
    DEC -->|No| E5["E5\nDecision Conversation & Feedback Intelligence"]
    E5 --> E6
    E6 --> O
    E6 --> E1
    E6 --> E2R["E2 learning/revalidation"]
    E6 --> E3R["E3 fit learning"]

Retornos materiais:

Need insuficiente → E2;
Opportunity Gate NEED MORE EVIDENCE → E1/E2;
Opportunity Gate DO NOT CREATE → closure/learning;
E3 MORE EVIDENCE REQUIRED → E2;
mudança de Need → E2 e revisão de E3;
mudança de Offer fora do boundary → E0.SALES e nova OfferVersion;
mudança de fit/promise → E3;
revisão apenas de comunicação/proposta dentro da mesma verdade → E4;
feedback/objeção/negociação autorizada → E5;
outcome/closure/handoff/value/learning → E6.

6. Arquitetura em três loops

6.1 Opportunity Intelligence Loop

E0 → E1 → E2 → Need Isolation Gate → Opportunity Gate → E3

Objetivo: decidir se existe uma necessidade suficientemente compreendida e se alguma oferta possui fit responsável.

6.2 Decision Intelligence Loop

E3 → E4 → Human Presentation → E5, quando necessário → Decision Resolution

Objetivo: transformar fit responsável em comunicação, escuta, negociação governada e decisão legítima.

6.3 Reality & Learning Loop

E6 → Outcome → Value Reality → Learning Candidate → Human Review → Proposed Change → Version

Objetivo: impedir que venda, entrega e aprendizado permaneçam desconectados.

7. Regra epistemológica transversal

O Orquestro separa sistematicamente:

Classe	Significado
`CUSTOMER STATEMENT / FACT`	declaração ou fato sustentado conforme origem e evidência
`SELLER OBSERVATION`	percepção humana contextual
`ENGINE HYPOTHESIS`	interpretação a testar
`COUNTER-HYPOTHESIS`	explicação alternativa relevante
`GAP`	conhecimento ausente, insuficiente, conflitante ou desatualizado
`EVIDENCE`	item rastreável que sustenta, limita ou contradiz uma afirmação
`DECISION`	escolha humana registrada
`LEARNING CANDIDATE`	interpretação ainda não generalizável
`LEARNING`	aprendizado revisado e governado

Invariantes:

percepção não vira fato;
hipótese não vira diagnóstico;
ausência de informação não é preenchida por suposição;
Customer Statement não é convertido automaticamente em verdade universal;
outcome observado não implica causalidade;
um caso não vira regra universal;
IA não promove sozinha uma classe epistemológica material.

8. Need Lifecycle e gates

8.1 Need Lifecycle

SUSPECTED
→ EXPLORED
→ ISOLATED
→ CLIENT_VALIDATED
ou REJECTED

CLIENT_VALIDATED fortalece a verdade da necessidade, mas não é pré-condição universal para E3 quando ISOLATED + Opportunity Gate CREATE já possuem base suficiente.

8.2 Need Isolation Gate

Para ISOLATED, exige base suficiente para:

Current Reality;
Evidence;
Impact;
Desired Future;
Priority / Relevance.

Quando aplicável, o Customer Need Truth também explicita:

Need Boundary;
What Is Not The Need;
Customer Recognition;
Constraints / Resources;
Timing / Urgency;
Implementation Context;
Relevant Decision Unit;
Open Gaps;
Evidence Limitations;
snapshot, validade e versão.

Resultados:

ISOLATED
MORE EVIDENCE REQUIRED
REJECTED
OUT OF SCOPE
HUMAN REVIEW REQUIRED

8.3 Opportunity Gate

CREATE
NEED MORE EVIDENCE
DO NOT CREATE

Princípio:

Não avançar pode ser uma boa decisão comercial.

9. Duas verdades antes do fit

E3 só pode operar responsavelmente quando consegue comparar:

CUSTOMER NEED TRUTH
        +
OFFER PASSPORT
        ↓
RESPONSIBLE SOLUTION FIT

Customer Need Truth responde: qual é a melhor representação governada da necessidade neste momento?

Offer Passport responde: o que esta OfferVersion pode responsavelmente oferecer, sob quais capacidades, evidências, preços, condições, limites e disclosure rules?

Nenhuma das duas autoriza fit isoladamente.

10. Offer Truth, Value Architecture e Commercial Configuration

E0.SALES deve manter, por OfferVersion:

Offer identity/version;
intended needs/outcomes;
promises e claims;
capabilities e evidências;
prerequisites;
seller constraints;
exclusions e anti-fit;
Organization Value Architecture;
Offer Value Architecture;
USF1 / USF2 / USP;
Commercial Configuration Policy;
Configuration Boundary;
Discount Boundary;
Payment Boundary;
Timeline Boundary;
Approval Authority;
capacity/readiness;
Disclosure Classification;
Offer Reality observations e change proposals.

10.1 Pricing truth

PRICE DEFINED
≠ PRICE AUTHORIZED
≠ PRICE PRESENTED
≠ PRICE ACCEPTED
≠ PRICE PAID

Authorized price não significa validated price.

10.2 Disclosure truth

PROPOSAL_SAFE
PRESENTATION_ONLY
PROTECTED_KNOW_HOW

USF2 pode comunicar valor do HOW, mas não deve revelar HOW protegido.

11. E1 — Lead Intelligence consolidado

O nome oficial permanece E1 — Lead Intelligence, com escopo de Account, Relationship & Trigger Intelligence.

Objetivo:

transformar informação prévia sobre empresa, pessoas, relacionamento, origem e momento em contexto, sinais, hipóteses, contra-hipóteses e gaps para preparar Discovery.

Saída principal: Lead Intelligence Brief.

E1:

pode usar baseline E0, origem, relacionamento, histórico, dados autorizados, informações públicas, interações anteriores, seller observations e triggers;
revalida histórico como STILL VALID / CHANGED / RESOLVED / UNKNOWN / NEW;
identifica ICP/Anti-ICP signals sem converter compatibilidade em oportunidade;
prepara Discovery Priorities e Watch-outs;
não diagnostica necessidade;
não seleciona solução;
não cria Commercial Opportunity.

12. E2 — Human Discovery & Customer Need Truth consolidado

Princípio:

O Orquestro prepara a conversa. A pessoa conduz a conversa.

Discovery Question Map:

OPEN
→ EVIDENCE
→ CONFIRM
→ IMPACT
→ FUTURE
→ PRIORITY

O mapa é adaptativo; perguntas abertas são o padrão de exploração e a reunião não vira formulário guiado por tela.

Post-Meeting Intelligence:

Notes / Debrief / Sources
→ Evidence Items
→ Knowledge Items
→ NeedInstance
→ Decision Context + Gaps
→ Customer Need Truth Working Draft
→ Need Isolation Gate
→ Customer Need Truth Snapshot

Regras-chave:

Customer Request ≠ Customer Need;
What Is Not The Need protege contra solution forcing;
Historical Need Truth ≠ Current Need Truth;
E3 pina um snapshot da Need Truth;
Material Need Truth Change exige revisão do fit;
editorial change não deve invalidar o fit automaticamente.

13. E3 — Responsible Solution Fit consolidado

Pergunta central:

Dadas as verdades atuais da necessidade e da oferta, existe uma combinação que podemos responsavelmente defender?

Fluxo:

Customer Need Truth + Offer Passport
→ Candidate Eligibility
→ Multidimensional Responsible Fit
→ Promise Integrity
→ Risk / Boundaries
→ Human Review
→ Responsible Fit Decision
→ Responsible Commercial Promise
→ Proposal Readiness Gate

Dimensões podem incluir:

Need Fit;
Solution Fit;
Strategic Fit;
Capability Fit;
Implementation Fit;
Resource Fit;
Timing Fit;
Relationship Fit;
Decision Context;
Risk Fit;
Promise Integrity.

Não existe score universal obrigatório.

Estados:

STRONG FIT
CONDITIONAL FIT
PARTIAL FIT
NO FIT
MORE EVIDENCE REQUIRED
SPECIALIST REVIEW REQUIRED

PARTIAL FIT não segue diretamente para proposta.

Out-of-boundary não altera Offer silenciosamente:

OfferChangeProposal
→ E0.SALES / Human Review
→ nova OfferVersion
→ re-E3

Invariantes:

NEED BEFORE SOLUTION · TRUTH BEFORE FIT · FIT BEFORE PROMISE · PROMISE BEFORE PROPOSAL · EVIDENCE BEFORE CLAIM · CAPABILITY BEFORE COMMITMENT · BOUNDARY BEFORE CUSTOMIZATION · ALIGNMENT BEFORE PROPOSAL GENERATION · READINESS BEFORE PROPOSAL · HUMAN REVIEW WHEN MATERIAL · VERSION BEFORE REUSE · OUTCOME BEFORE GENERALIZATION

14. E4 — Decision & Communication consolidado

E4 não cria a solução e não ensina HOW proprietário.

Subetapas:

Decision Communication Intelligence;
Proposal Architecture & Knowledge Disclosure;
Presentation Architecture;
Human Presentation & Listening;
Proposal Release & Handoff.

Princípios:

Quem isola, vende.
Quem ouve, vende melhor.
A comunicação pode mudar a ênfase, nunca a verdade.
A proposta deve ser suficiente para decidir, não suficiente para copiar.
A primeira experiência com a proposta é uma conversa, não um anexo.

Proposal lifecycle mínimo:

DRAFT
→ READY_FOR_REVIEW
→ INTERNAL_REVIEWED
→ PRESENTATION_READY
→ PRESENTED
→ SEND_AUTHORIZED
→ SENT

A apresentação é humana. SENT exige apresentação e autorização, salvo futura decisão explícita que altere a regra.

Behavioral Communication Intelligence:

adapta sequência, ênfase, profundidade, ritmo e densidade com base em evidência observável;
nunca muda fatos, claims, preço, promise ou risk truth por perfil;
Social Style pode servir como lente assistiva, nunca diagnóstico;
gênero, geração ou demografia não podem inferir vulnerabilidade ou preferência persuasiva.

15. E5 — Decision Conversation & Feedback Intelligence consolidado

E5 é condicional. Se a decisão fecha na apresentação, o caso pode seguir diretamente para E6.

Quando não fecha:

Human Presentation
→ Presentation Debrief
→ Decision Friction Intelligence
→ Objection & Negotiation Preparation
→ Human Follow-up
→ Debrief
→ novo ciclo E5
→ Decision Resolution

15.1 Decision Friction

Surface Objection não é automaticamente root cause.

Categorias candidatas incluem:

CLARITY
VALUE
ECONOMIC
RISK
TRUST
IMPLEMENTATION
TIMING
PRIORITY
AUTHORITY
CONSENSUS
SCOPE
COMMERCIAL_TERM
COMPETITIVE
INFORMATION
NO_DECISION
UNKNOWN

15.2 CRR + Open Question

CONCORDA
→ REFORÇA
→ REITERA
→ PERGUNTA ABERTA

Toda resposta preparada deve terminar devolvendo a palavra ao cliente, salvo situação operacional em que uma pergunta seja manifestamente inadequada.

15.3 Relevant Value Stack

E5 pode selecionar:

Need Truth
+ Responsible Promise
+ USF1
+ USF2
+ USP
+ evidence
+ boundaries

para aquela fricção específica. Não deve despejar benefícios nem inventar benefício novo.

15.4 Negotiation Boundary

posição ≠ interesse;
concessão não precede compreensão do interesse quando isso for material;
E5 negocia somente dentro do espaço comercial autorizado;
fora da autoridade → Human Review / E0.SALES;
E5 nunca edita ProposalVersion silenciosamente; revisão de proposta retorna ao E4.

16. E6 — Decision Outcome, Handoff & Commercial Learning consolidado

E6 começa quando o ciclo decisório ativo terminou ou foi legitimamente estacionado.

Estados governados:

WON
LOST
POSTPONED
NO_DECISION
WITHDRAWN_BY_SELLER
CLOSED_NO_OPPORTUNITY
NO_FIT
UNKNOWN

POSTPONED exige trigger/condição de retomada; sem trigger legítimo não deve mascarar NO_DECISION.

16.1 Decision Resolution

Registra:

status/data;
Decision Unit snapshot;
Proposal Version;
Commercial Configuration;
preço proposto/aceito/pago quando aplicável;
Customer-stated reason;
Seller Observation;
Engine Hypothesis;
Gaps;
conditions/commitments/evidence.

Loss reason não é inferido como fato.

16.2 Contracted Promise & Delivery Handoff

Em WON:

Responsible Commercial Promise
→ Contracted Promise Snapshot
→ Delivery Handoff Package

O Contracted Promise Snapshot é imutável para aquela contratação e não substitui contrato jurídico.

O handoff deve tornar claro:

por que o cliente comprou;
que Need Truth sustentou a decisão;
o que foi prometido e contratado;
o que está incluído e excluído;
prerequisites, risks e stakeholders;
what was NOT promised.

16.3 Value Reality Chain

PROMISED
→ CONTRACTED
→ DELIVERED
→ PERCEIVED
→ REALIZED
→ ATTRIBUTION

Regras:

WON ≠ value delivered;
LOST ≠ no value;
DELIVERED ≠ value;
perceived value ≠ observed outcome;
observed outcome ≠ causal attribution;
Value Delivered ≠ Renewal Won.

16.4 Learning governance

EVIDENCE
→ LEARNING CANDIDATE
→ REVIEW
→ STRENGTHEN / WEAKEN / REJECT
→ PROPOSED CHANGE
→ HUMAN DECISION
→ VERSION

Um case nunca altera automaticamente Offer, methodology, Engine, ICP ou pricing policy.

17. Decision Unit transversal

Decision Unit representa o sistema decisório daquele caso, não um rótulo permanente de pessoas.

Pode conter, conforme evidência:

sponsor;
user;
influencer;
approver;
economic authority;
technical authority;
blocker;
resource owner;
other relevant roles.

A composição é temporal e versionada. Novo decisor identificado em E4/E5 atualiza o contexto e pode exigir reavaliação de comunicação, condição ou fit.

18. Objetos canônicos e projeções governadas

18.1 Core transversal

Organization / Tenant;
User / Membership / Role;
Project / Engagement / Domain Case;
Source;
EvidenceItem;
KnowledgeItem;
Observation;
Hypothesis / Counter-Hypothesis;
Gap;
Concern;
Recommendation;
HumanReview;
Decision;
Action;
Outcome;
Learning;
AuditEvent / Version.

18.2 Sales — contexto e relacionamento

Account;
Lead;
Actor;
Relationship Context;
Interaction;
Trigger.

18.3 Sales — Discovery e oportunidade

Customer Statement;
Seller Observation;
Engine Hypothesis;
NeedInstance;
Gate Record;
Commercial Opportunity;
Decision Unit;
Decision Context.

18.4 Sales — oferta, fit e decisão

Offer;
OfferVersion;
OfferComponent;
OfferPromise;
OfferClaim;
Capability;
NeedPattern;
CustomerPrerequisite;
SellerConstraint;
OfferCondition;
OfferExclusion;
AntiFitPattern;
OfferReadinessAssessment;
CommercialConfigurationPolicy;
SolutionFitAssessment;
ResponsibleCommercialPromise;
ProposalVersion;
DecisionFriction;
Commitment.

18.5 Sales — outcome e learning

DecisionOutcomeRecord;
ContractedPromiseSnapshot;
OfferRealityObservation;
OfferChangeProposal;
OutcomeObservation;
LearningCandidate.

18.6 Projeções / One-Pages

Não são automaticamente entidades canônicas independentes:

Offer Passport;
Lead Intelligence Brief;
Meeting Prep Brief;
Discovery Snapshot;
Customer Need Truth Snapshot;
Proposal Ready Package;
Decision Communication Profile;
Presentation Plan;
Presentation Debrief;
Decision Feedback Brief;
Relevant Value Stack;
Delivery Handoff Package;
Commercial Outcome One-Page;
Value Reality One-Page.

A decisão física de persistência/materialização pertence à arquitetura técnica e aos ADRs correspondentes.

19. Contratos entre etapas

Origem	Destino	Contrato mínimo
E0.CORE	E0.SALES	Organization Context Snapshot + Domain Activation/Readiness
E0.SALES	E3	OfferVersion + Offer Passport + Commercial Configuration Policy + boundaries
E1	E2	Lead Intelligence Brief + gaps + hypotheses + historical status
E2	Gates	NeedInstance + Customer Need Truth Working/Snapshot + evidence
Need Isolation Gate	Opportunity Gate	Need state + gate rationale + unresolved gaps
Opportunity Gate	E3	`CREATE` + pinned Customer Need Truth Snapshot
E3	E4	Proposal Ready Package + Responsible Commercial Promise + Commercial Configuration
E4	Human Presentation	ProposalVersion + Presentation Plan + Decision Ask
Presentation	E5	Presentation Debrief, somente se ciclo não encerrar
E5	E4	Proposal revision request quando comunicação/documento precisar mudar
E5	E2/E3/E0.SALES	material change / out-of-boundary routing
E5	E6	Decision Resolution / closure state
E6	Delivery	Contracted Promise Snapshot + Delivery Handoff Package
E6	E0.SALES	Offer Reality Observation + Learning Candidate + Change Proposal
E6	E1/E2/E3/E4/E5	learnings governados e revalidation signals

20. Human Review e autoridade

A IA pode:

estruturar fontes;
sugerir classificações;
sintetizar drafts;
apontar gaps e contradictions;
preparar perguntas;
propor fit e alternatives;
montar proposta a partir de objetos governados;
preparar CRR + open questions;
sugerir learning candidates.

A IA não pode autonomamente:

transformar hipótese em fato;
aprovar Need Isolation Gate ou Opportunity Gate material quando revisão humana for requerida;
aprovar OfferVersion, claim material, pricing exception ou out-of-boundary configuration;
conceder desconto ou condição fora de autoridade;
alterar Responsible Commercial Promise;
enviar comunicação material em nome do seller sem regra/autorização correspondente;
reescrever histórico;
declarar causalidade de outcome;
generalizar learning;
expor protected know-how.

21. Segurança, privacidade e segregação

Requisitos transversais:

tenant isolation e RLS;
least privilege;
purpose limitation;
minimização de dados;
retenção proporcional;
field-level access para economics sensíveis quando necessário;
provenance de IA;
audit trail de decisões materiais;
versionamento e supersession sem hard delete indevido;
nenhuma gravação/transcrição de reunião sem base, autorização e política aplicável;
nenhuma inferência demográfica invasiva para persuasão;
outputs/exportações identificam organização, versão, data e contexto suficiente para evitar reutilização indevida.

22. One-Page First + Evidence on Demand

Cada etapa deve priorizar uma visão curta para decisão, com drill-down para evidência.

Etapa	One-Page principal
E0.CORE	Organization Context / Readiness
E0.SALES	Offer Passport
E1	Lead Intelligence Brief
E2.1	Meeting Prep Brief
E2.3	Discovery Snapshot / Customer Need Truth
Gates	Gate Decision One-Page
E3	Responsible Solution Fit / Proposal Ready
E4	Decision Communication / Presentation Plan
E5	Decision Feedback Brief
E6	Commercial Outcome / Value Reality

Princípio:

simple experience, rigorous traceability.

23. Estados comerciais consolidados

A implementação não deve virar CRM completo apenas para reproduzir estados. Estados existem para governar conhecimento e decisão.

23.1 Need

SUSPECTED → EXPLORED → ISOLATED → CLIENT_VALIDATED
                         ↘ REJECTED

23.2 Offer readiness/lifecycle

Os detalhes permanecem no E0.SALES. E3 somente usa versões elegíveis e válidas.

23.3 Solution Fit

STRONG_FIT
CONDITIONAL_FIT
PARTIAL_FIT
NO_FIT
MORE_EVIDENCE_REQUIRED
SPECIALIST_REVIEW_REQUIRED

23.4 Proposal

DRAFT
→ READY_FOR_REVIEW
→ INTERNAL_REVIEWED
→ PRESENTATION_READY
→ PRESENTED
→ SEND_AUTHORIZED
→ SENT

23.5 Decision / Closure

Enquanto houver compromisso ativo: E5.

Quando resolvido/estacionado:

WON
LOST
POSTPONED
NO_DECISION
WITHDRAWN_BY_SELLER
CLOSED_NO_OPPORTUNITY
NO_FIT
UNKNOWN

24. Invariantes sistêmicos v0.3

Nenhuma evidência relevante sem fonte ou origem rastreável.
Nenhum estado material sem data, ator ou mecanismo de responsabilidade.
Nenhuma Commercial Opportunity antes do Opportunity Gate.
Nenhum E3 antes de Need suficientemente isolada e oportunidade criada.
Nenhuma Offer selecionada apenas porque existe no catálogo.
Nenhuma hipótese apresentada como fato.
Nenhum claim sem status, limite e evidência correspondente.
Nenhuma configuração comercial fora do boundary sem review.
Nenhuma concessão fora de authority sem Human Review.
Nenhuma comunicação pode alterar a verdade para se adaptar ao perfil.
Nenhuma proposta deve expor protected know-how necessário apenas para execução.
Nenhuma primeira apresentação deve depender de uso intensivo do sistema.
Nenhuma objeção deve ser automaticamente tratada como causa-raiz.
Nenhuma oportunidade permanece indefinidamente aberta sem compromisso ou trigger legítimo.
Nenhum WON prova value delivered.
Nenhum LOST prova absence of value.
Nenhum outcome observado prova causalidade automaticamente.
Nenhum Contracted Promise Snapshot é reescrito para refletir o que aconteceu depois.
Nenhum learning de um caso vira regra universal automaticamente.
Nenhuma mudança material é aplicada silenciosamente ao passado.
Nenhum dado cruza tenant boundary.
Nenhuma documentação é apresentada como funcionalidade implementada.

25. Minimum Viable Sales Domain Slice — visão consolidada

A v0.3 define a arquitetura completa, mas implementação deve ocorrer por incrementos.

Fatia mínima para provar o ciclo Sales:

Tenant / Membership / RLS
→ E0.CORE Context mínimo
→ uma OfferVersion utilizável
→ Lead Intelligence Brief
→ Meeting Prep
→ Post-Meeting Intelligence
→ NeedInstance
→ Customer Need Truth mínimo
→ Need Isolation Gate
→ Opportunity Gate
→ Responsible Solution Fit assistido
→ Proposal Ready Package
→ Human Presentation preparada
→ Presentation Debrief quando necessário
→ Decision Resolution
→ Outcome / Learning Candidate

Minimum viable não exige automaticamente:

CRM completo;
CPQ completo;
forecasting preditivo;
ML;
cadências autônomas;
live meeting copilot invasivo;
pricing optimization;
knowledge graph dedicado;
automação irreversível de decisão.

26. Classificação de novas ideias no Sales

Toda nova ideia deve ser classificada como:

necessária para completar o fluxo atual;
necessária para segurança, segregação ou confiabilidade;
necessária para piloto real;
melhoria baseada em evidência;
expansão pós-fatia mínima;
fora de escopo.

Somente 1–3 são candidatas imediatas de incremento. A arquitetura completa não é autorização para implementação simultânea.

27. Estratégia de validação

A validação deve evoluir de forma incremental:

dados sintéticos para estados, objetos, RLS e gates;
LC Verum como laboratório interno, sem tratar como template universal;
replay de casos históricos com revalidação explícita;
operação assistida E0–E6;
pilotos externos;
medição de esforço, utilidade, qualidade, disposição de pagamento e outcomes;
learning registry e change proposals governados.

Antes de claims fortes, exigir evidência funcional e de mercado correspondente.

28. Critérios de aceite arquiteturais da consolidação

29. Hierarquia documental a partir da v0.3

decisão explícita mais recente das Founders;
Founder Resolutions / Decision Log;
Orquestro v3 MVP Modular Consolidado vigente;
este documento — Orquestro™ v0.3 consolidado;
standalones E0.CORE, E0.SALES, E2, E3, E4, E5 e E6 incorporados abaixo;
PRDs/incrementos derivados;
materiais históricos e v0.2 anterior.

Os standalones não são descartados. Eles preservam profundidade e critérios técnicos. A v0.3 governa a integração entre eles.

30. Mapa das fontes incorporadas

Bloco	Fonte incorporada
Foundation	`Orquestro_E0_CORE_Organizational_Context_Implementation_Intelligence_v0.1_2026-08-22.md`
Offer	`Orquestro_E0_SALES_Offer_Intelligence_Commercial_Readiness_v0.2_2026-08-22.md`
Lead	seção E1 preservada da `Orquestro_Sales_Intelligence_Modulo_v0.2_2026-08-21.md`, com conflitos resolvidos pela v0.3
Discovery	`Orquestro_E2_Human_Discovery_Customer_Need_Truth_v0.2_2026-08-22.md`
Fit	`Orquestro_E3_Responsible_Solution_Fit_v0.1_2026-08-22.md`
Communication	`Orquestro_E4_Decision_Communication_v0.1_2026-08-22.md`
Decision cycles	`Orquestro_E5_Decision_Conversation_Feedback_Intelligence_v0.1_2026-08-22.md`
Outcome/Learning	`Orquestro_E6_Decision_Outcome_Handoff_Commercial_Learning_v0.1_2026-08-22.md`
Platform scope	`Orquestro_v3_MVP_Modular_Consolidado_v0.5_2026-08-22.md`

PARTE II — ESPECIFICAÇÕES DETALHADAS INCORPORADAS

Os blocos abaixo preservam o conteúdo das especificações aprovadas. Seus headings foram demovidos apenas para caber na hierarquia deste documento. Em caso de conflito semântico, prevalecem as decisões consolidadas da Parte I.

E0.CORE — Organizational Context & Implementation Intelligence v0.1

Fonte incorporada integralmente: Orquestro_E0_CORE_Organizational_Context_Implementation_Intelligence_v0.1_2026-08-22.md

Orquestro E0.CORE — Organizational Context & Implementation Intelligence

Definição funcional: Identity, Context, Readiness & Activation
Versão: 0.1
Data: 22/08/2026
Status: baseline arquitetural aprovada para especificação e desenvolvimento incremental
Classificação: Foundation transversal do Orquestro v3
Escopo do documento: arquitetura funcional, conhecimento, experiência, dados, governança e Minimum Viable E0 Slice
Fonte metodológica obrigatória aplicada: PRODUCT_PROMPT.md — Product Markdown Rail

Aviso de maturidade: este documento define a arquitetura pretendida da E0.CORE. Não comprova que o fluxo, as entidades, os controles ou as integrações estejam implementados, validados ou prontos para produção.

1. Finalidade do documento

Este documento especifica a E0.CORE — Organizational Context & Implementation Intelligence, a etapa transversal que prepara uma organização para utilizar o Orquestro com contexto suficiente, finalidade legítima, segregação, prontidão, responsabilidade e rastreabilidade.

Ele deve orientar:

produto;
arquitetura de conhecimento;
experiência do usuário;
modelagem de dados;
segurança e privacidade;
desenvolvimento assistido por IA;
operação de implantação;
testes internos e pilotos;
ativação dos Domain Packs;
futuras revisões da arquitetura modular.

O documento não substitui PRDs menores de funcionalidades específicas. Cada incremento técnico poderá gerar PRDs próprios segundo a taxonomia estrita do Product Markdown Rail.

2. Decisão arquitetural aprovada

A E0 deixa de ser tratada apenas como cadastro inicial ou etapa exclusiva do Sales Intelligence.

Decisão aprovada:

A E0.CORE é a fundação transversal que constrói, valida, versiona e mantém o contexto organizacional necessário para que qualquer Domain Pack opere com coerência, evidência, limites de acesso e compreensão da realidade da organização.

Desdobramentos:

a E0.CORE precede a ativação dos Domain Packs;
o contexto comum não será duplicado em cada módulo;
cada domínio poderá possuir uma extensão E0.DOMAIN;
E0.SALES preservará Company & Offer Intelligence;
prontidão será avaliada por módulo, e não por um score único da empresa;
cada ativação material exigirá um Domain Activation Contract;
o contexto permanecerá vivo, temporal, versionado e governado;
descobertas dos módulos não alterarão silenciosamente a E0.CORE.

3. Truthmode e fronteira de evidência

3.1 Fatos e decisões vigentes

o Orquestro v3 foi aprovado como Minimum Viable Platform modular;
Foundation, E0 e Knowledge & Decision Core pertencem ao caminho crítico comum;
todos os Domain Packs aprovados dependem de contexto, autorização e ativação;
Sales Intelligence permanece a wedge e a primeira prova ponta a ponta;
a E0 transversal já havia sido indicada na arquitetura consolidada, mas ainda não possuía especificação completa;
esta arquitetura da E0.CORE foi aprovada pelas Founders nesta versão conceitual.

3.2 Ainda não comprovado

implementação funcional completa da E0.CORE;
eficácia da jornada em organizações externas;
redução mensurável do esforço de implantação;
integração automática com fontes empresariais;
qualidade de extração assistida por IA;
aderência do modelo a diferentes setores e portes;
economics da implantação;
escala operacional;
readiness para produção.

3.3 Regra de comunicação

É permitido afirmar que a E0.CORE está arquitetada e aprovada como baseline. Não é permitido afirmar que está implementada, validada, automatizada ou pronta para produção sem evidência funcional correspondente.

4. Tese central

Nenhum módulo deveria aconselhar uma organização que ainda não compreende suficientemente.

A E0.CORE existe para responder, de forma governada:

de qual organização estamos falando;
qual parte dela está no escopo;
qual contexto estava válido;
quem autorizou o uso;
para qual finalidade;
quais fontes sustentam as informações;
o que ainda não se sabe;
onde existem conflitos;
quem pode acessar;
qual módulo pode ser ativado;
sob quais condições;
com qual objetivo;
com qual capacidade real de implantação.

5. Problema que a E0.CORE resolve

Sem uma fundação transversal de contexto:

módulos repetem perguntas e cadastros;
áreas diferentes trabalham com versões incompatíveis da organização;
decisões utilizam informações antigas sem indicação temporal;
a estrutura formal é confundida com a operação real;
acesso a dados pode ultrapassar finalidade e necessidade;
módulos podem ser ativados sem patrocinador, owner ou capacidade de mudança;
a plataforma recomenda ações sem compreender restrições relevantes;
o cliente recebe análises fragmentadas e contraditórias;
aprendizados não retornam a uma fonte organizacional comum;
o Orquestro se aproxima de formulários independentes em vez de uma plataforma de conhecimento.

6. Definição funcional

Nome oficial: E0.CORE — Organizational Context & Implementation Intelligence
Subtítulo: Identity, Context, Readiness & Activation

Definição:

Camada transversal do Orquestro responsável por estruturar o perímetro organizacional, o contexto compartilhado, a finalidade de uso, a prontidão de implantação e os contratos de ativação dos domínios.

A E0.CORE é simultaneamente:

jornada de implantação;
arquitetura de contexto;
controle de entrada;
mecanismo de readiness;
contrato de ativação;
baseline temporal;
ciclo de manutenção contextual.

7. Posição na arquitetura do Orquestro

flowchart TB
    F["Foundation técnica\nTenant · Identity · Security · RLS · Audit"]
    E0["E0.CORE\nIdentity · Context · Readiness · Activation"]
    K["Knowledge & Decision Core\nEvidence · Knowledge · Decision · Action · Learning"]
    D["E0.DOMAIN + Domain Packs\nSales · Compliance · Management · demais"]
    X["Experience Layer\nOne-Page · Board · Middle · Specialist"]

    F --> E0
    K <--> E0
    E0 --> D
    K <--> D
    D --> X
    E0 --> X

Essa é uma representação lógica. Não exige microsserviços, bancos ou repositórios separados.

8. Fronteira entre Foundation, E0.CORE e Knowledge Core

Camada	Responsabilidade primária	Não deve absorver
Foundation técnica	tenant, autenticação, membership, RLS, segurança, armazenamento, auditoria e infraestrutura	semântica empresarial detalhada
E0.CORE	contexto organizacional, finalidade, readiness, baseline e ativação	lógica especializada de cada domínio
Knowledge & Decision Core	fontes, evidências, conhecimento, hipóteses, gaps, decisões, ações, outcomes e learnings	cadastro paralelo de organização ou regras específicas de domínio
E0.DOMAIN	contexto inicial especializado do domínio ativado	duplicação do contexto comum
Domain Pack	jornada, objetos, regras e decisões especializadas	alteração silenciosa da E0.CORE

Regra:

Foundation fornece o ambiente seguro; E0.CORE explica em qual organização e contexto ele será utilizado; o Core preserva conhecimento e decisão; os domínios aplicam inteligência especializada.

9. E0.CORE versus E0.DOMAIN

9.1 E0.CORE

Mantém o contexto mínimo compartilhado por toda a plataforma:

identidade e perímetro;
entidades e unidades;
estratégia e prioridades;
governança e decisão;
operating model resumido;
sistemas e fontes;
riscos e restrições iniciais;
stakeholders estratégicos;
capacidade de mudança;
finalidade, acesso e ativação.

9.2 E0.DOMAIN

Aprofunda apenas o que o domínio necessita.

Exemplos:

E0.SALES: Company & Offer Intelligence;
E0.COMPLIANCE: ambiente regulatório, requisitos e programa existente;
E0.MANAGEMENT: sistema de gestão, fóruns, metas e cadência;
E0.OPERATIONS: cadeia de valor, capacidade e controles operacionais;
E0.FINANCIAL_FISCAL: entidades, regimes, sistemas e calendários relevantes;
E0.PEOPLE: estrutura, lideranças, papéis críticos e condições de gestão;
E0.CUSTOMER_VALUE: segmentos, jornadas e promessas de valor;
E0.PROJECT_PORTFOLIO: iniciativas, capacidade e critérios de portfólio;
E0.REPUTATION_STAKEHOLDER: stakeholders, compromissos e contexto público.

9.3 Regra de não duplicação

O domínio deve referenciar o contexto aprovado e acrescentar especialização. Não deve copiar dados comuns para criar uma verdade paralela.

10. Relação com E0.SALES

A antiga formulação Company & Offer Intelligence + Diagnóstico de Implementação é separada em duas responsabilidades:

E0.CORE
Organizational Context & Implementation Intelligence
        ↓
E0.SALES
Company & Offer Intelligence
        ↓
E1 Lead Intelligence
→ E2 Discovery
→ E3 Responsible Solution Fit

E0.CORE fornece contexto, governança, capacidade, restrições e autorização. E0.SALES estrutura ofertas, capabilities, claims, ICP, evidências, limites e prontidão comercial.

11. Princípios operacionais

Context before advice — compreender antes de recomendar.
Purpose before ingestion — definir finalidade antes de coletar dados.
Thin shared baseline, deep domain knowledge — contexto comum enxuto; profundidade no domínio.
Unknown is a valid state — ausência de informação não será preenchida por suposição.
Temporal truth — contexto possui data, validade e versão.
Source-aware — afirmações relevantes retornam à fonte.
Human-governed activation — IA não aprova baseline nem ativa domínio.
Readiness by domain — prontidão é contextual e modular.
Progressive onboarding — perguntar apenas o necessário e reutilizar evidências.
No silent mutation — módulos não alteram contexto aprovado sem fluxo governado.
Evidence on demand — síntese primeiro, profundidade quando necessária.
Governance proportional to risk — controles aumentam conforme sensibilidade e impacto.

12. Resultados esperados

Quando concluída para um escopo determinado, a E0.CORE deve produzir:

perímetro organizacional definido;
finalidade e autorização registradas;
contexto mínimo estruturado;
fontes e responsáveis identificados;
gaps e conflitos explícitos;
avaliação de prontidão por módulo;
condições e bloqueadores visíveis;
Domain Activation Contract;
Organizational Context Snapshot aprovado;
One-Pages adequadas aos papéis;
decisão rastreável de ativar, condicionar, limitar, adiar ou não ativar.

13. O que a E0.CORE não é

A E0.CORE não é:

ERP ou cadastro mestre universal;
data warehouse empresarial;
questionário extensivo de maturidade;
auditoria completa de todos os domínios;
consultoria empresarial automatizada;
diagnóstico jurídico, fiscal, psicológico ou clínico;
mecanismo de certificação;
digital twin operacional em tempo real;
scoring único da organização;
repositório irrestrito de todos os dados;
substituto dos Domain Packs;
autorização para coletar dados sem finalidade.

14. Objeto central

O objeto central é o Organization Context.

Ele representa o contexto vivo, governado e escopado da organização dentro do Orquestro.

Três formas complementares são necessárias:

Forma	Função
Organization Context	contexto vivo e atualizável
Implementation Case	jornada de implantação e ativação em determinado escopo
Organizational Context Snapshot	fotografia aprovada e imutável por versão

O contexto vivo não substitui snapshots históricos. O snapshot não impede evolução do contexto vivo.

15. Modelo conceitual de objetos

Objetos próprios e relacionados:

OrganizationContext;
ImplementationCase;
ContextAssertion;
ContextAssertionEvidence;
ContextGap;
ContextConflict;
ReadinessAssessment;
ReadinessDimensionResult;
ReadinessCondition;
DomainActivationContract;
ModuleActivation;
OrganizationalContextSnapshot;
ContextChangeEvent;
ContextReview;
ContextVocabularyItem.

Objetos compartilhados utilizados:

Organization/Tenant;
OrganizationUnit;
User, Membership e Role;
Project/Engagement;
Source e EvidenceItem;
Observation, Hypothesis, Gap e KnowledgeItem;
HumanReview;
Decision;
Action, Outcome e Learning;
AuditEvent e Version;
OnePage e Report.

16. Organization Context

Campos conceituais mínimos:

id;
tenant_id;
organization_id;
scope_type;
scope_id;
purpose;
status;
current_snapshot_id;
context_owner_membership_id;
sponsor_membership_id;
valid_from;
next_review_at;
created_at;
updated_at.

Regras:

pertence a um único tenant;
possui escopo explícito;
pode cobrir grupo, entidade, unidade ou engagement;
possui owner e sponsor definidos quando aplicável;
referências a informações sensíveis respeitam finalidade e acesso;
alterações materiais geram revisão e histórico.

17. Implementation Case

O ImplementationCase organiza a jornada E0 para um escopo e uma onda de implantação.

Exemplos:

primeira implantação da organização;
inclusão de nova unidade;
ativação de novo domínio;
reativação após pausa;
revisão causada por fusão, aquisição ou reestruturação;
implantação conduzida por parceiro ou BPO autorizado.

Campos conceituais:

organização e escopo;
objetivo;
patrocinador;
implementation lead;
participantes;
domínios candidatos;
estado da jornada;
bloqueadores;
condições;
datas relevantes;
snapshot de entrada;
snapshot aprovado;
decisão final.

18. Context Assertion

Uma ContextAssertion é uma afirmação estruturada sobre a organização.

Exemplos:

“a diretoria aprova todas as contratações”;
“a empresa possui três unidades operacionais”;
“a prioridade estratégica atual é aumentar recorrência”;
“o ERP é a fonte primária do faturamento”.

Toda assertion material deve registrar:

conteúdo;
categoria;
escopo;
classificação epistemológica;
fonte ou origem;
autor ou responsável;
temporalidade;
estado de revisão;
sensibilidade;
evidência vinculada;
conflitos conhecidos.

Uma declaração não se transforma automaticamente em fato institucional.

19. Classificação epistemológica

Classe	Significado
FACT/EVIDENCE	sustentado por evidência verificável no escopo declarado
ORGANIZATION STATEMENT	declaração formal ou institucional da organização
PARTICIPANT STATEMENT	declaração de uma pessoa participante
OBSERVATION	percepção humana contextual
HYPOTHESIS	interpretação ainda sujeita a teste
GAP	conhecimento ausente ou insuficiente
CONFLICT	afirmações ou evidências incompatíveis
DECISION	escolha humana aprovada
LEARNING	conclusão derivada de resultado e evidência disponível

Regras:

percepção não vira fato;
documento não prova automaticamente execução;
declaração de fundador não apaga evidência divergente;
IA pode sugerir classificação, mas não promover hipótese a fato;
mudanças de classe exigem histórico e justificativa.

20. Context Assertion Evidence

O vínculo entre assertion e evidência registra:

assertion_id;
evidence_item_id;
tipo de suporte: confirma, contradiz, contextualiza ou limita;
trecho ou locator permitido;
período coberto;
força ou suficiência qualitativa;
restrições de uso;
responsável pelo vínculo;
data da revisão.

Não deve existir peso proprietário ou score opaco exposto como verdade.

21. Context Gap

Um ContextGap registra conhecimento necessário, mas ausente ou insuficiente.

Tipos iniciais:

missing information;
missing owner;
missing source;
stale information;
insufficient evidence;
unclear scope;
unknown applicability;
access restricted;
specialist review required.

Campos relevantes:

pergunta não respondida;
impacto potencial;
módulo afetado;
materialidade;
owner da resolução;
data-alvo;
estado;
tratamento provisório.

Gaps não devem ser ocultados para produzir aparência de completude.

22. Context Conflict

Um ContextConflict existe quando fontes, versões ou atores sustentam afirmações incompatíveis.

Exemplos:

organograma formal diverge da autoridade real;
política afirma um controle, mas evidência operacional indica ausência;
dois diretores atribuem ownership à outra área;
sistema e planilha apresentam valores incompatíveis;
documento atual contradiz orientação histórica ainda praticada.

Estados:

OPEN
→ UNDER_REVIEW
→ EXPLAINED
→ RESOLVED
→ ACCEPTED_AS_PERSISTENT
→ SUPERSEDED

O sistema não resolve conflitos materiais automaticamente.

23. Official–Observed Delta

O Official–Observed Delta diferencia quatro perspectivas:

como a organização declara que funciona;
como documentos determinam que deveria funcionar;
como participantes relatam que funciona;
como as evidências indicam que funciona.

O delta não é automaticamente não conformidade. Pode representar:

adaptação legítima;
informalidade funcional;
documento desatualizado;
controle não implementado;
exceção não registrada;
diferença de escopo;
percepção parcial;
conflito material.

A E0 identifica o delta e o encaminha ao domínio proprietário quando exigir aprofundamento.

24. Context Debt

Context Debt é o conjunto de decisões e análises expostas a contexto ausente, desatualizado, contraditório, sem owner ou excessivamente tácito.

Não é:

score de maturidade;
valor contábil;
diagnóstico automático;
ranking público;
rótulo de incompetência.

Deve ser representado por uma carteira de itens com:

natureza da dívida;
decisões afetadas;
módulos impactados;
risco de manutenção;
responsável;
tratamento;
evidência de resolução.

No Minimum Viable E0 Slice, Context Debt pode ser derivado de gaps, conflitos e itens vencidos, sem mecanismo analítico avançado.

25. Change Load Map

O Change Load Map registra a carga de transformação que compete pela atenção e capacidade da organização.

Elementos possíveis:

projetos ativos;
mudanças regulatórias;
implantações de sistemas;
reestruturações;
auditorias;
certificações;
sucessões;
campanhas ou ciclos sazonais;
dependência das mesmas lideranças;
capacidade disponível declarada;
conflitos de calendário.

Objetivo:

evitar ativar módulos ou ações em uma velocidade superior à capacidade de absorção da organização.

No MVP, o mapa pode ser manual e qualitativo. Previsão automática de capacidade não pertence à fatia mínima.

26. Critical Knowledge Map

O mapa de conhecimento crítico identifica, em nível inicial:

conhecimento concentrado em pessoas-chave;
processos sem fonte confiável;
decisões dependentes de memória;
vocabulário específico;
documentos essenciais;
especialistas internos e externos;
riscos de perda de continuidade.

A E0 registra o sinal e o contexto mínimo. People, Process, Operations ou outro domínio aprofunda conforme ownership.

27. Perímetro organizacional

A E0 deve suportar:

uma organização independente;
grupo econômico;
holding;
múltiplas entidades jurídicas;
unidades de negócio;
filiais;
marcas;
operações compartilhadas;
joint ventures, quando autorizadas;
prestadores externos;
BPOs;
consultorias;
organizações familiares.

O perímetro deve distinguir:

quem pertence ao tenant;
quem é parte do contexto, mas não usuário;
quem é terceiro autorizado;
quais dados podem atravessar entidades;
qual unidade responde por cada informação.

28. Context inheritance

O contexto pode ser herdado em cascata:

Grupo empresarial
└── Entidade jurídica
    └── Unidade de negócio
        └── Área
            └── Project/Engagement
                └── Domain Case

Regras:

o nível inferior herda apenas itens aplicáveis e autorizados;
exceções devem ser explícitas;
override registra motivo, responsável e validade;
item sensível não é herdado apenas por conveniência;
mudança no nível superior identifica consumidores afetados;
herança não substitui RLS nem autorização por finalidade.

29. Escopo e precedência contextual

Quando houver múltiplos contextos aplicáveis, a precedência conceitual será:

regra específica válida do Domain Case;
regra específica do Project/Engagement;
regra da área ou unidade;
regra da entidade jurídica;
regra corporativa ou do grupo.

Uma regra inferior só prevalece quando:

o override é permitido;
existe justificativa;
o período de validade está definido;
não viola controle obrigatório superior;
o usuário possui autorização.

Conflitos de precedência devem ser apresentados para Human Review.

30. Temporalidade e validade

Todo contexto material deve considerar:

observed_at — quando foi observado;
valid_from — quando passou a valer;
valid_to — quando deixou de valer, se conhecido;
recorded_at — quando entrou no Orquestro;
reviewed_at — quando foi revisado;
next_review_at — próxima revisão prevista;
superseded_by — versão que o substituiu.

Princípio:

Historical Organizational Evidence ≠ Current Organizational Truth.

O sistema deve indicar quando uma informação histórica está sendo reutilizada e exigir revalidação quando sua atualidade for material para a decisão.

31. Três relógios do contexto

A E0 deve distinguir três ritmos de mudança:

Relógio	Exemplos	Revisão típica
Estrutural	identidade, entidades, governança, modelo de negócio	por evento material ou revisão periódica
Gerencial	prioridades, metas, owners, portfólio, capacidade	por ciclo de gestão
Situacional	crise, indisponibilidade, projeto, exceção, restrição temporária	orientada por evento

Não serão fixados prazos universais de validade nesta baseline. Cada categoria ou organização poderá ter política própria, sujeita a futura deliberação técnica e de governança.

32. Vocabulário organizacional

A E0.CORE pode manter um vocabulário controlado com:

nomes oficiais e nomes usuais;
siglas;
áreas;
papéis;
fóruns;
produtos e serviços;
termos internos;
sinônimos;
termos proibidos ou obsoletos;
vigência;
owner semântico.

Objetivos:

reduzir ambiguidade;
preservar linguagem da organização;
melhorar busca e extração;
evitar que a IA normalize termos incorretamente;
permitir que módulos compartilhem a mesma semântica.

O vocabulário não deve expor taxonomias proprietárias internas do Orquestro sem necessidade.

33. Modos operacionais da E0

Modo	Uso	Limites
Assisted	implantação conduzida com apoio humano intensivo	maior esforço operacional; indicado para primeiros testes
Guided	usuário executa fluxo com orientações e revisões pontuais	depende de UX e materiais estáveis
Self-Service	organização conduz a maior parte da implantação	horizonte posterior; não presumir prontidão
Recovery	revisão após incidente, pausa, reestruturação ou contexto vencido	exige reavaliação de risco e acesso
Partner/BPO	implantação operada por terceiro autorizado	segregação e limites contratuais reforçados

O Minimum Viable E0 Slice pode operar de forma assistida. Isso deve ser comunicado como modo de operação, não como automação inexistente.

34. Jornada E0.CORE

flowchart TB
    A["E0.0 Authority, Purpose & Trust Boundary"]
    B["E0.1 Organizational Perimeter"]
    C["E0.2 Business, Strategy & Value Logic"]
    D["E0.3 Governance & Decision System"]
    E["E0.4 Operating Model & Capabilities"]
    F["E0.5 Risk, Obligation & Stakeholder Context"]
    G["E0.6 Data, Systems & Knowledge Readiness"]
    H["E0.7 Change & Implementation Readiness"]
    I["E0.8 Domain Activation"]
    J["E0.9 Baseline Approval & Launch"]
    K["Continuous Context Maintenance"]

    A --> B --> C --> D --> E --> F --> G --> H --> I --> J --> K
    K -. "material change" .-> B

As subetapas podem coletar informações em paralelo, mas os gates de autorização, integridade, prontidão e ativação continuam obrigatórios.

35. E0.0 — Authority, Purpose & Trust Boundary

Objetivo

Estabelecer autorização legítima, finalidade, perímetro inicial e limites de confiança antes da ingestão relevante de dados.

Entradas

solicitação de implantação;
patrocinador indicado;
organização e escopo pretendido;
módulos candidatos;
participantes iniciais;
termos, contratos e políticas aplicáveis;
informações mínimas de segurança e privacidade.

Decisões

quem autoriza;
para qual finalidade;
quais unidades entram;
quais dados podem ser utilizados;
quem pode participar;
se terceiros terão acesso;
se uso de IA é permitido e sob quais limites;
quais dados não devem ser coletados.

Saídas

E0 Charter inicial;
trust boundary;
matriz inicial de papéis;
propósito registrado;
restrições de dados;
decisão para prosseguir, condicionar ou interromper.

36. Authority & Purpose Gate

Perguntas obrigatórias:

existe patrocinador ou autoridade legítima identificada?
a finalidade está clara e registrada?
o perímetro inicial está definido?
os participantes possuem vínculo e necessidade?
existem restrições conhecidas de dados, confidencialidade ou conflito?
a coleta pretendida é proporcional à finalidade?

Resultados:

AUTHORIZED
AUTHORIZED_WITH_RESTRICTIONS
NEED_CLARIFICATION
NOT_AUTHORIZED

NOT_AUTHORIZED impede ingestão e ativação. NEED_CLARIFICATION permite apenas configuração mínima necessária para resolver a autorização.

37. E0.1 — Organizational Perimeter

Objetivo

Determinar quem é a organização no contexto do Orquestro e quais fronteiras jurídicas, operacionais e informacionais se aplicam.

Conteúdo mínimo

nome e identificadores necessários;
entidades jurídicas;
unidades e marcas;
relações societárias ou operacionais relevantes;
localizações relevantes;
estruturas compartilhadas;
terceiros críticos;
BPOs e operadores externos;
responsáveis por unidade;
limites de compartilhamento.

Avaliação

sistemas existentes;
documentos;
planilhas;
bases estruturadas;
entrevistas necessárias;
owners das fontes;
qualidade e atualidade;
sensibilidade;
finalidade permitida;
formato e acessibilidade;
integridade;
confiabilidade operacional;
vocabulário;
lacunas;
necessidade de extração ou integração.

Saídas

Source Map;
Data & Access Profile;
Knowledge Readiness Diagnostic;
gaps e conflitos;
plano de coleta complementar.

43. E0.7 — Change & Implementation Readiness

Objetivo

Avaliar se a organização possui condições reais de absorver o uso do Orquestro e o domínio candidato.

Questões centrais

existe patrocinador ativo?
existe owner operacional?
as pessoas necessárias têm disponibilidade?
decisões conseguem ser tomadas no tempo necessário?
os dados essenciais estão acessíveis?
existem bloqueadores de segurança, privacidade ou contrato?
a organização possui cadência de acompanhamento?
há sobrecarga de iniciativas?
existe capacidade de implementar recomendações?
os critérios de valor são observáveis?

Princípio

Necessidade alta não significa prontidão alta. A decisão pode ser iniciar de forma assistida, reduzir escopo, criar condições ou adiar.

44. E0.8 — Domain Activation

Objetivo

Decidir quais domínios serão ativados, em qual escopo, modo e condição.

Entradas

baseline contextual;
finalidade;
necessidade ou hipótese de valor;
readiness por módulo;
riscos e bloqueadores;
responsáveis;
dados permitidos;
critérios de sucesso;
capacidade de operação.

Saídas

DomainActivationContract;
ModuleActivation;
condições;
plano de readiness;
decisão humana registrada;
snapshot vinculado.

Regra

A sequência de construção do produto não obriga o cliente a contratar ou percorrer todos os módulos.

45. E0.9 — Baseline Approval & Launch

Objetivo

Consolidar uma versão aprovada do contexto e autorizar o início controlado do domínio.

Aprovação mínima

perímetro;
finalidade;
assertions materiais;
gaps e conflitos relevantes;
papéis;
readiness;
condições;
contrato de ativação;
riscos aceitos ou tratados;
critérios de revisão.

Saídas

OrganizationalContextSnapshot aprovado;
decisão de ativação;
One-Pages;
evento de negócio;
pacote de contexto para o domínio.

O baseline aprovado é imutável por versão. Correções criam nova versão ou registro formal de retificação.

46. Continuous Context Maintenance

A E0 não termina após a ativação.

O ciclo contínuo deve:

receber mudanças relevantes;
revisar itens vencidos;
tratar gaps e conflitos;
avaliar impacto em módulos ativos;
atualizar owners;
reavaliar readiness;
renovar ou alterar contratos;
criar novo snapshot quando necessário;
preservar o snapshot utilizado em decisões históricas.

Fluxo:

Context Change Event
→ Impact Assessment
→ Review
→ Update or Reject
→ New Snapshot, when material
→ Notify Affected Modules

47. Gatilhos de revisão contextual

Exemplos de eventos materiais:

mudança societária;
nova entidade ou unidade;
mudança de sponsor ou owner;
reestruturação organizacional;
alteração relevante de estratégia;
novo sistema crítico;
incidente material;
alteração regulatória relevante identificada por especialista;
fusão ou aquisição;
descontinuação de oferta ou operação;
ativação de novo domínio;
expiração de condição;
revogação de acesso;
descoberta de conflito em um domínio;
mudança de terceiro ou BPO;
crise reputacional;
sucessão de liderança;
revisão periódica prevista.

Nem todo evento exige novo snapshot. A materialidade deve ser revisada e registrada.

48. Readiness por módulo

A prontidão é avaliada para uma combinação específica:

Organization Scope
+ Domain Pack
+ Purpose
+ Time
+ Operating Mode

Uma organização pode estar:

pronta para Sales;
pronta com condições para Compliance;
bloqueada para Financial & Fiscal por dados não confiáveis;
apta apenas a piloto assistido de People;
temporariamente sobrecarregada para Project & Portfolio.

Não existe um único nível universal de maturidade da organização.

49. Dimensões de readiness

Dimensão	Pergunta
Purpose Clarity	o problema, objetivo e decisão esperada estão claros?
Sponsorship	existe autoridade ativa e comprometida?
Ownership	existem owners disponíveis e accountable?
Evidence & Data	fontes essenciais são suficientes, atuais e autorizadas?
Process Visibility	o fluxo mínimo relevante é compreensível?
Decision Capacity	decisões podem ocorrer na cadência necessária?
Change Capacity	a organização consegue absorver a implantação?
Change Load	outras iniciativas competem pela mesma capacidade?
Privacy, Security & Legal	existem condições mínimas e restrições tratadas?
Technical Readiness	sistemas, acesso e suporte são compatíveis?
Operating Cadence	existe rotina para acompanhar decisões e ações?
Value Measurement	o valor esperado pode ser observado sem métricas artificiais?

Dimensões podem ser especializadas por domínio, mas a semântica comum pertence à E0.CORE.

50. Estados de uma dimensão de readiness

UNKNOWN
READY
READY_WITH_CONDITIONS
BLOCKED
NOT_APPLICABLE

Regras:

UNKNOWN não equivale a baixo risco;
READY_WITH_CONDITIONS exige condições explícitas, owner e prazo;
BLOCKED impede ativação quando o bloqueador for material;
NOT_APPLICABLE exige justificativa;
IA pode sugerir estado, mas a decisão material requer Human Review;
nenhum percentual médio pode esconder bloqueador crítico.

51. Decisão consolidada de readiness

Resultados possíveis:

Decisão	Significado
ACTIVATE	condições mínimas atendidas
ACTIVATE_WITH_CONDITIONS	ativação autorizada com controles e prazos
ASSISTED_PILOT_ONLY	uso permitido apenas em modo assistido e limitado
REDUCE_SCOPE	escopo deve ser reduzido antes de ativar
NEED_MORE_EVIDENCE	gaps críticos impedem decisão
DEFER	necessidade pode existir, mas o momento não é adequado
DO_NOT_ACTIVATE	risco, falta de autoridade ou incompatibilidade impede ativação

Essa decisão é contextual, temporal e revisável. Não representa avaliação permanente da organização.

52. Readiness Plan

Quando a ativação não for imediata, a E0 produz plano de readiness com:

condição ou bloqueador;
motivo;
evidência;
risco associado;
ação necessária;
owner;
prazo ou gatilho;
evidência de conclusão;
impacto no escopo;
decisão de reavaliação.

O Readiness Plan não deve se transformar automaticamente em projeto amplo de consultoria. Ações fora do escopo contratado devem ser tratadas como recomendação ou nova decisão.

53. Gates consolidados da E0

Gate	Pergunta	Possíveis resultados
Authority & Purpose Gate	existe autorização legítima e finalidade clara?	authorize, restrict, clarify, deny
Context Integrity Gate	sabemos o que é evidência, declaração, observação, hipótese, gap ou conflito?	pass, conditional, review
Evidence Sufficiency Gate	existe base suficiente para o próximo passo?	sufficient, more evidence, blocked
Implementation Readiness Gate	a organização consegue absorver o domínio no escopo proposto?	activate, conditions, assisted only, defer
Domain Activation Gate	valor, owner, dados, limites e critérios estão definidos?	approve, revise, reject

Nenhum gate material pode ser aprovado apenas por IA.

54. Context Integrity Gate

Critérios mínimos:

assertions materiais possuem origem;
escopo e temporalidade estão explícitos;
hipóteses não aparecem como fatos;
gaps materiais estão visíveis;
conflitos não foram apagados;
owners de revisão estão definidos;
informação sensível possui classificação;
fontes históricas estão identificadas como históricas.

O gate não exige contexto perfeito. Exige contexto suficientemente íntegro para que as limitações sejam conhecidas.

55. Evidence Sufficiency Gate

A suficiência depende da decisão pretendida.

Exemplo:

dados mínimos podem ser suficientes para ativar um piloto assistido;
os mesmos dados podem ser insuficientes para recomendação financeira material;
uma declaração pode orientar perguntas, mas não sustentar conclusão de compliance;
um organograma pode estruturar permissões iniciais, mas não provar decisão real.

Resultado sempre deve registrar:

decisão que está sendo habilitada;
evidências utilizadas;
gaps aceitos;
riscos residuais;
reviewer;
validade.

56. Domain Activation Contract

O DomainActivationContract é o contrato operacional e informacional que governa a ativação de um domínio.

Conteúdo mínimo:

organização e unidade no escopo;
Domain Pack;
finalidade;
problema ou hipótese de valor;
sponsor;
domain owner;
participantes;
dados permitidos;
dados proibidos ou limitados;
baseline utilizado;
readiness decision;
condições e bloqueadores;
modo operacional;
decisões que o domínio pode apoiar;
decisões que permanecem fora do escopo;
critérios de sucesso;
cadência de revisão;
prazo ou vigência;
stop conditions;
aprovadores;
histórico.

Não precisa ser contrato jurídico. É um objeto de governança da plataforma e da implantação.

57. Estados do Domain Activation Contract

DRAFT
→ UNDER_REVIEW
→ APPROVED
→ ACTIVE
→ AMENDMENT_REQUIRED
→ PAUSED
→ EXPIRED
→ CLOSED
→ REJECTED

Regras:

APPROVED exige Human Review autorizado;
ACTIVE exige Module Activation compatível;
alteração material de finalidade, escopo ou dado gera amendment;
contrato expirado não autoriza novo processamento;
fechamento não apaga evidências e histórico sujeitos à retenção;
reativação exige revisão de contexto e readiness.

58. Module Activation

ModuleActivation representa o estado técnico-operacional do Domain Pack para determinado escopo.

Estados sugeridos:

PROPOSED
→ ASSESSING
→ APPROVED | CONDITIONAL | BLOCKED
→ ACTIVE
→ PAUSED | SUSPENDED
→ DEACTIVATED

Diferença:

Domain Activation Contract registra a autorização e as condições;
Module Activation controla a disponibilidade do domínio no escopo;
feature flag técnica não substitui o contrato;
contrato aprovado não prova que o módulo está implementado.

59. Condições, bloqueadores e exceções

Condição

Requisito que permite ativação limitada, com owner, prazo e controle compensatório.

Bloqueador

Impedimento material que torna a ativação insegura, ilegítima ou sem valor suficiente.

Exceção autorizada

Desvio deliberado de uma regra configurável, com:

fundamento;
aprovador;
escopo;
validade;
risco;
controle;
revisão.

Regras imutáveis de segregação, autorização e auditoria não podem ser dispensadas por exceção comum.

60. Pausa, suspensão, desativação e reativação

Ação	Quando usar	Efeito mínimo
Pause	decisão voluntária ou condição temporária	interrompe novas operações; preserva histórico
Suspend	risco, violação ou incidente	bloqueio imediato proporcional; exige revisão
Deactivate	encerramento planejado	encerra uso operacional e inicia regras de retenção
Reactivate	retorno após pausa ou desativação permitida	exige contexto, autorização e readiness atualizados

O comportamento de leitura após pausa ou desativação dependerá de papel, retenção e obrigação aplicável. Não haverá deleção física automática de histórico aprovado.

61. Estratégia de aquisição de contexto

A E0 adota aquisição progressiva e multimodal:

Configuração mínima
→ fontes existentes
→ extração assistida
→ gaps e conflitos
→ perguntas adaptativas
→ entrevistas direcionadas
→ revisão humana
→ baseline

Princípios:

reutilizar informação confiável já disponível;
não pedir ao usuário que digite o que pode revisar;
não coletar tudo “para usar no futuro”;
priorizar dados necessários ao domínio candidato;
permitir operação manual quando automação falhar;
registrar origem e transformação.

62. Progressive Context Onboarding

O onboarding deve ocorrer em camadas.

Camada 1 — Minimum Trust Setup

organização;
patrocinador;
finalidade;
participantes;
escopo;
restrições iniciais.

Camada 2 — Shared Context

estrutura;
estratégia resumida;
governança;
operating model;
sistemas e fontes.

Camada 3 — Readiness

gaps;
capacidade;
riscos;
owners;
condições.

Camada 4 — Domain Extension

perguntas e fontes específicas do domínio ativado.

O usuário deve visualizar progresso por suficiência para a decisão, não por quantidade arbitrária de campos preenchidos.

63. Ingestão documental

Tipos possíveis:

documentos institucionais;
organogramas;
políticas;
contratos autorizados;
relatórios;
apresentações;
manuais;
processos;
planilhas;
evidências de sistemas;
atas;
certificações;
registros históricos.

Safe-guards mínimos:

validação de tipo e tamanho;
verificação de segurança aplicável;
classificação de sensibilidade;
owner e finalidade;
versionamento;
falha de extração visível;
revisão de conteúdo extraído;
proibição de considerar upload como aprovação;
prevenção de acesso cross-tenant.

64. Entrevistas e conhecimento tácito

Entrevistas podem complementar fontes quando:

o conhecimento está concentrado;
documentos estão ausentes;
existem conflitos;
a governança real difere da formal;
decisões dependem de experiência;
o vocabulário não é compreendido.

Regras:

consentimento e finalidade devem estar claros;
o Orquestro prepara e estrutura; a conversa permanece humana;
declaração é atribuída ao participante e ao tempo;
percepção não vira fato;
divergências entre participantes permanecem visíveis;
inferências sensíveis exigem revisão;
não realizar profiling psicológico.

65. Integrações e fontes externas

Integrações podem, futuramente, apoiar atualização de contexto, mas não são requisito automático do Minimum Viable E0 Slice.

Cada integração deverá definir:

finalidade;
escopo;
credencial e owner;
frequência;
fonte de verdade;
campos importados;
política de erro;
idempotência;
retenção;
revogação;
impacto em snapshots;
auditoria.

No MVP, importações manuais e controladas são aceitáveis quando rastreáveis.

66. Papel da IA

A IA pode apoiar:

extração de informações de fontes autorizadas;
sugestão de categorias;
identificação de possíveis gaps;
detecção preliminar de contradições;
sumarização;
perguntas adaptativas;
rascunho de One-Pages;
checagem de consistência;
preparação de revisão.

Toda contribuição de IA deve registrar, conforme aplicável:

provedor ou modelo;
versão/configuração disponível;
data;
fontes utilizadas;
prompt ou referência protegida;
output original ou hash/locator conforme política;
transformação;
reviewer;
decisão humana.

A lógica proprietária sensível deve permanecer protegida.

67. Limites da IA

A IA não pode, sozinha:

autorizar coleta;
aprovar finalidade;
definir base legal;
resolver conflito material;
transformar hipótese em fato;
aceitar risco;
aprovar baseline;
ativar domínio;
conceder acesso;
remover bloqueador;
criar exceção de segurança;
declarar readiness definitivo;
declarar conformidade;
realizar diagnóstico psicológico;
inferir emoção como verdade;
excluir evidência material;
sobrescrever decisão humana.

Em falha de IA, a operação deve poder continuar manualmente quando seguro.

68. Human Review proporcional ao risco

Níveis conceituais:

Nível	Exemplo	Revisão
H0	metadado não sensível e determinístico	validação automática permitida
H1	extração simples ou classificação reversível	revisão por amostragem ou confirmação
H2	síntese que influencia readiness ou escopo	revisão humana obrigatória
H3	acesso, ativação, risco material ou conflito	aprovação por papel autorizado
H4	decisão sensível regulatória, fiscal, trabalhista ou similar	especialista competente quando aplicável

Os níveis são baseline conceitual. A matriz técnica definitiva deve ser deliberada e versionada.

69. Data, Privacy & AI Governance by Design

A E0 é o primeiro ponto de aplicação prática da governança transversal.

Controles mínimos:

finalidade;
minimização;
classificação;
segregação;
necessidade de acesso;
retenção;
proveniência;
revisão humana;
transparência sobre IA;
gestão de incidentes;
revogação;
auditoria;
tratamento de dados sensíveis;
restrição por unidade e domínio.

A E0 não automatiza conclusões jurídicas. Decisões especializadas permanecem com profissionais competentes.

70. Classificação de dados

Categorias conceituais iniciais:

Classe	Exemplo	Regra geral
Public	informação institucional pública	uso conforme finalidade e fonte
Internal	contexto interno comum	acesso por membership autorizado
Confidential	estratégia, contratos, riscos, dados financeiros	least privilege e auditoria reforçada
Restricted	dados pessoais sensíveis, denúncias, segredos ou material altamente crítico	acesso excepcional, finalidade estrita e controles reforçados

A classificação definitiva e seus controles técnicos deverão ser harmonizados com a política de segurança e privacidade do Orquestro.

71. Finalidade, autorização e base aplicável

Cada Implementation Case deve registrar:

finalidade operacional;
patrocinador;
categorias de dados;
escopo organizacional;
usuários e terceiros;
restrições;
período de uso;
fundamento ou base aplicável quando necessário;
responsável pela avaliação especializada;
revisão.

Regras:

finalidade genérica como “melhorar a empresa” é insuficiente para dados sensíveis;
mudança material de finalidade exige revisão;
autorização de negócio não substitui obrigação legal;
consentimento não deve ser presumido como única ou correta base;
o Orquestro não emite opinião jurídica automática.

72. Retenção, correção e exclusão

Princípios:

snapshots aprovados não são editados em silêncio;
correção cria nova versão ou retificação vinculada;
exclusão física segue política autorizada, obrigação aplicável e avaliação de impacto;
quando a remoção for exigida, preservar trilha mínima de que ocorreu sem manter conteúdo indevido;
desativação de módulo não implica apagamento imediato;
retenção não deve ser indefinida por padrão;
backups e derivados devem seguir política coerente;
dados de teste devem ser sintéticos ou devidamente autorizados.

73. Papéis funcionais

Papel	Responsabilidade principal
Organization Owner	autoridade institucional sobre o tenant
Tenant Admin	configuração de usuários e acessos, sem poder substantivo ilimitado
E0 Sponsor	patrocínio, propósito e decisões executivas da implantação
Implementation Lead	coordenação da jornada E0
Context Steward	qualidade, atualização e semântica do contexto
Domain Owner	responsabilidade pelo domínio ativado
Human Reviewer	revisão de sínteses e decisões conforme risco
Specialist Reviewer	revisão técnica especializada quando necessária
Contributor	fornecimento de contexto e evidências
Evidence Viewer	leitura limitada de evidências autorizadas
Board Viewer	acesso a síntese executiva adequada
External Partner/BPO	atuação limitada por contrato, escopo e finalidade
Platform Operator	suporte técnico sem acesso empresarial por padrão

Uma pessoa pode acumular papéis quando permitido, mas conflitos de interesse devem ser avaliados.

74. Matriz conceitual de permissões

Ação	Owner/Admin	Sponsor	Implementation Lead	Steward	Contributor	Board	External
configurar tenant e membership	permitido conforme papel	não	não	não	não	não	não
definir propósito	participa	aprova	prepara	consulta	não	consulta	não
adicionar fonte	permitido	permitido	permitido	permitido	permitido no escopo	não	limitado
editar assertion em rascunho	permitido	permitido	permitido	permitido	limitado	não	limitado
aprovar snapshot	conforme autorização	permitido	prepara	revisa	não	consulta	não por padrão
aprovar ativação	conforme governança	permitido	prepara	consulta	não	consulta	não por padrão
ver evidência restrita	por necessidade	por necessidade	por necessidade	por necessidade	limitado	não por padrão	excepcional
ver One-Page Board	permitido	permitido	permitido	permitido	não por padrão	permitido	não por padrão

A matriz definitiva deve ser configurável dentro de limites seguros. RLS e autorização no servidor prevalecem sobre ocultação visual.

75. Usuários com múltiplas organizações

Um usuário pode pertencer a múltiplos tenants apenas se a arquitetura técnica aprovar esse modelo.

Se permitido:

cada request deve possuir tenant ativo explícito;
troca de tenant deve ser visível;
cache e estado de interface devem ser isolados;
nenhuma busca pode misturar resultados;
links devem validar escopo;
logs devem registrar tenant e membership usados;
background jobs devem preservar o tenant;
exportações devem indicar organização e escopo.

A possibilidade técnica ainda deve ser confirmada por ADR. O safe-guard de não mistura é obrigatório em qualquer alternativa.

76. Terceiros, consultores e BPOs

A E0 deve suportar operação assistida por terceiros sem confundir delegação com transferência integral de responsabilidade.

Controles:

membership externo identificado;
organização empregadora ou vinculante;
escopo e unidade;
finalidade;
vigência;
dados permitidos;
proibição de reutilização;
exportação limitada;
revisão de acesso;
revogação;
logs;
sponsor interno;
responsabilidades preservadas.

Um BPO pode operar funções autorizadas, mas não aprovar decisões que exigem autoridade da organização salvo delegação formal e compatível.

77. Segregação de visões

A mesma fonte de verdade pode gerar visões diferentes:

Board;
sponsor;
middle management;
implementação;
specialist;
contributor;
external partner;
auditoria.

Regras:

síntese não cria verdade paralela;
detalhe sensível não aparece por conveniência;
ausência de permissão não deve revelar metadados indevidos;
redaction deve ser registrada quando material;
One-Page externa não expõe gaps internos sem autorização;
Board recebe decisão e exceção, não dump de dados.

78. Auditoria e regras imutáveis

Eventos materiais devem registrar:

tenant;
ator;
membership e papel;
ação;
objeto;
versão anterior e posterior quando aplicável;
timestamp;
origem;
motivo;
reviewer;
resultado;
correlação com job ou request.

Regras imutáveis:

nenhum Domain Pack altera snapshot aprovado;
nenhuma ativação material ocorre sem decisão humana autorizada;
nenhuma informação cross-tenant é retornada;
nenhuma hipótese é promovida silenciosamente a fato;
nenhum conflito material é apagado para concluir gate;
nenhuma mudança de finalidade ocorre sem revisão;
nenhum snapshot aprovado é sobrescrito;
nenhuma ação de IA fica sem proveniência quando influencia decisão material.

79. One-Page First + Evidence on Demand

A E0 adota o padrão:

Decisão necessária
→ One-Page por papel
→ evidência sob demanda
→ histórico e auditoria

One-Page não é resumo genérico. Deve responder:

o que está sendo decidido;
qual contexto importa;
o que sabemos;
o que não sabemos;
quais condições existem;
quem precisa agir;
qual é o próximo gate.

80. Organization Context One-Page

Conteúdo sugerido:

organização e escopo;
modelo de negócio resumido;
prioridades;
estrutura e decision owners;
cadeia de valor resumida;
sistemas e fontes essenciais;
stakeholders críticos;
restrições;
top gaps e conflitos;
snapshot e validade;
links para evidências autorizadas.

Não deve conter detalhes de todos os módulos.

81. Implementation Readiness One-Page

Conteúdo:

domínio avaliado;
propósito;
decisão proposta;
dimensões prontas;
condições;
bloqueadores;
gaps materiais;
change load;
sponsor e owner;
ações de readiness;
prazo ou gatilho de revisão;
evidências críticas.

Não deve reduzir readiness a uma média numérica.

82. Board Activation One-Page

Deve mostrar apenas:

por que ativar;
qual decisão é exigida;
onde começar;
valor esperado;
riscos materiais;
condições para sucesso;
recursos ou atenção necessários;
responsável;
próximos gates;
pedido de aprofundamento quando necessário.

Detalhes técnicos permanecem no Specialist View.

83. Specialist & Evidence View

Permite, conforme acesso:

navegar assertions;
abrir fontes;
visualizar temporalidade;
comparar versões;
examinar gaps;
analisar conflitos;
revisar proveniência de IA;
registrar parecer;
propor alteração;
rastrear decisão e audit events.

Não deve permitir editar snapshots aprovados.

84. Arquitetura de experiência

Áreas conceituais da interface:

Implementation Home — progresso, gates e decisões;
Organization Map — perímetro e relações;
Context Workspace — assertions, gaps e conflitos;
Source & Evidence Map — fontes e validade;
Readiness Workspace — dimensões, condições e plano;
Activation Workspace — contratos e módulos;
Snapshots & History — versões e impacto;
One-Pages — visões por papel;
Review Queue — itens pendentes de Human Review.

No MVP, essas áreas podem ser consolidadas em menos telas desde que estados e responsabilidades permaneçam claros.

85. Estados de interface

Empty State

Deve informar:

o que falta;
por que importa;
menor próxima ação;
quem pode executar;
se a ausência bloqueia ativação.

Loading State

indicar atividade em andamento;
não simular conclusão;
permitir sair da tela quando o job for assíncrono;
preservar idempotência;
mostrar status consultável.

Error State

mensagem clara e não técnica;
correlation id quando apropriado;
ação segura de retry;
garantia de que nenhum dado foi perdido, quando comprovável;
canal de suporte;
fallback manual quando permitido.

Restricted State

informar que o conteúdo não está disponível;
não revelar título, categoria ou existência quando isso violar acesso;
indicar procedimento legítimo de solicitação quando aplicável.

Stale State

mostrar que o contexto pode estar desatualizado;
impedir decisão material quando a validade for obrigatória;
permitir solicitação de revisão.

86. Experiência de gaps e conflitos

Gaps e conflitos devem ser apresentados sem linguagem acusatória.

Cada card deve indicar:

questão;
escopo;
fontes relacionadas;
impacto;
módulo afetado;
estado;
owner;
ação possível;
prazo ou gatilho;
se bloqueia o gate.

A interface não deve usar cores isoladamente para transmitir criticidade. Deve incluir rótulo e explicação textual.

87. Notificações e escalonamento

Eventos notificáveis:

review solicitado;
condição próxima do vencimento;
fonte vencida;
conflito material aberto;
acesso alterado;
ativação bloqueada;
contrato expirando;
domínio suspenso;
snapshot substituído;
mudança com impacto cross-domain.

Regras:

evitar excesso de notificações;
agrupar quando seguro;
respeitar papel e acesso;
materialidade define canal e urgência;
notificação não substitui registro;
escalonamento sensível permanece humano.

88. Core Flow — caminho feliz

Foundation cria ou valida tenant, usuário, membership e segregação.
usuário autorizado cria ImplementationCase.
sistema registra sponsor, finalidade, escopo e domínios candidatos.
Authority & Purpose Gate é aprovado.
usuário estrutura perímetro organizacional.
fontes são adicionadas com owner, finalidade e classificação.
sistema e usuários criam ContextAssertions com proveniência.
gaps e conflitos são registrados.
reviewer valida contexto suficiente para o escopo.
sistema cria ReadinessAssessment para cada domínio candidato.
owners registram condições, bloqueadores e ações.
decisão de readiness é aprovada por humano autorizado.
sistema prepara DomainActivationContract.
sponsor e papéis necessários aprovam o contrato.
sistema cria OrganizationalContextSnapshot imutável por versão.
ModuleActivation muda para estado permitido.
o domínio recebe um Context Package referenciando o snapshot.
One-Pages são disponibilizadas conforme papel.
audit events e eventos de integração são registrados.
mudanças futuras passam por Continuous Context Maintenance.

89. Fluxos alternativos

Ativação com condições

Readiness conditional
→ condições + owner + prazo
→ Human Review
→ contrato condicionado
→ ativação limitada
→ monitoramento
→ cumprir, prorrogar justificadamente, reduzir escopo ou suspender

Evidência insuficiente

Gap material
→ NEED_MORE_EVIDENCE
→ plano de coleta
→ nova revisão
→ ativar, reduzir escopo ou não ativar

Piloto assistido

valor potencial + baixa prontidão de autonomia
→ ASSISTED_PILOT_ONLY
→ escopo mínimo
→ controles e suporte
→ avaliação de outcome
→ learning

Mudança material após ativação

Context Change Event
→ impacto nos módulos
→ manutenção, condition, pause ou suspend
→ novo snapshot
→ atualização do contrato

90. Edge cases principais

organização sem documentos formais;
múltiplos fundadores oferecem versões conflitantes;
sponsor delega tudo e não participa;
usuário pertence a mais de uma empresa;
grupo possui entidades com políticas diferentes;
unidade opera com exceção não documentada;
BPO possui dados, mas a organização não controla o acesso;
organograma está desatualizado;
fonte crítica é uma planilha pessoal;
documentos são históricos e continuam sendo usados;
uso de IA é restrito para determinada categoria;
extração falha ou produz conteúdo incompatível;
source owner revoga acesso;
condição vence durante caso ativo;
módulo descobre conflito material na E0;
fusão ou aquisição muda o perímetro;
organização familiar confunde propriedade, gestão e parentesco;
não existe owner para uma decisão;
readiness é alto em várias dimensões, mas existe um bloqueador crítico;
usuário tenta ativar módulo por feature flag sem contrato;
contexto muda enquanto snapshot aguarda aprovação;
duas ativações usam versões diferentes do baseline;
organização solicita exclusão de dados presentes em histórico;
incidente exige suspensão imediata;
organização está sobrecarregada por outras transformações.

Cada caso deve possuir comportamento determinístico no PRD de implementação correspondente.

91. Safe-guards obrigatórios

Situação	Comportamento seguro
ausência de sponsor	impedir aprovação e ativação material
finalidade ausente	permitir apenas configuração mínima; impedir ingestão relevante
perímetro ambíguo	marcar gap e bloquear compartilhamento entre entidades
conflito material aberto	condicionar ou bloquear gate conforme impacto
fonte vencida	sinalizar stale e exigir revalidação quando material
falha de IA	manter output como não processado; oferecer revisão/manual
erro de upload	não criar assertion como se a fonte tivesse sido lida
tentativa cross-tenant	negar, registrar evento e acionar tratamento de segurança
acesso revogado	interromper novo uso e reavaliar derivados conforme política
condição expirada	impedir nova operação material e enviar para review
contrato expirado	bloquear processamento novo do domínio
mudança de finalidade	exigir amendment e nova autorização
ativação sem snapshot	bloquear no servidor
snapshot em aprovação alterado	invalidar aprovação anterior e exigir nova revisão
incidente material	permitir suspensão governada e fallback de segurança

92. Anti-features e proibições

Não implementar como requisito automático:

giant onboarding questionnaire;
score universal de maturidade;
ranking entre organizações;
perfil psicológico de colaboradores ou líderes;
emotion recognition;
vigilância de comunicações;
ingestão irrestrita de e-mails ou chats;
inferência de base legal por IA sem revisão;
aprovação automática de readiness;
ativação automática de módulo;
coleta preventiva sem finalidade;
edição retroativa de snapshot;
sincronização em tempo real com todos os sistemas;
digital twin completo;
Knowledge Graph sofisticado antes do fluxo funcional;
previsão determinística de sucesso da implantação;
customização profunda por setor no MVP;
exposição pública de prompts, pesos ou regras proprietárias.

93. Contrato de contexto entregue aos domínios

Cada domínio ativado deve receber um Context Package versionado contendo, conforme autorização:

tenant e organization scope;
snapshot id e versão;
purpose;
sponsor e domain owner;
vocabulário relevante;
assertions compartilháveis;
gaps e conflitos materiais;
fontes referenciáveis;
restrições de uso;
classificação de dados;
readiness decision;
condições;
vigência;
links para evidência;
contrato de ativação.

O pacote deve ser uma projeção autorizada do contexto, não uma cópia irrestrita de toda a E0.

94. Matriz de alimentação dos módulos

Domain Pack	Contexto mínimo recebido	Profundidade permanece no domínio
Sales	empresa, modelo de negócio, prioridades, capacidades e restrições	ofertas, ICP, leads, needs e Solution Fit
Compliance	entidades, ambiente regulatório, governança e riscos iniciais	requisitos, controles, incidents, CAPAs e assurance
Management	estratégia, fóruns, alçadas, priorities e decision owners	decisões, transformação, performance e Board
Operations	cadeia de valor, unidades, sistemas, capacidade e dependências	execução, qualidade, estabilidade e desvios
Financial & Fiscal	entidades, sistemas, owners, restrições e regimes declarados	indicadores, cenários, obrigações e exposures
People	estrutura, lideranças, papéis críticos e change capacity	liderança, competências, sucessão e work health governance
Customer & Value	segmentos, proposta de valor e canais	jornada, value realization e customer outcomes
Project & Portfolio	prioridades, capacidade, change load e governance	initiatives, portfolio, benefits e delivery
Reputation & Stakeholder	stakeholders, compromissos e contexto público inicial	cases, trust, legitimacy, response e repair

95. Retorno dos módulos para a E0

Domínios podem propor atualização quando descobrirem:

nova entidade ou unidade;
owner real diferente do cadastro;
mudança estratégica;
sistema fonte diferente;
conflito contextual;
novo stakeholder crítico;
restrição material;
mudança de capacidade;
novo compromisso;
mudança de prontidão;
informação vencida ou incorreta.

Fluxo obrigatório:

Domain Finding
→ Context Change Proposal
→ E0 Impact Review
→ Accept, Reject or Request Evidence
→ Update Context
→ New Snapshot when material

O domínio não possui permissão para alterar unilateralmente o baseline aprovado.

96. Eventos conceituais de integração

Evento	Origem	Consumidores possíveis
`ImplementationCaseCreated`	E0	Foundation, PMO, Audit
`PurposeAuthorized`	E0	Data/Privacy/AI, domains candidates
`OrganizationalPerimeterDefined`	E0	todos os domínios autorizados
`ContextAssertionReviewed`	E0/Core	domínios consumidores
`MaterialContextConflictRaised`	E0 ou domínio	Management, Compliance, domain owner
`ReadinessAssessmentCompleted`	E0	sponsor, PMO, domain owner
`DomainActivationApproved`	E0	Foundation, domain pack, Audit
`DomainActivationConditioned`	E0	domain pack, PMO, sponsor
`DomainActivationBlocked`	E0	sponsor, PMO, domain owner
`OrganizationalContextSnapshotPublished`	E0	módulos autorizados
`ContextChangeProposed`	qualquer domínio	E0 steward/reviewer
`ContextChangeMaterialized`	E0	módulos afetados
`ModuleActivationPaused`	E0/Foundation	domain pack, users, Audit
`ActivationContractExpired`	E0	domain pack, sponsor, PMO

Eventos são contratos conceituais. Implementação pode iniciar de forma in-process e simples.

97. Minimum Viable E0 Slice

A fatia mínima funcional da E0.CORE inclui:

criação de Implementation Case para tenant existente;
sponsor, finalidade e escopo;
entidades e unidades mínimas;
usuários, memberships e papéis necessários;
registro manual de fontes;
Context Assertions com classificação e temporalidade;
gaps e conflitos;
assessment de readiness por domínio;
condições e bloqueadores;
decisão humana de readiness;
Domain Activation Contract;
snapshot versionado;
Module Activation governada;
Context Package para ao menos Sales;
One-Page de contexto e readiness;
trilha de auditoria;
RLS e segregação verificáveis;
fluxo de mudança contextual e nova versão.

98. Fora da fatia mínima

Permanecem como expansão posterior, salvo necessidade comprovada de piloto ou segurança:

conectores em tempo real;
grafo organizacional avançado;
detecção automática ampla de contradições;
questionário totalmente adaptativo;
Context Debt analytics;
Change Load analytics preditivo;
benchmark de readiness;
self-service completo;
workflow jurídico automatizado;
políticas complexas configuráveis por setor;
inheritance engine sofisticada;
motores de regras distribuídos;
modelos preditivos;
aplicativos móveis nativos;
customizações profundas por cliente;
múltiplos planos comerciais.

99. Direção técnica conceitual

Baseline tecnológica vigente:

Next.js;
TypeScript;
Tailwind;
Supabase;
PostgreSQL;
OpenAI como direção de integração assistida, ainda sujeita a comprovação funcional.

Direções:

monólito modular antes de microsserviços;
RLS e tenant scoping no servidor;
entidades relacionais para ownership, estado e auditoria;
snapshots versionados;
jobs assíncronos para extração, quando necessário;
feature flags separadas de Module Activation;
eventos de domínio simples e versionados;
observabilidade básica;
contratos claros entre Foundation, E0 e Domain Packs;
testes de autorização antes de pilotos externos.

100. Modelo de dados conceitual mínimo

erDiagram
    ORGANIZATION ||--o{ ORGANIZATION_UNIT : contains
    ORGANIZATION ||--o{ ORGANIZATION_CONTEXT : has
    ORGANIZATION_CONTEXT ||--o{ IMPLEMENTATION_CASE : scopes
    ORGANIZATION_CONTEXT ||--o{ CONTEXT_ASSERTION : contains
    CONTEXT_ASSERTION ||--o{ ASSERTION_EVIDENCE : supported_by
    CONTEXT_ASSERTION ||--o{ CONTEXT_CONFLICT : may_have
    ORGANIZATION_CONTEXT ||--o{ CONTEXT_GAP : has
    IMPLEMENTATION_CASE ||--o{ READINESS_ASSESSMENT : evaluates
    READINESS_ASSESSMENT ||--o{ READINESS_DIMENSION_RESULT : contains
    READINESS_ASSESSMENT ||--o{ READINESS_CONDITION : creates
    IMPLEMENTATION_CASE ||--o{ DOMAIN_ACTIVATION_CONTRACT : proposes
    DOMAIN_ACTIVATION_CONTRACT ||--|| MODULE_ACTIVATION : governs
    ORGANIZATION_CONTEXT ||--o{ CONTEXT_SNAPSHOT : versions
    CONTEXT_SNAPSHOT ||--o{ DOMAIN_ACTIVATION_CONTRACT : anchors
    ORGANIZATION_CONTEXT ||--o{ CONTEXT_CHANGE_EVENT : receives

O diagrama é conceitual. Cardinalidades e nomes físicos dependem de ADR e revisão do schema existente.

101. Campos técnicos transversais

Entidades persistentes materiais devem considerar:

id;
tenant_id direto ou relação comprovadamente segura;
organization_id;
scope_type e scope_id quando aplicável;
status;
version;
created_at e created_by;
updated_at e updated_by;
valid_from e valid_to;
purpose_id ou referência equivalente;
data_classification;
source_id ou proveniência;
human_review_status;
superseded_by_id;
deleted_at apenas quando soft delete for compatível;
correlação de auditoria.

Não usar tenant_id apenas no front-end. A regra deve ser enforceable na persistência e nos serviços.

102. Serviços ou comandos conceituais

Comandos esperados:

CreateImplementationCase;
DefinePurposeAndScope;
RegisterOrganizationUnit;
AddContextSource;
CreateContextAssertion;
LinkAssertionEvidence;
RaiseContextGap;
RaiseContextConflict;
ReviewContextAssertion;
AssessDomainReadiness;
AddReadinessCondition;
SubmitSnapshotForReview;
ApproveContextSnapshot;
CreateDomainActivationContract;
ApproveDomainActivation;
PauseModuleActivation;
ProposeContextChange;
PublishNewContextSnapshot.

Queries esperadas:

contexto atual por escopo;
snapshot por versão;
assertions com fonte;
gaps e conflitos abertos;
readiness por domínio;
contratos e condições;
módulos ativos;
One-Pages por papel;
histórico de mudança;
audit trail autorizado.

Endpoints específicos serão definidos em PRDs técnicos e ADRs.

103. State machine do Implementation Case

DRAFT
→ AUTHORIZATION_REVIEW
→ CONTEXT_COLLECTION
→ CONTEXT_REVIEW
→ READINESS_ASSESSMENT
→ ACTIVATION_REVIEW
→ BASELINE_APPROVED
→ ACTIVE
→ MAINTENANCE
→ CLOSED

Estados alternativos:

ON_HOLD
BLOCKED
CANCELLED

Regras:

não avançar para coleta sem autorização compatível;
não avançar para activation review sem readiness;
não publicar baseline sem review;
BLOCKED exige motivo e owner;
retorno de estado preserva histórico;
cancelamento não apaga fontes e logs sujeitos à política.

104. Critérios de aceite funcionais

105. Critérios de aceite técnicos e de segurança

106. Cenários mínimos de teste ponta a ponta

Cenário A — organização simples

Criar tenant, definir contexto, avaliar Sales, aprovar snapshot e ativar E0.SALES.

Cenário B — ativação condicionada

Compliance possui fontes parciais; ativar apenas em modo assistido com condição e prazo.

Cenário C — conflito de governança

Organograma e entrevistas divergem; conflito permanece aberto e aparece na readiness.

Cenário D — múltiplas unidades

Regra corporativa é herdada; uma unidade possui override autorizado e temporal.

Cenário E — acesso externo

BPO acessa somente unidade, fonte e função autorizadas; não acessa outras áreas.

Cenário F — atualização material

Mudança de sponsor gera Context Change Event, revisão, novo snapshot e notificação aos módulos.

Cenário G — cross-tenant attack

Tentativas por URL, API, busca, exportação e job são negadas e auditadas.

Cenário H — falha de IA

Extração falha; usuário recebe estado claro e consegue continuar manualmente sem conclusão falsa.

107. Estratégia de validação

Fase 1 — dados sintéticos

Validar estados, permissões, versionamento, gaps, conflitos e ativação.

Fase 2 — laboratório interno LC Verum

Usar a LC Verum como caso interno, sem tratá-la como template universal ou evidência externa de PMF.

Fase 3 — replay assistido

Reprocessar contextos históricos de clientes com dados minimizados ou autorizados, distinguindo evidência histórica de verdade atual.

Fase 4 — piloto externo controlado

Testar uma organização, um escopo e um domínio inicial, após gates mínimos de segurança, privacidade e operação.

Fase 5 — cross-domain

Demonstrar que o mesmo snapshot contextual alimenta dois domínios sem duplicação ou mistura de ownership.

108. Evidências de conclusão da fatia mínima

A Minimum Viable E0 Slice estará funcionalmente demonstrada quando:

uma organização percorre E0.0–E0.9 em ambiente controlado;
contexto possui fontes, gaps, conflitos e temporalidade;
readiness é avaliada por domínio;
Human Review aprova snapshot e ativação;
ao menos Sales recebe Context Package válido;
alteração material gera nova versão;
usuários de tenants distintos permanecem segregados;
One-Pages refletem o mesmo baseline;
audit trail recupera a cadeia da decisão;
falhas principais possuem comportamento seguro;
o teste é repetível com dados sintéticos;
limitações conhecidas são documentadas.

Arquitetura, mockup ou Markdown isolados não atendem esse gate.

109. Métricas de produto e operação

Métricas candidatas, ainda sem metas aprovadas:

tempo até Authority & Purpose Gate;
tempo até primeiro snapshot;
quantidade de perguntas manuais necessárias;
proporção de assertions com fonte e owner;
gaps materiais por ativação;
conflitos abertos e tempo de tratamento;
itens stale;
ativações por decisão;
condições vencidas;
módulos pausados por mudança de contexto;
taxa de reutilização de contexto entre módulos;
retrabalho causado por contexto incorreto;
tempo de revisão humana;
falhas de acesso;
esforço assistido por implantação;
contexto descoberto pelo domínio e devolvido à E0;
percepção de clareza por sponsor e operator.

Nenhuma métrica deve ser apresentada como validada antes de uso real.

110. Riscos e controles

Risco	Controle principal
onboarding virar questionário gigante	progressive onboarding e suficiência por decisão
falsa sensação de completude	gaps, conflicts e validity visíveis
E0 absorver todos os módulos	thin shared baseline e ownership explícito
contexto envelhecer	temporalidade, review triggers e stale state
mistura entre tenants	RLS, server-side scoping e testes adversariais
excesso de dados	purpose, minimization e domain projection
IA inventar contexto	provenance, draft state e Human Review
score esconder bloqueador	estados por dimensão e bloqueador soberano
implantação burocrática	One-Page, automação assistida e foco no próximo gate
dependência das Founders	templates, stewards, operação assistida e learning
BPO exceder autoridade	membership externo, purpose e sponsor interno
snapshot divergente entre módulos	referência de versão e evento de substituição
ativação sem capacidade	Change Load + readiness + stop conditions
arquitetura virar produto fictício	evidência funcional antes de claim

111. Backlog priorizado

P0 — necessário para fluxo mínimo, segurança ou confiabilidade

tenant-scoped Implementation Case;
purpose e scope;
assertions, sources, gaps e conflicts;
readiness por domínio;
Human Review;
snapshot versionado;
Domain Activation Contract;
Module Activation;
RLS;
audit trail;
Context Package para Sales;
One-Pages mínimas;
error e empty states.

P1 — necessário para piloto real

external/BPO access control;
condition monitoring;
stale review;
context change workflow;
exportação controlada;
fila de revisão;
métricas de esforço;
protocolo de suporte e incidentes.

P2 — melhoria baseada em evidência

perguntas adaptativas;
extração assistida mais robusta;
detecção de contradição;
visualização de Change Load;
Context Debt portfolio;
templates por contexto organizacional;
integrações selecionadas.

Horizon

graph avançado;
self-service;
context analytics;
recomendações de atualização;
automação cross-domain ampliada;
data/learning effects, se comprovados.

112. Deliberações técnicas futuras

Itens que exigem ADR ou decisão técnica antes de implementação definitiva:

unidade canônica de tenancy e relação com Organization;
suporte a usuário multi-tenant;
modelagem de grupos e entidades relacionadas;
estratégia física de snapshots;
regras de inheritance e override;
engine de autorização além de RBAC;
versionamento de eventos;
política de retenção e erasure;
armazenamento e redaction de fontes;
provenance de IA;
fila de jobs e idempotência;
mecanismo de feature flag versus Module Activation;
política de cache por tenant;
formato do Context Package;
busca e indexação de conteúdo sensível;
limites de exportação;
observabilidade e alertas;
tratamento de shared ownership entre unidades.

Este documento define requisitos e invariantes; não antecipa decisões técnicas ainda abertas.

113. Sequência recomendada de implementação

Incremento 1 — secure bootstrap

tenant, membership e RLS;
Implementation Case;
purpose e scope;
audit básico.

Incremento 2 — context workspace

organization scope;
sources;
assertions;
gaps;
conflicts;
versionamento inicial.

Incremento 3 — readiness

assessment;
dimensions;
conditions;
Human Review;
readiness decision.

Incremento 4 — activation

Domain Activation Contract;
Module Activation;
Context Package;
E0.SALES como primeiro consumidor.

Incremento 5 — maintenance and experience

snapshots;
change events;
One-Pages;
review queue;
métricas e observabilidade.

Cada incremento deve fechar um fluxo verificável, não apenas criar tabelas.

114. Briefing para desenvolvimento

O desenvolvedor deve compreender:

E0.CORE não é formulário de cadastro;
Foundation owns tenancy e segurança; E0 owns contexto e ativação;
contexto possui fonte, escopo, tempo e classe epistemológica;
unknown, gap e conflict são estados válidos;
readiness é por domínio e pode bloquear ativação;
contrato de ativação e feature flag são coisas diferentes;
snapshot aprovado não é editável;
domínios consomem projeção versionada;
domínios propõem mudanças, mas não alteram baseline diretamente;
IA assiste; humanos aprovam decisões materiais;
RLS e autorização são requisitos de produto;
One-Pages são projeções da mesma fonte de verdade;
erro, vazio, loading, stale e restricted precisam de comportamento explícito;
documentação não comprova implementação.

115. Definition of Done por incremento

Um incremento da E0 só está concluído quando:

fluxo feliz funciona;
edge cases priorizados estão tratados;
permissões são verificadas no servidor;
migração e rollback foram avaliados;
testes automatizados relevantes passam;
estados de UI existem;
audit events foram verificados;
dados sensíveis não aparecem em logs indevidos;
documentação técnica está atualizada;
demo reproduzível foi registrada;
limitações estão declaradas;
owner aprovou o resultado;
nenhuma capacidade é comunicada além da evidência.

116. Qualidade do conhecimento

Checklist:

117. Certification, ESG e Innovation Readiness

A E0 registra sinais iniciais que podem orientar transversais:

Certification Readiness

certificações existentes;
certificações desejadas;
escopo pretendido;
patrocinador;
histórico de auditorias;
restrições e gaps iniciais.

ESG & Sustainability

temas materiais declarados;
stakeholders;
compromissos;
riscos e dados disponíveis;
fronteiras organizacionais.

Innovation & Experimentation

experimentos ativos;
capacidade de mudança;
sponsor;
hipóteses;
critérios de aprendizado;
change load.

A E0 apenas estrutura o contexto inicial. As camadas proprietárias aprofundam readiness, assurance ou experimentação.

118. Claims permitidos e proibidos

Permitidos após arquitetura aprovada

a E0.CORE foi definida como fundação transversal;
o modelo prevê contexto versionado, readiness modular e ativação governada;
Sales será o primeiro consumidor do Context Package;
a implementação está planejada por incrementos.

Permitidos somente após evidência funcional

E0 funciona ponta a ponta;
segregação foi validada;
snapshots são produzidos automaticamente;
IA extrai contexto com qualidade suficiente;
módulos reutilizam contexto sem duplicação;
onboarding reduz esforço.

Proibidos sem validação correspondente

E0 compreende qualquer empresa automaticamente;
readiness prevê sucesso da implantação;
o sistema garante conformidade ou certificação;
a IA conhece a verdade organizacional;
a plataforma elimina consultoria ou revisão humana;
contexto está sempre atualizado em tempo real.

119. Referências internas

Fontes utilizadas:

PRODUCT_PROMPT.md;
Orquestro Master Context;
Orquestro Strategy Advisor — Master Source;
Orquestro_v3_MVP_Modular_Consolidado_v0.5_2026-08-22.md;
Orquestro_v3_Arquitetura_Modular_Aprovada_2026-08-21.md;
Orquestro_Sales_Intelligence_Modulo_v0.2_2026-08-21.md;
especificações dos Domain Packs aprovados;
decisões das Founders de 22/08/2026;
deliberação aprovada sobre E0.CORE nesta sequência.

Em conflito, prevalecem a instrução explícita mais recente das Founders e as decisões formalmente aprovadas.

120. Glossário

Termo	Definição
E0.CORE	fundação transversal de contexto, readiness e ativação
E0.DOMAIN	extensão inicial especializada de um Domain Pack
Organization Context	contexto vivo e escopado da organização
Implementation Case	jornada de implantação em determinado escopo
Context Assertion	afirmação estruturada sobre a organização
Context Gap	conhecimento necessário ausente ou insuficiente
Context Conflict	informações incompatíveis que exigem tratamento
Official–Observed Delta	diferença entre desenho oficial, relato e prática evidenciada
Context Debt	carteira de decisões expostas a contexto deficiente
Change Load	carga de transformação concorrente
Readiness	condição contextual para ativação responsável
Domain Activation Contract	contrato operacional e informacional do domínio
Module Activation	estado técnico-operacional do módulo no escopo
Context Snapshot	fotografia versionada e aprovada do contexto
Context Package	projeção autorizada do snapshot para um domínio
Human Review	revisão humana registrada e proporcional ao risco
One-Page	síntese por papel com evidence on demand

121. Bloco de inicialização para outra IA

Você está trabalhando na E0.CORE do Orquestro v3.
 
BASELINE
- Use esta especificação v0.1.
- Use o Orquestro v3 MVP Modular Consolidado v0.5.
- Leia e aplique o PRODUCT_PROMPT.md antes de gerar ou revisar Markdown.
- A E0.CORE está arquitetada e aprovada como baseline, mas não deve ser tratada como software implementado.
 
DEFINIÇÃO
Organizational Context & Implementation Intelligence.
Identity, Context, Readiness & Activation.
 
TESE
Nenhum Domain Pack deve aconselhar uma organização que ainda não compreende suficientemente.
 
OBJETO CENTRAL
Organization Context.
 
OBJETOS PRINCIPAIS
- Implementation Case
- Context Assertion
- Context Gap
- Context Conflict
- Readiness Assessment
- Domain Activation Contract
- Module Activation
- Organizational Context Snapshot
- Context Change Event
 
JORNADA
E0.0 Authority, Purpose & Trust Boundary
→ E0.1 Organizational Perimeter
→ E0.2 Business, Strategy & Value Logic
→ E0.3 Governance & Decision System
→ E0.4 Operating Model & Capabilities
→ E0.5 Risk, Obligation & Stakeholder Context
→ E0.6 Data, Systems & Knowledge Readiness
→ E0.7 Change & Implementation Readiness
→ E0.8 Domain Activation
→ E0.9 Baseline Approval & Launch
→ Continuous Context Maintenance.
 
GATES
- Authority & Purpose Gate
- Context Integrity Gate
- Evidence Sufficiency Gate
- Implementation Readiness Gate
- Domain Activation Gate
 
REGRAS
- E0.CORE mantém contexto comum; E0.DOMAIN aprofunda.
- E0.SALES preserva Company & Offer Intelligence.
- unknown, gap e conflict são estados válidos.
- contexto possui fonte, escopo, tempo, classificação e owner.
- readiness é por módulo e não por score universal.
- um bloqueador crítico não pode ser escondido por média.
- IA não aprova finalidade, baseline, risco ou ativação.
- snapshot aprovado não é editado em place.
- Domain Pack não altera baseline silenciosamente.
- nenhuma informação cruza tenant sem autorização.
- Domain Activation Contract é diferente de feature flag.
- arquitetura não comprova software implementado.
 
EXPERIÊNCIA
Progressive Context Onboarding + One-Page First + Evidence on Demand.

122. Controle de versão

Versão	Data	Estado	Alteração
0.1	22/08/2026	baseline arquitetural aprovada	consolidação completa da E0.CORE transversal

Decisões consolidadas:

criação formal da E0.CORE;
separação entre E0.CORE e E0.DOMAIN;
preservação de E0.SALES como Company & Offer Intelligence;
Organization Context como objeto central;
jornada E0.0–E0.9;
cinco gates estruturantes;
readiness por módulo;
Domain Activation Contract obrigatório;
snapshots temporais e versionados;
Context Inheritance governada;
Official–Observed Delta;
Context Debt;
Change Load Map;
Progressive Context Onboarding;
One-Pages por papel;
feedback governado dos módulos;
aplicação do Product Markdown Rail;
safe-guards de segurança, privacidade, IA e Human Review.

123. Síntese final

A E0.CORE não existe para preencher um cadastro sobre a empresa. Existe para construir a compreensão mínima, legítima, temporal e rastreável que autoriza o Orquestro a começar a pensar com ela.

Princípio final:

Contexto antes de recomendação. Finalidade antes de dados. Prontidão antes de ativação. Evidência antes de claim. Humano antes da decisão material.

E0.SALES — Offer Intelligence & Commercial Readiness v0.2

Fonte incorporada integralmente: Orquestro_E0_SALES_Offer_Intelligence_Commercial_Readiness_v0.2_2026-08-22.md

Orquestro E0.SALES — Offer Intelligence & Commercial Readiness

Definição funcional: Offer Truth, Value Architecture, Commercial Configuration, Promise Integrity & Boundaries
Versão: 0.2
Data: 22/08/2026
Status: baseline arquitetural revisada e aprovada pelas Founders para especificação e desenvolvimento incremental
Classificação: extensão especializada E0.DOMAIN do Orquestro™
Substitui: Orquestro_E0_SALES_Offer_Intelligence_Commercial_Readiness_v0.1_2026-08-22.md
Fundação obrigatória: E0.CORE — Organizational Context & Implementation Intelligence v0.1
Dependências principais: E3 Responsible Solution Fit, E4 Decision & Communication, E5 Decision Conversation & Feedback Intelligence, E6 Decision Outcome, Handoff & Commercial Learning
Fonte metodológica aplicada: Product Markdown Rail

Aviso de maturidade: este documento define a arquitetura pretendida do E0.SALES v0.2. Não comprova implementação funcional, integração completa de IA, prontidão de produção, pricing validado, Product-Market Fit ou qualquer ganho de conversão, margem ou receita.

1. Finalidade do documento

Este documento atualiza o E0.SALES — Offer Intelligence & Commercial Readiness para incorporar os requisitos arquiteturais que emergiram da especificação aprofundada de E3, E4, E5 e E6.

O objetivo não é redesenhar o E0.SALES. A v0.1 permanece estruturalmente válida. A v0.2 fecha lacunas em quatro áreas:

configuração comercial governada;
arquitetura de valor USF1 + USF2 + USP;
fronteira de divulgação e proteção do know-how;
integração operacional do Offer Reality Loop com E6.

2. Decisão arquitetural consolidada

E0.SALES define não apenas o que a organização pode responsavelmente oferecer, mas também o espaço dentro do qual ela pode configurar, precificar, comunicar, negociar e comprometer essa oferta sem violar a verdade da Offer Version.

A v0.2 preserva os quatro mecanismos já aprovados:

Offer Passport;
Promise Integrity Chain;
Responsible Fit Assessment, executado em E3;
Offer Reality Loop.

E adiciona quatro extensões explícitas:

Organization & Offer Value Architecture;
Commercial Configuration Policy;
Knowledge Disclosure Boundary;
Value Reality Feedback Integration.

3. O que permanece inalterado da v0.1

Permanecem válidos:

separação E0.CORE × E0.SALES;
Offer e OfferVersion como fonte canônica da oferta;
Offer Passport como projeção governada;
Need before Solution;
Promise Integrity Chain;
Capability Evidence;
Customer Prerequisites;
Seller Constraints;
Anti-Fit;
Configuration Boundary;
Offer Readiness;
Commercial Capacity Signal;
Offer Drift;
Offer Reality Loop;
Human Review proporcional;
versionamento e temporalidade;
proteção de IP;
nenhuma alteração automática da oferta por IA ou learning;
E3 como etapa responsável por avaliar fit;
E4 como etapa responsável por estruturar e comunicar a decisão;
E5 como etapa responsável por feedback, fricções e negociação;
E6 como etapa responsável por outcome, handoff, valor e learning.

4. O que muda na v0.2

Tema	v0.1	v0.2
Pricing	status de preço/economics	política comercial consumível por E3–E5
Configuration	boundary de customização	Commercial Configuration Policy versionada
Valor	promises, claims e outcomes	Organization/Offer USF1 + USF2 + USP
Comunicação	claims autorizados	Relevant Value Stack como projeção contextual
IP	proteção geral de know-how	disclosure classification na fonte
Negociação	limites gerais	discount/payment/timeline/authority boundaries explícitos
Offer Passport	verdade da oferta	inclui value architecture e commercial status
E6 feedback	Offer Reality Observation	Value Reality Chain + attribution + Offer Change Proposal
Pricing maturity	preço como informação	defined ≠ authorized ≠ presented ≠ accepted ≠ paid

5. Tese central v0.2

Uma oferta comercialmente pronta não é apenas uma descrição de serviço. É uma verdade versionada que combina promessa, capacidade, evidência, valor, configuração autorizada, limites de comunicação, limites de negociação e condições reais de entrega.

E0.SALES deve permitir responder:

o que vendemos;
para qual necessidade a oferta pode ser relevante;
o que podemos prometer;
o que sustenta essa promessa;
que valor tangível e intangível podemos defender;
qual diferenciação podemos declarar responsavelmente;
como a oferta pode ser configurada;
quanto pode custar dentro da autoridade vigente;
quem pode autorizar exceções;
o que pode ser mostrado na proposta;
o que pode ser explicado verbalmente;
o que deve permanecer protegido;
quando a oferta não deve ser vendida;
o que aprendemos depois de vender e entregar.

6. Posição na jornada Sales Intelligence

flowchart LR
    CORE["E0.CORE\nOrganizational Context"] --> E0S["E0.SALES\nOffer Intelligence"]
    E0S --> E1["E1\nLead Intelligence"]
    E1 --> E2["E2\nHuman Discovery"]
    E2 --> E3["E3\nResponsible Solution Fit"]
    E0S --> E3
    E3 --> E4["E4\nDecision & Communication"]
    E4 --> E5["E5\nDecision Conversation"]
    E5 --> E6["E6\nOutcome & Learning"]
    E6 --> E0S

E0.SALES prepara a verdade da oferta. Não seleciona solução em E1 ou E2.

7. Fronteiras de responsabilidade

E0.CORE

Conhece a organização, tenant, identidade, governança, contexto, readiness transversal e restrições gerais.

E0.SALES

Conhece a oferta, sua versão, valor, promessa, claims, capacidade, evidência, configuração, economics status, boundaries e readiness comercial.

E3

Seleciona ou rejeita uma configuração específica para uma necessidade isolada.

E4

Transforma a configuração aprovada em proposta e apresentação, sem revelar know-how protegido.

E5

Trata feedback, fricções e negociação dentro dos limites autorizados.

E6

Registra o contratado, handoff, delivery, valor percebido/realizado e learning.

8. Invariante de fronteira

Offer readiness não autoriza solution selection. Need isolation não prova fit. Commercial Configuration Policy não cria proposta. Pricing autorizado não prova disposição de pagamento. E3 precisa das duas verdades: Customer Need Truth + Offer Truth.

PARTE I — ORGANIZATION & OFFER VALUE ARCHITECTURE

9. Finalidade da Value Architecture

A arquitetura de valor transforma características e formas de entrega em linguagem comercial governada sem permitir que E4 ou E5 inventem benefícios no calor da interação.

10. Organization Value Architecture

OrganizationValueArchitecture representa a verdade comercial transversal da organização vendedora.

Ela não substitui identidade institucional, posicionamento de marca ou OfferVersion.

É composta conceitualmente por:

Organization USF1;
Organization USF2;
Organization USP;
supporting evidence;
limitations;
validity;
owner;
Human Review status.

11. USF1 — Tangible Value

USF1 representa o que existe concretamente na oferta ou organização que produz utilidade comercial observável.

Pode incluir:

entregáveis;
ativos;
componentes;
capacidades;
relatórios;
acompanhamento;
diagnóstico;
indicadores;
estrutura;
horas;
plataforma;
serviço;
materiais;
instrumentos;
suporte.

Regra:

USF1 não é lista promocional. É uma representação governada de valor tangível sustentada pela Offer Truth.

12. USF2 — Intangible Delivery Value

USF2 representa o valor intangível produzido pela forma de entrega.

Pode descrever, quando sustentado:

integração;
proximidade;
segurança;
governança;
simplicidade;
personalização;
continuidade;
implementação assistida;
decisões baseadas em evidências;
redução de carga cognitiva;
estruturação do conhecimento;
experiência coordenada.

Regra crítica:

USF2 comunica o valor do HOW; não revela o HOW protegido.

13. USP — Unique Value Proposition

USP representa uma formulação sintética do benefício diferencial que a organização ou oferta pode responsavelmente defender.

A USP:

deve ser simples;
deve ser coerente com evidence;
deve declarar limitações quando materiais;
não pode usar superioridade absoluta sem evidência;
não pode transformar hipótese de posicionamento em fato;
não pode copiar claim de marketing não validado automaticamente.

14. Organization Value Architecture ≠ Offer Value Architecture

A organização pode possuir uma verdade de valor transversal, mas cada OfferVersion deve possuir sua própria expressão de valor.

Organization Value Architecture
        ↓ specializes
Offer Value Architecture
        ↓ contextualizes
Relevant Value Stack

15. Offer Value Architecture

OfferValueArchitecture é vinculada à OfferVersion.

Conteúdo conceitual:

Offer USF1;
Offer USF2;
Offer USP;
permitted benefits;
supporting claims;
supporting evidence;
limitations;
prohibited claims;
disclosure classification;
validity;
owner;
reviewer.

16. Benefício permitido

Um Permitted Benefit é um benefício que pode ser comunicado dentro das condições definidas.

Ele não significa outcome garantido.

Deve declarar, quando relevante:

condição;
público/contexto;
base de evidence;
nível de confiança;
limitation;
disclosure class.

17. Benefício proibido

Um benefício deve ser classificado como não utilizável quando:

não existe evidence suficiente;
depende de causalidade não demonstrada;
extrapola a capability;
viola compliance;
exige garantia de resultado;
está desatualizado;
pertence a OfferVersion diferente;
conflita com outcome recente.

18. Relevant Value Stack

RelevantValueStack é uma projeção contextual, não necessariamente uma entidade canônica.

É produzida a partir de:

Customer Need Truth
+
Decision Friction
+
Offer Value Architecture
+
Responsible Commercial Promise
=
Relevant Value Stack

O stack deve selecionar apenas valor relevante para aquela decisão.

19. Regra contra benefit dumping

O sistema não deve responder a uma objeção ou montar proposta despejando todos os benefícios disponíveis.

Deve priorizar:

relação com a necessidade isolada;
relação com a fricção atual;
evidência;
clareza;
limite de divulgação.

20. Exemplo conceitual de Relevant Value Stack

Decision Friction:
"Minha equipe não terá tempo."
 
Need:
sobrecarga e dependência
 
USF1 relevante:
acompanhamento estruturado
 
USF2 relevante:
implementação assistida
 
USP relevante:
organizar a operação sem transferir integralmente o peso da mudança ao time interno
 
Relevant Benefits:
↓ esforço
↓ retrabalho
↑ clareza

O exemplo é ilustrativo; não autoriza claim universal.

PARTE II — COMMERCIAL CONFIGURATION POLICY

21. Finalidade

CommercialConfigurationPolicy define o espaço comercial autorizado de uma OfferVersion.

Pergunta central:

Esta configuração comercial está dentro daquilo que esta OfferVersion autoriza?

22. Policy ≠ Case Configuration

E0.SALES define a política.

E3 seleciona uma configuração para o caso.

Commercial Configuration Policy
        ↓
E3 Case Commercial Configuration
        ↓
E4 Proposal Configuration
        ↓
E5 Negotiated Configuration
        ↓
E6 Contracted Configuration

23. Commercial Configuration Policy — campos conceituais

A política pode conter:

pricing_model;
base_price;
authorized_price_range;
package_or_tier;
effort_basis;
included_hours;
included_components;
optional_components;
implementation_fee;
recurring_fee;
payment_terms;
discount_boundary;
configuration_boundary;
validity_rules;
capacity_dependency;
partner_costs;
commercial_exceptions;
approval_authority;
pricing_status;
economics_status;
owner;
reviewed_at;
valid_from;
valid_to.

Campos não aplicáveis podem permanecer nulos.

24. Pricing Models mínimos

A fatia mínima deve suportar conceitualmente:

preço fixo;
pacote/tier;
hourly;
faixa autorizada;
fórmula simples governada;
recorrência;
implementação + recorrência;
human-reviewed pricing.

Não deve virar CPQ universal.

25. Pricing Truth

Distinguir obrigatoriamente:

PRICE DEFINED
≠
PRICE AUTHORIZED
≠
PRICE PRESENTED
≠
PRICE ACCEPTED
≠
PRICE PAID

26. PRICE DEFINED

A organização possui uma referência de preço para a OfferVersion.

Não prova autoridade de uso nem validação de mercado.

27. PRICE AUTHORIZED

O preço ou faixa foi autorizado para uso comercial dentro da policy vigente.

Não prova que o cliente aceitará.

28. PRICE PRESENTED

Preço efetivamente comunicado ao cliente em E4.

Deve permanecer ligado a:

OfferVersion;
Proposal Version;
Commercial Configuration;
data;
seller;
customer/account.

29. PRICE ACCEPTED

Preço aceito na decisão comercial.

Registrado em E6.

Não é sinônimo de preço pago.

30. PRICE PAID

Preço efetivamente pago conforme dados disponíveis e autorizados.

Pode depender de integração futura com Financial Intelligence ou sistema financeiro.

31. Pricing Status

Estados conceituais mínimos:

UNKNOWN;
DRAFT;
DEFINED;
AUTHORIZED;
REVIEW_REQUIRED;
SUSPENDED;
EXPIRED.

Nomenclaturas técnicas finais podem ser ajustadas por ADR sem mudar a semântica.

32. Economics Status

Economics deve permanecer separado de Pricing.

Estados conceituais candidatos:

UNKNOWN;
PARTIAL;
KNOWN;
REVIEW_REQUIRED.

Economics pode envolver:

custo;
margem;
esforço;
partner cost;
capacity cost;
implementation burden.

33. Authorized Price ≠ Validated Price

Regra estrutural:

Preço conhecido ou autorizado não pode ser apresentado como preço validado pelo mercado sem evidência de apresentação, aceitação, pagamento e contexto.

34. Discount Boundary

Deve definir, quando aplicável:

desconto máximo autorizado;
autoridade por nível;
necessidade de justificativa;
condições de uso;
validade;
impacto em componentes;
necessidade de Human Review.

35. Payment Boundary

Deve definir, quando aplicável:

formas de pagamento autorizadas;
parcelamento;
antecipação;
recorrência;
vencimento;
exceções;
autoridade para alteração.

36. Timeline Boundary

Deve definir:

prazo padrão;
janela aceitável;
dependências;
capacity constraints;
autoridade para compromissos excepcionais.

37. Component Boundary

Deve distinguir:

required components;
optional components;
conditional components;
prohibited combinations;
partner-dependent components;
experimental components.

38. Configuration Boundary

Preserva a regra da v0.1:

dentro do boundary → configurar;
fora do boundary → OfferChangeProposal ou Human Review;
nenhuma customização material altera silenciosamente a OfferVersion.

39. Approval Authority

A policy deve permitir mapear autoridade para:

preço;
desconto;
prazo;
pagamento;
escopo;
partner;
componente opcional;
exceção comercial.

A matriz final de autoridade é decisão de implementação/configuração por tenant.

40. Commercial Exceptions

Exceção deve registrar:

pedido;
razão;
objeto afetado;
impacto;
requester;
approver;
decisão;
validade;
evidence;
audit event.

41. Capacity Dependency

Uma configuração comercial pode ser autorizada em abstrato e indisponível naquele momento por capacity.

Portanto:

COMMERCIAL AUTHORIZATION
≠
CURRENT DELIVERY AVAILABILITY

42. Partner Costs

Quando aplicável, partner cost pode influenciar economics e boundary.

Deve respeitar acesso restrito e não ser exposto automaticamente ao seller ou cliente.

43. Case Commercial Configuration

E3 consome a policy e produz uma configuração específica para o caso.

Conteúdo conceitual:

OfferVersion;
selected components;
selected package;
price basis;
hours/effort basis;
implementation fee;
recurrence;
payment terms;
timeline basis;
applied discount;
conditions;
exceptions;
authority status;
capacity status;
validity.

A representação física final será decidida com E3/ADR.

44. Commercial Configuration Gate

Resultado mínimo:

WITHIN_AUTHORIZED_BOUNDARY;
REVIEW_REQUIRED;
OUTSIDE_AUTHORIZED_BOUNDARY;
INSUFFICIENT_INFORMATION.

45. REVIEW_REQUIRED

Exemplos:

desconto fora do seller boundary;
prazo excepcional;
payment term excepcional;
partner não aprovado;
preço em review;
economics desconhecido quando material;
capacity incerta;
customização material.

46. OUTSIDE_AUTHORIZED_BOUNDARY

Não pode avançar silenciosamente para proposta.

Deve gerar uma destas rotas:

E0.SALES Human Review;
OfferChangeProposal;
nova OfferVersion;
retorno E3;
rejeição da configuração.

PARTE III — KNOWLEDGE DISCLOSURE BOUNDARY

47. Finalidade

O E0.SALES deve classificar a sensibilidade comercial e intelectual da informação antes que E4 gere proposta ou apresentação.

48. Classes de divulgação

Classes aprovadas:

PROPOSAL_SAFE;
PRESENTATION_ONLY;
PROTECTED_KNOW_HOW.

Pode existir uma classe interna adicional de acesso restrito técnico/financeiro, sem alterar as três classes de comunicação externa.

49. PROPOSAL_SAFE

Pode constar em material enviado ao cliente.

Exemplos:

objetivo;
escopo macro;
componentes;
entregáveis;
prazo;
condições;
investimento;
responsabilidades;
exclusions;
claims autorizados.

50. PRESENTATION_ONLY

Pode ser utilizado para explicação humana, sem obrigação de constar integralmente no documento enviado.

Exemplos:

racional da recomendação;
nuances de contexto;
interpretação de evidências;
explicações de valor;
exemplos selecionados;
detalhes suficientes para decisão, sem transferir know-how operacional.

51. PROTECTED_KNOW_HOW

Não deve ser revelado externamente sem autorização explícita.

Pode incluir:

prompts;
pesos;
taxonomias sensíveis;
lógica proprietária;
sequência operacional replicável;
frameworks internos detalhados;
regras da Engine;
templates proprietários;
critérios internos sensíveis;
métodos cuja divulgação permita reprodução indevida.

52. Regra de IP

A proposta deve ser suficiente para decidir, não suficiente para copiar.

53. Disclosure Classification na fonte

A classificação deve existir o mais próximo possível da fonte canônica.

Pode ser aplicada a:

OfferComponent;
OfferClaim;
OfferCondition;
Value Architecture item;
Evidence reference;
narrative block;
capability detail;
commercial field.

A granularidade física será definida por implementação.

54. E4 não decide sensibilidade do zero

E4 deve herdar a classificação do E0.SALES e aplicar regras de composição.

Se não houver classificação suficiente para conteúdo material:

DISCLOSURE UNKNOWN
→ HUMAN REVIEW REQUIRED

55. USF2 e proteção do HOW

USF2 pode comunicar:

integração;
governança;
proximidade;
estruturação;
método baseado em evidências;
implementação assistida.

USF2 não deve revelar:

sequência proprietária;
critérios detalhados;
prompts;
regras internas;
playbooks replicáveis;
mecanismos protegidos.

PARTE IV — OFFER PASSPORT v0.2

56. Offer Passport continua projeção

A fonte canônica permanece em:

Offer;
OfferVersion;
objetos relacionados.

O Passport é One-Page First.

57. Conteúdo mínimo do Offer Passport v0.2

Offer identity;
OfferVersion;
what it is;
intended need;
intended outcome;
responsible generic promise;
USF1;
USF2;
USP;
capabilities;
evidence status;
customer prerequisites;
seller constraints;
anti-fit;
configuration boundary;
commercial configuration status;
pricing status;
capacity status;
disclosure status;
readiness;
validity;
owner;
review status.

58. Passport e informação financeira

O Passport não precisa mostrar valores sensíveis a todos os usuários.

Pode exibir, conforme autorização:

PRICING_AUTHORIZED;
faixa;
preço permitido;
ou apenas status.

Custos e margem permanecem restritos por need-to-know.

59. Passport e E3

E3 recebe um Offer Context Package suficiente para avaliar fit e configuração.

Não precisa receber:

margem detalhada;
custo detalhado;
know-how protegido;
evidence sem autorização;
informações além da finalidade.

PARTE V — OFFER READINESS v0.2

60. Offer Readiness ampliada

Uma OfferVersion pronta para matching deve possuir base suficiente em:

Offer Truth;
Intended Need;
Intended Outcome;
Promise Integrity;
Capability Sufficiency;
Evidence;
Customer Prerequisites;
Seller Constraints;
Anti-Fit;
Configuration Boundary;
Commercial Configuration Policy;
Pricing Authority;
Economics status proporcional;
Capacity;
Organization/Offer Value Architecture;
Disclosure Boundary;
Measurement Basis;
Ownership;
Human Review.

61. Readiness States

Permanecem conceitualmente:

VALIDATING;
READY_TO_MATCH;
READY_WITH_CONDITIONS;
CAPACITY_CONSTRAINED;
PAUSED;
RETIRED.

Outros estados da v0.1 permanecem conforme lifecycle aprovado.

62. Blockers de readiness v0.2

Blocker material inclui:

promise sem capability;
claim material sem evidence suficiente;
pricing obrigatório desconhecido;
ausência de authority quando necessária;
configuration boundary ausente em oferta altamente customizável;
anti-fit desconhecido quando risco material existe;
disclosure class desconhecida para know-how sensível;
capacity impossível;
prerequisite essencial não mapeado;
conflito material não resolvido.

63. READY_WITH_CONDITIONS

Exige:

condição explícita;
owner;
due date ou trigger;
impacto;
regra de uso;
critério de encerramento;
visibility para E3.

PARTE VI — ACCESS, PRIVACY & ECONOMICS

64. Princípio need-to-know

Informação comercial sensível deve ser disponibilizada somente na extensão necessária à decisão.

65. Camadas de acesso conceituais

Seller

Pode acessar, conforme tenant policy:

Offer Passport;
authorized price ou faixa necessária;
discount boundary aplicável;
components;
allowed claims;
negotiation boundaries relevantes.

Sales Leadership

Pode acessar:

pricing policy;
exceptions;
authority rules;
offer readiness;
commercial conflicts.

Finance / Authorized Economic Role

Pode acessar:

cost;
margin;
partner cost;
economics assumptions;
restricted pricing logic.

E3

Recebe apenas o necessário para classificar a configuração como autorizada ou não.

66. Field-level policy

A implementação deve permitir restrição por campo ou projeção segura quando dados de preço, custo e margem forem sensíveis.

A estratégia técnica final permanece decisão de arquitetura/ADR.

67. RLS

Todo acesso permanece tenant-scoped.

Nenhuma Offer, Value Architecture, Price Policy, Evidence, Margin ou Configuration de outro tenant pode ser inferida por:

UI;
API;
busca;
export;
background job;
IA;
erro;
cache.

68. Proveniência

Toda informação material deve preservar:

source;
owner;
tenant;
purpose;
observed_at;
valid_from;
valid_to;
recorded_at;
reviewed_at;
reviewer;
version;
correlation id quando aplicável.

PARTE VII — OFFER REALITY LOOP REFINADO

69. Nova cadeia

O Offer Reality Loop v0.2 passa a ser representado como:

OFFER TRUTH
      ↓
RESPONSIBLE PROMISE
      ↓
PRESENTED
      ↓
CONTRACTED
      ↓
DELIVERED
      ↓
PERCEIVED
      ↓
REALIZED
      ↓
ATTRIBUTION
      ↓
LEARNING
      ↓
OFFER CHANGE PROPOSAL
      ↓
HUMAN DECISION
      ↓
NEW OFFER VERSION

70. OFFER TRUTH

Verdade da OfferVersion no momento da avaliação.

71. RESPONSIBLE PROMISE

Promessa case-specific produzida em E3 dentro das boundaries da OfferVersion.

72. PRESENTED

O que foi efetivamente comunicado em E4.

73. CONTRACTED

O que foi efetivamente acordado e registrado no Contracted Promise Snapshot em E6.

74. DELIVERED

O que foi efetivamente executado/entregue.

75. PERCEIVED

Valor ou experiência declarada pelo cliente.

É Customer Statement, não prova de outcome.

76. REALIZED

Mudança observável sustentada por evidence.

Não implica causalidade automática.

77. ATTRIBUTION

Avaliação governada de quanto pode ser atribuído à solução.

Estados conceituais candidatos:

UNKNOWN;
PLAUSIBLE_CONTRIBUTION;
PARTIALLY_SUPPORTED;
SUPPORTED.

Não utilizar falsa precisão.

78. LEARNING

Learning permanece consequência de evidence, não de opinião isolada.

79. Offer Change Proposal

Outcome pode gerar proposta de mudança, nunca edição silenciosa.

OfferRealityObservation
→ Learning Candidate
→ OfferChangeProposal
→ Human Review
→ Decision
→ New OfferVersion

80. Historical integrity

OfferVersion usada em caso histórico permanece imutável e referenciável.

Uma nova versão nunca reescreve:

proposal histórica;
contracted promise;
price presented;
claim used;
fit assessment;
outcome.

81. Value Delivered ≠ Renewal Won

Regra estrutural:

Valor entregue e decisão de renovação são fenômenos distintos.

E0.SALES deve aprender com ambos sem colapsá-los.

82. WON ≠ Validated Offer

Uma venda ganha:

não prova fit universal;
não prova pricing ótimo;
não prova value realized;
não prova causalidade;
não prova PMF.

83. LOST ≠ Bad Offer

Uma venda perdida:

não prova oferta inadequada;
não prova preço errado;
não prova ausência de valor;
exige reason/evidence antes de learning.

PARTE VIII — INTEGRATION CONTRACTS

84. E0.SALES → E3

E3 deve receber:

OfferVersion;
Offer Passport;
Offer Value Architecture;
claims permitidos/proibidos;
capabilities;
evidence status;
prerequisites;
constraints;
anti-fit;
Commercial Configuration Policy;
pricing status;
capacity status;
disclosure rules necessárias;
readiness;
validity.

85. E3 → E0.SALES

E3 pode devolver:

fit gaps;
configuration exception request;
missing capability;
unsupported claim;
boundary conflict;
OfferChangeProposal candidate.

Não altera OfferVersion.

86. E0.SALES → E4

E4 recebe, via E3/Proposal Ready Package:

selected OfferVersion;
Responsible Commercial Promise;
case Commercial Configuration;
allowed claims;
prohibited claims;
relevant value items;
disclosure classifications;
conditions;
exclusions;
validity.

87. E0.SALES → E5

E5 consome:

relevant USF1;
relevant USF2;
relevant USP;
negotiation boundaries;
price authority;
discount boundary;
payment boundary;
timeline boundary;
protected claims;
disclosure limits.

88. E6 → E0.SALES

E6 devolve:

contracted configuration;
contracted promise snapshot reference;
delivery observations;
perceived value;
realized outcome;
attribution status;
drift observations;
customer-stated reasons;
learning candidates;
OfferChangeProposal candidates.

PARTE IX — CORE FLOWS

89. Fluxo feliz — estruturar oferta

E0.CORE Context Package
→ Offer Landscape
→ Offer
→ OfferVersion
→ Promise/Claim/Capability/Evidence
→ Value Architecture
→ Commercial Configuration Policy
→ Disclosure Classification
→ Readiness Review
→ Human Approval
→ Offer Passport
→ READY_TO_MATCH

90. Fluxo feliz — usar em E3

Customer Need Truth
+
Offer Passport
+
Commercial Configuration Policy
→ Candidate Assessment
→ Responsible Solution Fit
→ Case Commercial Configuration
→ Proposal Readiness

91. Fluxo — negociação dentro do boundary

Client requests change
→ E5 identifies request
→ compare with Policy
→ within authority
→ update Case Commercial Configuration
→ audit
→ E4 regenerate proposal version if needed

92. Fluxo — negociação fora do boundary

Client requests change
→ compare with Policy
→ outside authority/boundary
→ Human Review or OfferChangeProposal
→ approve / reject / create new OfferVersion
→ E3 reassessment when material

93. Fluxo — disclosure unknown

E4 wants to use content
→ disclosure class missing
→ block external use
→ Human Review
→ classify
→ audit
→ continue or remove

94. Fluxo — learning altera oferta

E6 Evidence
→ OfferRealityObservation
→ Learning Candidate
→ repeated evidence / review
→ OfferChangeProposal
→ Human Decision
→ New OfferVersion
→ old version preserved

PARTE X — EDGE CASES & SAFE-GUARDS

95. Empty State — sem pricing

Se pricing for material e não houver base:

mostrar PRICING UNKNOWN;
impedir proposta quando preço for necessário;
permitir estruturação da oferta sem falsa completude;
criar Gap com owner.

96. Empty State — sem USF/USP

Offer pode existir sem Value Architecture completa durante VALIDATING.

Não deve ser promovida a READY_TO_MATCH quando value communication for material e estiver ausente.

97. Empty State — sem disclosure classification

Conteúdo sensível não classificado não pode ser externalizado automaticamente.

98. Error State — IA indisponível

Operação manual permanece possível.

O sistema não deve:

perder dados;
aprovar automaticamente;
fingir processing concluído;
bloquear revisão humana essencial.

99. Error State — policy inconsistente

Se price range, discount boundary ou authority entrarem em conflito:

criar OfferConflict;
marcar REVIEW_REQUIRED;
impedir uso material até revisão;
preservar versões anteriores.

100. Policy expirada

Commercial Configuration expirada não deve ser reutilizada silenciosamente.

E3 deve receber status de invalidade.

101. OfferVersion superseded

Não usar em novo fit por padrão.

Permitir leitura histórica conforme acesso.

102. Customer asks for protected HOW

E4/E5 podem:

explicar valor;
explicar outcome pretendido;
esclarecer scope e conditions;
recusar educadamente transferência de know-how protegido;
registrar concern se material.

Não devem revelar conteúdo classificado como PROTECTED_KNOW_HOW.

103. Seller attempts unsupported benefit

Sistema deve:

bloquear uso como claim suportado;
mostrar evidence status;
sugerir claim permitido quando existir;
exigir Human Review para exceção;
registrar tentativa quando material.

104. Discount request without authority

Não aplicar.

Criar request/review com:

amount;
reason;
requester;
approver;
decision;
timestamp.

105. Price inside range but margin unknown

Se margin não for requisito material para aquela authority:

permitir conforme policy;
manter economics status visível.

Se for requisito material:

REVIEW_REQUIRED.

106. Capacity changes after proposal readiness

Se capacity material mudar:

invalidate readiness relevante;
notificar E3/E4;
exigir revisão antes de novo compromisso.

107. Offer Value Architecture contradita por outcome

Criar:

OfferRealityObservation;
conflict ou learning candidate;
review.

Não apagar automaticamente claim histórico.

108. Multi-tenant safety

Nenhuma inferência cruzada pode ocorrer mesmo quando Offers possuem nomes semelhantes.

PARTE XI — DATA, AUDIT & VERSIONING

109. Objetos canônicos adicionados/candidatos

A v0.2 adiciona conceitualmente:

OrganizationValueArchitecture;
OfferValueArchitecture;
CommercialConfigurationPolicy;
DisclosureClassification ou mecanismo equivalente.

110. Objetos reutilizados

Reutilizar:

Offer;
OfferVersion;
OfferComponent;
OfferPromise;
OfferClaim;
IntendedOutcome;
NeedPattern;
Capability;
CapabilityEvidenceLink;
CustomerPrerequisite;
SellerConstraint;
OfferCondition;
OfferExclusion;
AntiFitPattern;
OfferGap;
OfferConflict;
OfferReadinessAssessment;
OfferReadinessCondition;
CommercialCapacitySignal;
OfferRealityObservation;
OfferChangeProposal;
HumanReview;
Decision;
Outcome;
Learning;
AuditEvent;
Version.

111. Projeções / packages, não necessariamente entidades

Offer Passport;
Relevant Value Stack;
E3 Offer Context Package;
Case Commercial Configuration;
Proposal Ready Package;
Contracted Promise Snapshot.

112. Regras imutáveis

OfferVersion aprovada não é editada in place.
Commercial Configuration Policy utilizada em caso deve ser versionável/rastreável.
Price Presented não é reescrito quando Price Accepted muda.
Price Accepted não é reescrito quando Price Paid difere.
USF/USP histórico usado em proposta permanece rastreável.
Disclosure classification usada em artefato externo permanece auditável.
Contracted Promise não altera OfferVersion histórica.
Learning não altera OfferVersion automaticamente.
IA não aprova pricing, disclosure, offer readiness ou commercial exception.
Cross-tenant access é negado sempre.

113. Audit Event mínimo

Registrar:

tenant;
actor;
membership;
action;
object;
object version;
previous state;
new state;
reason;
timestamp;
source;
reviewer;
correlation id.

114. Temporalidade

Cada policy/value architecture material deve suportar:

valid_from;
valid_to;
recorded_at;
reviewed_at;
next_review_at;
superseded_by.

PARTE XII — AI & HUMAN REVIEW

115. O que a IA pode fazer

extrair preços e termos de documentos;
sugerir estrutura de Value Architecture;
identificar possível USF1/USF2/USP;
detectar conflicts;
sugerir disclosure classification;
mapear components;
comparar configuração com policy;
gerar Relevant Value Stack;
apontar drift;
criar learning candidate;
sugerir OfferChangeProposal.

116. O que a IA não pode fazer

autorizar preço;
conceder desconto;
aprovar exception;
classificar conteúdo sensível definitivamente sem revisão quando material;
declarar superioridade sem evidence;
promover hipótese a claim;
mudar OfferVersion;
alterar contracted truth;
inferir margem de outro tenant;
revelar know-how protegido;
transformar um case em regra universal.

117. Human Review obrigatório

Exigir revisão humana quando houver:

pricing novo/material;
exception;
desconto fora do boundary;
claim material novo;
USP de superioridade;
disclosure ambiguity material;
OfferChangeProposal;
economics material desconhecido;
capability conflict;
anti-fit contestado;
material drift.

PARTE XIII — MINIMUM VIABLE OFFER INTELLIGENCE SLICE v0.2

118. Objetivo da fatia mínima

Demonstrar que uma OfferVersion pode ser estruturada, governada, configurada e reutilizada em E3–E6 sem virar CPQ completo.

119. Incluído no MVP Slice

Offer + OfferVersion;
Promise/Claim/Capability/Evidence;
Anti-Fit;
Customer Prerequisites;
Seller Constraints;
Offer Value Architecture simples;
USF1/USF2/USP;
Commercial Configuration Policy simples;
pricing status;
authorized range ou base price quando aplicável;
discount boundary simples;
authority simples;
configuration boundary;
disclosure classification;
Offer Passport;
readiness;
E3 handoff;
E6 Offer Reality Observation;
versionamento;
audit;
RLS.

120. Fora da fatia mínima

CPQ completo;
optimization engine;
dynamic pricing ML;
complex bundle solver;
advanced margin simulation;
complex capacity planning;
automated contracting;
automatic discount approval;
universal product configurator;
predictive price recommendation;
autonomous offer mutation.

121. Perguntas que o MVP deve responder

Esta OfferVersion está pronta para matching?
Que valor podemos responsavelmente comunicar?
O que não podemos prometer?
Que configuração comercial é autorizada?
Esta configuração está dentro do boundary?
Quem precisa aprovar uma exceção?
O que pode ir para a proposta?
O que pode ser explicado apenas na apresentação?
O que é know-how protegido?
O que aprendemos depois do outcome?

PARTE XIV — CRITÉRIOS DE ACEITE

122. Critérios funcionais

123. Critérios de acesso e segurança

RLS impede acesso cross-tenant a pricing e Value Architecture.
Seller sem permissão não acessa cost/margin.
E3 consegue validar boundary sem exigir exposição de margem quando desnecessária.
Export respeita disclosure classification.
IA não recebe conteúdo além da finalidade autorizada.
Logs não persistem know-how protegido indevido.
Error state não revela existência de pricing de outro tenant.
Histórico de policy permanece recuperável.

124. Critérios de versionamento

Alterar Value Architecture aprovada exige nova versão ou mecanismo auditável equivalente.
Alterar Commercial Configuration Policy utilizada em casos preserva a política anterior.
Proposal histórica continua ligada à policy e OfferVersion usadas.
Contracted Promise Snapshot continua ligado à versão contratada.
OfferChangeProposal não altera passado.

125. Cenários mínimos de teste

A — preço fixo

OfferVersion com preço fixo autorizado; E3 seleciona e E4 apresenta.

B — faixa autorizada

OfferVersion com faixa; seller configura dentro da faixa.

C — desconto fora da autoridade

Sistema gera REVIEW_REQUIRED.

D — USF2 protegendo HOW

USF2 comunica implementação assistida sem expor método interno.

E — know-how protegido

Tentativa de inserir framework interno em proposta é bloqueada/revisada.

F — policy expirada

E3 não reutiliza configuração silenciosamente.

G — value claim contestado

Outcome cria OfferRealityObservation e review.

H — pricing status

Preço autorizado não é tratado como aceito.

I — E6 feedback

Contracted/Delivered/Perceived/Realized retornam ao Offer Reality Loop.

J — cross-tenant

Busca, API e IA não misturam offers/policies.

126. Evidência de conclusão da fatia

A fatia mínima estará demonstrada quando, com dados sintéticos ou autorizados:

OfferVersion é criada e aprovada;
Value Architecture é registrada;
Commercial Configuration Policy é registrada;
Offer Passport é produzido;
E3 recebe OfferVersion válida;
uma configuração dentro do boundary avança;
uma configuração fora do boundary é bloqueada/revisada;
E4 respeita disclosure classification;
E5 recebe negotiation boundary;
E6 devolve OfferRealityObservation;
nova OfferVersion preserva a anterior;
RLS/audit passam nos testes.

Documentação isolada não comprova implementação.

PARTE XV — MÉTRICAS CANDIDATAS

127. Métricas operacionais

Sem metas aprovadas:

tempo para estruturar OfferVersion;
percentual de Offers com Value Architecture;
percentual com Commercial Configuration Policy;
pricing status por OfferVersion;
exceptions por tipo;
discounts fora do boundary;
proposals bloqueadas por disclosure;
claims sem evidence;
Offer conflicts;
capacity constrained rate;
OfferChangeProposals por outcome;
drift promise→contract;
drift contract→delivery;
drift delivery→value;
esforço humano de manutenção.

128. Métricas de validação de mercado

Não confundir com desempenho funcional:

price presented;
price accepted;
price paid;
willingness-to-pay evidence;
configuration most accepted;
reasons declared for loss;
no-fit decisions;
repeated value statements;
repeated outcome evidence.

Nenhuma métrica isolada comprova PMF.

PARTE XVI — OPEN TECHNICAL DECISIONS

129. Decisões ainda abertas

As seguintes decisões não bloqueiam a baseline arquitetural, mas exigem ADR/PRD antes da implementação definitiva:

OrganizationValueArchitecture como entidade própria ou agregado versionado;
OfferValueArchitecture como entidade própria ou conjunto de objetos vinculados;
CommercialConfigurationPolicy como tabela própria ou documento versionado;
representação física de CaseCommercialConfiguration;
enums finais de Pricing Status e Economics Status;
matriz de approval authority por tenant;
field-level access para price/cost/margin;
granularidade da Disclosure Classification;
estratégia de redaction em export;
invalidation rules quando policy muda após Proposal Readiness;
idempotência de Offer Passport e policy snapshots;
optimistic locking para revisão concorrente;
event schemas;
materiality thresholds para Human Review.

130. Decisões não abertas

Não reabrir sem nova deliberação das Founders:

E0.SALES separado da E0.CORE;
Need before Solution;
OfferVersion como verdade versionada;
E3 avalia fit;
Commercial Configuration Policy pertence à Offer Truth;
USF1/USF2/USP pertencem à arquitetura de valor;
USF2 não revela HOW protegido;
proposta não deve revelar know-how protegido;
preço autorizado não equivale a preço validado;
E5 negocia dentro de boundaries;
E6 devolve outcome/learning;
learning não altera OfferVersion automaticamente.

PARTE XVII — INVARIANTES FINAIS

131. Invariantes

NEED BEFORE SOLUTION.

TRUTH BEFORE POSITIONING.

EVIDENCE BEFORE CLAIM.

CAPABILITY BEFORE PROMISE.

CONFIGURATION BEFORE COMMERCIAL COMMITMENT.

AUTHORIZED PRICE ≠ VALIDATED PRICE.

ORGANIZATION VALUE ≠ OFFER-SPECIFIC VALUE.

USF2 COMMUNICATES THE VALUE OF HOW; IT DOES NOT DISCLOSE PROTECTED HOW.

COMMUNICATION MAY SELECT VALUE; IT MAY NOT INVENT VALUE.

NEGOTIATION MAY CONFIGURE AN OFFER; IT MAY NOT SILENTLY REDEFINE IT.

SENSITIVE ECONOMICS ARE NEED-TO-KNOW.

OUTCOME MAY PROPOSE A NEW OFFER VERSION; IT MAY NOT REWRITE THE OLD ONE.

A PROPOSAL MUST BE SUFFICIENT TO DECIDE, NOT SUFFICIENT TO COPY.

ONE CASE PRODUCES A LEARNING CANDIDATE, NOT A UNIVERSAL RULE.

132. Resumo executivo para handoff

O E0.SALES v0.2 preserva a arquitetura da v0.1 e adiciona as capacidades mínimas necessárias para suportar E3–E6 sem virar CPQ completo.

A OfferVersion passa a carregar ou referenciar:

Offer Truth;
Promise/Claims;
Capability/Evidence;
Value Architecture;
Commercial Configuration Policy;
Configuration Boundary;
Pricing/Economics Status;
Negotiation Boundaries;
Disclosure Classification;
Readiness;
Reality Loop.

O objetivo do MVP não é otimizar preço, configurar produtos complexos ou automatizar negociação.

O objetivo é responder com governança:

O que podemos oferecer?
Que valor podemos defender?
Como podemos configurar?
O que está autorizado?
O que podemos comunicar?
O que precisa permanecer protegido?
O que aprendemos depois?

133. Próxima integração obrigatória

Após este retrofit:

E2 deve formalizar Customer Need Truth como projeção governada de NeedInstance + evidence + context;
E3 consome Customer Need Truth + Offer Passport + Commercial Configuration Policy;
E4 consome Proposal Ready Package e Disclosure Boundary;
E5 consome Relevant Value Stack e Negotiation Boundaries;
E6 devolve Contracted/Delivered/Perceived/Realized/Attribution/Learning;
a especificação consolidada do Orquestro deve avançar para v0.3.

Fim — Orquestro E0.SALES — Offer Intelligence & Commercial Readiness v0.2

E1 — Lead Intelligence — baseline integrada

Origem: seção E1 da v0.2 anterior, preservada porque ainda não existe standalone E1 próprio. A Parte I v0.3 prevalece em caso de conflito.

11. E1 — Lead, Account, Relationship & Trigger Intelligence

O nome oficial Lead Intelligence permanece. A descrição ampliada evita reduzir a etapa a enriquecimento cadastral.

11.1 Objetivo

Transformar informação prévia sobre empresa, pessoa, relacionamento, origem e momento em contexto, sinais, hipóteses e gaps para preparar a descoberta.

11.2 Entradas

baseline E0;
fonte e origem do lead;
relacionamento existente;
dados autorizados da conta e de seus atores;
informações públicas e internas;
histórico comercial;
interações anteriores;
proposta ou entrega histórica;
observações do seller;
possíveis triggers;
limitações de uso.

11.3 Temporalidade do conhecimento

Quando houver histórico, cada item relevante deve ser reavaliado como:

STILL VALID;
CHANGED;
RESOLVED;
UNKNOWN;
NEW.

Regra:

Historical Commercial Evidence ≠ Current Commercial Truth.

11.4 Saída principal

Lead Intelligence Brief com:

Account Snapshot;
Relationship Context;
Source & Origin;
Observable Signals;
ICP/Anti-ICP Signals;
Triggers;
Need Hypotheses;
Counter-Hypotheses;
Initial Decision Context;
Historical Evidence Status;
Knowledge Gaps;
Discovery Priorities;
Watch-outs.

11.5 Gate

O lead pode seguir para preparação quando:

fontes e origem são identificáveis;
fato, statement, observação e hipótese estão separados;
gaps relevantes estão visíveis;
existe motivo legítimo para uma conversa;
não foi selecionada solução prematuramente.

E1 prepara Discovery. Não diagnostica necessidade e não cria Commercial Opportunity.

E2 — Human Discovery & Customer Need Truth v0.2

Fonte incorporada integralmente: Orquestro_E2_Human_Discovery_Customer_Need_Truth_v0.2_2026-08-22.md

Orquestro E2 — Human Discovery & Customer Need Truth

Definição funcional: Human Discovery, Need Isolation & Governed Customer Need Truth
Versão: 0.2
Data: 22/08/2026
Status: baseline arquitetural aprovada pelas Founders para especificação e desenvolvimento incremental
Posição na jornada: E1 Lead Intelligence → E2 Human Discovery → Need Isolation Gate → Opportunity Gate → E3 Responsible Solution Fit
Depende de: E0.CORE, E0.SALES, E1 Lead Intelligence, Foundation/Core transversal
Próxima etapa: E3 — Responsible Solution Fit
Fonte metodológica aplicada: PRODUCT_PROMPT.md — Product Markdown Rail

Aviso de maturidade: este documento define a arquitetura pretendida do E2 v0.2. Não comprova que o fluxo ponta a ponta, os gates, a IA, o Customer Need Truth, a segregação, os relatórios ou os pilotos estejam implementados, validados ou prontos para produção.

Decisão de retrofit: E2.1, E2.2 e E2.3 são preservados. O retrofit formaliza Customer Need Truth como projeção governada e versionada do NeedInstance, sem criar uma segunda verdade canônica e sem transformar o Discovery em questionário rígido.

1. Finalidade do documento

Este documento especifica o retrofit do E2 — Human Discovery do Orquestro™.

Ele consolida:

preparação cognitiva antes da conversa;
Discovery humano com presença mínima do sistema;
estruturação pós-reunião;
Need Lifecycle;
Need Isolation Gate;
Opportunity Gate;
criação e versionamento do Customer Need Truth;
handoff governado para E3;
revalidação de verdade histórica;
tratamento de mudanças materiais;
rastreabilidade, permissões, auditoria e Human Review;
critérios de aceite do Minimum Viable E2 Slice.

Este é um documento de arquitetura e especificação modular. Funcionalidades técnicas menores devem gerar PRDs próprios conforme o Product Markdown Rail.

2. Decisão arquitetural aprovada

Decisão:

NeedInstance permanece como fonte canônica da necessidade. Customer Need Truth é uma projeção governada, versionada e rastreável da necessidade, das evidências, do contexto e do estado dos gates em determinado momento.

Simetria arquitetural:

OfferVersion
    ↓
Offer Passport
 
NeedInstance
    ↓
Customer Need Truth

Consequências:

não existe segundo lifecycle concorrente de necessidade;
Customer Need Truth pode existir como WORKING DRAFT durante exploração;
apenas snapshot elegível pode alimentar E3;
E3 deve fixar a versão do Customer Need Truth usada no fit;
mudanças materiais posteriores exigem revisão de fit;
histórico não é sobrescrito.

3. Truthmode e fronteira de evidência

Estruturado ou aprovado

E2.1 Meeting Preparation permanece;
E2.2 Human Discovery permanece human-first;
E2.3 Post-Meeting Intelligence permanece;
Need Lifecycle permanece SUSPECTED → EXPLORED → ISOLATED → CLIENT_VALIDATED ou REJECTED;
Need Isolation Gate permanece central;
Opportunity Gate permanece separado;
percepção não vira fato;
hipótese não vira diagnóstico;
não avançar continua sendo decisão legítima;
E3 só ocorre após necessidade suficientemente isolada e Opportunity Gate compatível.

Ainda não comprovado

qualidade do Customer Need Truth gerado no software;
redução de solution forcing;
melhoria de taxa de acerto de fit;
redução de retrabalho comercial;
ganho de conversão, velocidade ou receita;
qualidade da detecção de mudanças materiais;
utilidade percebida por sellers;
valor de mercado da arquitetura.

Regra de claim

É permitido afirmar que a arquitetura foi aprovada. Não é permitido afirmar que o E2 diagnostica corretamente empresas, identifica causas-raiz automaticamente ou melhora resultado comercial sem evidência correspondente.

4. Tese central

O objetivo do Discovery não é confirmar uma solução imaginada. É construir uma representação suficientemente verdadeira, limitada, rastreável e útil da necessidade para decidir se existe oportunidade e, somente depois, avaliar fit.

O E2 deve responder:

o que acontece hoje;
como sabemos;
qual impacto existe;
o que o cliente deseja que exista no lugar;
por que isso importa;
onde a necessidade começa e termina;
o que não deve ser confundido com a necessidade;
que restrições, recursos e contexto podem afetar eventual mudança;
quem participa da decisão;
o que ainda não sabemos;
quão atual é essa representação.

5. Problema que o retrofit resolve

Sem uma saída governada de E2, a organização pode manter informação suficiente para conversar, mas insuficiente para demonstrar qual verdade da necessidade sustentou determinada recomendação.

Riscos:

pedido de solução tratado como necessidade;
problema amplo demais;
problema estreito demais;
causa presumida sem evidência;
solução selecionada antes da necessidade;
gaps escondidos para avançar;
histórico tratado como verdade atual;
mudança de contexto sem revisão de fit;
Discovery transformado em questionário;
proposta baseada em síntese que ninguém consegue reconstruir;
necessidade atualizada depois sem saber qual versão E3 utilizou.

6. O que permanece inalterado

O retrofit não altera:

E2.1 Meeting Preparation;
E2.2 Human Discovery;
E2.3 Post-Meeting Intelligence;
princípio o Orquestro prepara a conversa; a pessoa conduz a conversa;
Discovery Question Map adaptativo;
classificação epistemológica;
Need Lifecycle;
Need Isolation Gate;
Opportunity Gate;
Human Review proporcional;
possibilidade legítima de DO NOT CREATE;
separação entre Need e Solution.

7. O que muda na v0.2

O retrofit adiciona ou formaliza:

Customer Need Truth como projeção governada;
Need Boundary;
What Is Not The Need;
Known Constraints / Resources;
Timing / Urgency;
Implementation Context;
Relevant Decision Unit;
Open Gaps e Evidence Limitations explícitos;
validade e última confirmação;
snapshot fixado para E3;
revalidação de verdade histórica;
distinção entre mudança editorial e mudança material;
sinalização de invalidation/review downstream;
One-Page específico de Customer Need Truth.

8. Posição na arquitetura

flowchart LR
    E0["E0.CORE / E0.SALES"] --> E1["E1 Lead Intelligence"]
    E1 --> E21["E2.1 Meeting Prep"]
    E21 --> E22["E2.2 Human Discovery"]
    E22 --> E23["E2.3 Post-Meeting Intelligence"]
    E23 --> NG{"Need Isolation Gate"}
    NG --> CNT["Customer Need Truth Snapshot"]
    CNT --> OG{"Opportunity Gate"}
    OG --> E3["E3 Responsible Solution Fit"]
    E0 --> E3

E2 constrói a verdade governada da necessidade. E0.SALES constrói a verdade governada da oferta. E3 avalia fit entre essas duas verdades.

9. Simetria Need Truth × Offer Truth

Verdade da necessidade	Verdade da oferta
`NeedInstance`	`OfferVersion`
`Customer Need Truth`	`Offer Passport`
Current Reality	Offer Definition
Evidence	Capability / Value Evidence
Impact	Intended Outcome
Desired Future	Responsible Promise
Boundary	Configuration Boundary
What Is Not The Need	Anti-Fit / Exclusions
Constraints / Context	Conditions / Prerequisites
Need Validity	Offer Validity

Regra:

Need isolation não prova fit. Offer readiness não prova fit. E3 precisa das duas verdades.

10. Arquitetura funcional E2.1–E2.3

E2.1 — MEETING PREPARATION
        ↓
E2.2 — HUMAN DISCOVERY
        ↓
E2.3 — POST-MEETING INTELLIGENCE
        ↓
NeedInstance + Evidence + Context + Gaps
        ↓
Customer Need Truth — Working Draft
        ↓
Need Isolation Gate
        ↓
Customer Need Truth Snapshot
        ↓
Opportunity Gate

O sistema prepara e estrutura. A conversa permanece humana.

11. E2.1 — Meeting Preparation: objetivo

Preparar cognitivamente quem conduzirá o Discovery sem transformar a reunião em entrevista mecânica, questionário de tela ou busca por confirmação de uma solução já escolhida.

12. E2.1 — inputs

Entradas possíveis:

Lead Intelligence Brief;
Account Snapshot;
Relationship Context;
Customer Statements disponíveis;
Seller Observations;
Need Hypotheses;
Counter-Hypotheses;
Critical Knowledge Gaps;
Decision Unit Unknowns;
Historical Need Truth, quando existir;
contexto E0.CORE permitido;
sinais de oferta apenas para awareness interno, nunca para direcionar solução prematuramente.

13. E2.1 — Meeting Prep Brief

Conteúdo recomendado:

Meeting Objective;
Relationship Context;
Account Snapshot;
What We Know;
Customer Statements;
Seller Observations;
Hypotheses to Test;
Counter-Hypotheses;
Critical Knowledge Gaps;
Conversation Priorities;
Discovery Question Map;
Current Need Candidates;
Boundary Questions;
What Might Not Be The Need;
Decision Unit Unknowns;
Historical Revalidation Questions, quando aplicável;
Watch-outs;
Leave Knowing;
Need Isolation Gate status.

One-Page First; evidência sob demanda.

14. Discovery Question Map

O mapa permanece adaptativo:

flowchart LR
    O["OPEN"] --> E["EVIDENCE"]
    E --> C["CONFIRM"]
    C --> I["IMPACT"]
    I --> F["FUTURE"]
    F --> P["PRIORITY"]
    P --> B["BOUNDARY"]
    B --> N["NOT THE NEED"]

Nem toda conversa exige todas as perguntas, nem na mesma ordem.

Princípio:

Perguntas abertas são padrão investigativo; confirmação serve para reduzir ambiguidade, não para induzir concordância.

15. Tipos de perguntas e finalidade

Tipo	Finalidade
Open	explorar realidade sem antecipar resposta
Evidence	buscar fatos, exemplos, frequência, documentos, eventos ou fontes
Confirm	verificar entendimento do seller
Impact	compreender consequência
Future	compreender estado desejado
Priority	compreender relevância e timing
Boundary	delimitar onde o problema aparece e onde não aparece
Not-the-Need	testar explicações ou pedidos que podem não representar a necessidade
Constraint	compreender limites, recursos e dependências
Decision Unit	compreender quem participa da decisão e implementação

O sistema pode sugerir perguntas; a pessoa decide como e quando utilizá-las.

16. E2.2 — Human Discovery: objetivo

Conduzir uma conversa humana capaz de compreender realidade atual, evidência, impacto, futuro desejado, prioridade, boundaries, contexto e sistema decisório, preservando autonomia, escuta e confiança.

17. Prioridades do Human Discovery

Priorizar:

conexão;
escuta;
contexto;
perguntas abertas;
exemplos concretos;
aprofundamento;
silêncio;
observação;
confirmação ética;
autonomia;
contraditório;
possibilidade de rejeitar hipóteses;
possibilidade de concluir que não existe oportunidade.

18. Uso do sistema durante a reunião

O uso deve ser mínimo e opcional.

O sistema pode apoiar:

consulta pontual ao Meeting Prep;
notas leves;
marcação de itens a revisar depois.

O sistema não deve:

conduzir a conversa;
exigir preenchimento de formulário enquanto o cliente fala;
diagnosticar em tempo real como verdade;
sugerir solução antes da necessidade;
gerar pressão para avançar;
competir com o cliente pela atenção;
inferir estado psicológico;
gravar ou transcrever sem base e autorização adequadas.

19. Discovery human-first invariant

O Orquestro prepara antes e estrutura depois. A pessoa cria conexão, escuta, pergunta, observa e decide durante a conversa.

Qualquer experiência que torne a tela protagonista deve ser considerada regressão de UX, salvo caso de uso específico aprovado.

20. Need candidates durante a conversa

Durante Discovery podem existir múltiplos Need Candidates.

Regras:

candidate não é Need isolada;
candidate pode ser rejeitada;
candidate pode se desdobrar em mais de uma NeedInstance;
duas necessidades distintas não devem ser fundidas apenas para simplificar;
sintomas não devem ser automaticamente promovidos a necessidade central;
pedidos de solução permanecem Customer Request até investigação.

21. Customer Request ≠ Customer Need

Exemplo:

Customer Request:
"Precisamos mapear processos."
 
Possible Need Hypothesis:
reduzir dependência de conhecimento tácito e aumentar previsibilidade operacional

Regra:

Pedido de solução é evidência sobre intenção e linguagem do cliente; não é prova da necessidade subjacente.

22. E2.3 — Post-Meeting Intelligence: objetivo

Transformar notas, debrief, transcrição autorizada e evidências adicionais em conhecimento comercial estruturado sem apagar origem, divergência, tempo ou incerteza.

23. Fluxo de Post-Meeting Intelligence

flowchart TB
    S["Notes / Debrief / Sources"] --> E["Evidence Items"]
    E --> K["Knowledge Items"]
    K --> N["NeedInstance"]
    N --> C["Current Reality / Impact / Future / Priority"]
    C --> B["Boundary / Not the Need / Constraints / Gaps"]
    B --> W["Customer Need Truth — Working Draft"]
    W --> G{"Need Isolation Gate"}

A Engine pode estruturar e sugerir. Revisão humana é proporcional ao risco e materialidade.

24. Debrief humano

O debrief pode registrar:

Customer Statements;
Facts;
Seller Observations;
Engine Hypotheses;
Counter-Hypotheses;
Evidence Items;
Knowledge Items;
contradictions;
Gaps;
Need Candidates;
Decision Unit signals;
Communication signals;
implementation context;
seller uncertainties;
follow-up evidence requests.

O debrief não deve obrigar o usuário a “fechar diagnóstico”.

25. Classificação epistemológica

Classe	Uso
FACT	informação sustentada por fonte adequada
CUSTOMER STATEMENT	declaração atribuída ao cliente
SELLER OBSERVATION	percepção contextual do seller
ENGINE HYPOTHESIS	interpretação sujeita a teste
COUNTER-HYPOTHESIS	alternativa explicativa
GAP	conhecimento ausente ou insuficiente
EVIDENCE	fonte ou item que suporta análise
DECISION	decisão humana ou de gate registrada

Regras:

observação não vira fato;
hipótese não vira diagnóstico;
ausência de dado não é preenchida;
linguagem segura não aumenta a força da evidência;
IA não promove classe epistemológica material sem regra e revisão.

26. NeedInstance — papel canônico

NeedInstance é a entidade canônica que representa uma necessidade em determinado caso comercial.

Deve possuir ou referenciar:

tenant;
account/case;
lifecycle state;
owner;
temporalidade;
fontes relevantes;
relações com Knowledge Items;
gate decisions;
snapshots/projeções utilizados downstream.

Customer Need Truth não substitui o NeedInstance.

27. Need Lifecycle

Lifecycle preservado:

SUSPECTED
   ↓
EXPLORED
   ↓
ISOLATED
   ↓
CLIENT_VALIDATED
 
ou
 
REJECTED

Definições:

SUSPECTED: hipótese de necessidade;
EXPLORED: investigada, ainda insuficiente;
ISOLATED: estrutura mínima do Need Isolation Gate satisfeita;
CLIENT_VALIDATED: cliente reconheceu a síntese como adequada;
REJECTED: hipótese rejeitada, resolvida ou irrelevante.

28. Need Isolation Gate — estrutura mínima

Uma NeedInstance chega a ISOLATED apenas quando houver base suficiente para:

Current Reality — o que acontece hoje;
Evidence — como sabemos;
Impact — qual consequência produz;
Desired Future — o que deveria existir no lugar;
Priority / Relevance — por que importa.

Para CLIENT_VALIDATED, exige-se adicionalmente:

Client Recognition — o cliente reconheceu a síntese como representação adequada de sua realidade.

29. Need Isolation Gate — resultados

Resultados conceituais:

ISOLATED;
MORE_EVIDENCE_REQUIRED;
REJECTED;
OUT_OF_SCOPE;
HUMAN_REVIEW_REQUIRED.

Os resultados de gate não substituem o lifecycle canônico. Implementação física dos enums pode ser refinada em ADR.

30. Regras do Need Isolation Gate

seller urgency não substitui customer priority;
customer recognition não prova Solution Fit;
quantidade de evidência não substitui qualidade;
uma única declaração pode ser suficiente para um fato simples, mas não para causalidade complexa;
gaps materiais permanecem visíveis;
Need pode ser isolada com gaps não materiais;
conflito material exige review ou mais evidência;
ISOLATED não autoriza proposta;
gate deve registrar reason, evidence basis, actor e timestamp.

31. Opportunity Gate — separação obrigatória

Depois de Need Isolation existe decisão independente sobre oportunidade:

Decisão	Uso
`CREATE`	existe base suficiente para criar/continuar Commercial Opportunity
`NEED_MORE_EVIDENCE`	necessidade relevante, mas contexto comercial ainda insuficiente
`DO_NOT_CREATE`	não existe oportunidade comercial legítima naquele momento

Princípio:

Uma Need pode ser verdadeira sem existir Opportunity.

32. Customer Need Truth — definição

Definição:

Representação governada, temporal, versionada e rastreável da melhor verdade comercial disponível sobre uma NeedInstance, incluindo seus limites, evidências, gaps e estado de reconhecimento.

Truth significa verdade comercial baseada nas evidências disponíveis naquele momento.

Não significa:

verdade absoluta;
diagnóstico clínico ou organizacional definitivo;
causalidade comprovada;
autorização para solução;
opinião da IA apresentada como fato.

33. Customer Need Truth — natureza arquitetural

Recomendação:

tratar como projeção governada ou materialized snapshot;
NeedInstance permanece canônico;
snapshot é imutável após fixação downstream;
nova verdade gera nova versão/snapshot;
implementação física como tabela, view ou objeto composto permanece ADR técnico.

34. Campos do Customer Need Truth

Campos conceituais:

Need;
Current Reality;
Evidence;
Impact;
Desired Future;
Priority / Relevance;
Need Boundary;
What Is Not The Need;
Customer Recognition;
Known Constraints / Resources;
Timing / Urgency;
Implementation Context;
Relevant Decision Unit;
Open Gaps;
Evidence Limitations;
Need Lifecycle State;
Need Isolation Gate Decision;
Opportunity Gate Decision, quando disponível;
snapshot/version;
last confirmed at;
validity;
source links;
Human Review status.

35. Need

O campo Need deve sintetizar a necessidade sem prescrever solução.

Preferir linguagem orientada ao estado que precisa mudar.

Evitar:

“precisa comprar X”;
“precisa implementar nosso método”;
“precisa de consultoria”;
linguagem diagnóstica sem evidência;
causa-raiz presumida.

Exemplo:

“Reduzir dependência decisória em atividades operacionais específicas e aumentar clareza de responsabilidade.”

36. Current Reality

Descreve o estado atual relevante.

Deve:

usar linguagem observável;
preservar contexto e tempo;
evitar julgamento de valor desnecessário;
distinguir recorrência de episódio isolado;
apontar divergências quando existirem.

37. Evidence

Evidence deve retornar às fontes.

Pode incluir:

Customer Statements;
documentos;
dados;
exemplos concretos;
eventos;
registros de processo;
evidência histórica marcada como histórica;
fontes externas autorizadas.

Regra:

Nenhuma afirmação material do Customer Need Truth deve parecer mais forte que a evidência que a sustenta.

38. Impact

Impact descreve a consequência conhecida ou plausível.

Separar:

impacto declarado pelo cliente;
impacto observado;
impacto medido;
impacto hipotético.

Não converter associação em causalidade.

39. Desired Future

Representa o estado desejado pelo cliente, quando conhecido.

Não deve ser preenchido automaticamente com a proposta do seller.

Pode ser:

explícito;
parcialmente explícito;
ainda desconhecido.

Se desconhecido e material, permanece gap.

40. Priority / Relevance

Registra por que a necessidade importa e seu nível de relevância contextual.

Não assumir urgência a partir de entusiasmo, dor percebida pelo seller ou tamanho do problema.

Possíveis evidências:

prioridade declarada;
prazo externo;
consequência recorrente;
decisão de liderança;
evento futuro;
compromisso interno.

41. Need Boundary

Need Boundary define onde a necessidade começa e termina.

Deve ajudar a responder:

quais unidades, processos, pessoas ou situações estão dentro;
quais estão fora;
quais dependências pertencem ao problema;
quais são adjacentes, mas não parte da Need atual.

Benefício:

reduzir expansão de escopo e solution forcing.

42. What Is Not The Need

Campo obrigatório quando houver risco relevante de confundir pedido, sintoma, causa presumida ou solução com a necessidade.

Exemplo:

Customer Request:
"Precisamos mapear processos."
 
What Is Not The Need:
Não há evidência de que ausência de fluxogramas, isoladamente,
seja o problema central.

Princípio:

Definir o que não é a necessidade protege a integridade do fit.

43. Customer Recognition

Registra se e como o cliente reconheceu a síntese.

Estados conceituais candidatos:

CONFIRMED;
PARTIALLY_CONFIRMED;
NOT_CONFIRMED;
CONTRADICTED;
NOT_REQUESTED.

Os enums finais permanecem ADR.

Regra:

Client Recognition fortalece a verdade da Need; não prova Solution Fit, budget, authority ou willingness to buy.

44. Known Constraints / Resources

Registra condições conhecidas que podem afetar eventual solução ou mudança:

disponibilidade de pessoas;
orçamento conhecido;
capacidade operacional;
tecnologia;
regulamentação;
dependências internas;
parceiros;
restrições contratuais;
recursos já existentes.

Não transformar constraint presumida em fato.

45. Timing / Urgency

Registra janela, prazo, evento ou urgência relevante.

Distinguir:

timing declarado;
deadline objetivo;
seller urgency;
hipótese de urgência.

Urgência artificial é proibida.

46. Implementation Context

Registra aspectos do contexto que podem afetar uma eventual implementação:

change load;
iniciativas paralelas;
disponibilidade;
maturidade processual observável;
dependências de sistema;
sponsor;
riscos materiais.

Não transforma E2 em diagnóstico completo de implementação; usa sinais suficientes para preservar contexto.

47. Relevant Decision Unit

Customer Need Truth pode referenciar atores relevantes para:

reconhecer a necessidade;
aprovar decisão;
disponibilizar recursos;
implementar;
bloquear;
influenciar.

Decision Unit é contextual e versionável. Não é organograma fixo nem perfil psicológico.

48. Open Gaps

Gaps permanecem visíveis mesmo após isolamento.

Classificar, quando útil:

material para Need;
material para Opportunity;
material para Fit;
não material no momento.

Regra:

Isolated não significa known everything.

49. Evidence Limitations

Registrar limitações como:

amostra pequena;
fonte única;
evidência antiga;
declaração indireta;
conflito entre fontes;
ausência de métrica;
inferência não confirmada;
contexto parcial.

Limitação não deve desaparecer do One-Page apenas para aumentar confiança aparente.

50. Working Draft

Durante SUSPECTED ou EXPLORED, o sistema pode exibir:

Customer Need Truth — Working Draft

Regras:

claramente rotulado;
gaps visíveis;
não elegível para E3;
não usado para gerar proposta;
pode ser revisado livremente enquanto draft;
alterações materiais ficam registradas conforme necessidade de auditoria.

51. Snapshot elegível para E3

Condição mínima:

NeedInstance = ISOLATED ou CLIENT_VALIDATED
        +
Need Isolation Gate compatível
        +
Opportunity Gate = CREATE
        ↓
Customer Need Truth Snapshot elegível para E3

Exceções precisam de decisão explícita futura; não criar bypass silencioso.

52. `CLIENT_VALIDATED` não é pré-requisito universal

Decisão preservada:

ISOLATED satisfaz estrutura mínima da Need;
CLIENT_VALIDATED adiciona reconhecimento explícito do cliente;
E3 pode iniciar com Need ISOLATED quando Opportunity Gate = CREATE;
E3 deve saber se existe ou não reconhecimento explícito.

Isso evita bloquear artificialmente casos em que a necessidade está bem isolada, mas a síntese formal não foi recitada de volta ao cliente.

53. Customer Need Truth Snapshot

Conteúdo mínimo recomendado:

Customer Need Truth Snapshot
 
NeedInstance ID
Lifecycle State
 
Need
Current Reality
Evidence References
Impact
Desired Future
Priority / Relevance
 
Need Boundary
What Is Not The Need
 
Customer Recognition
Known Constraints / Resources
Timing / Urgency
Implementation Context
Relevant Decision Unit
 
Open Gaps
Evidence Limitations
 
Need Isolation Gate Decision
Opportunity Gate Decision
 
Created At
Last Confirmed At
Validity
Version
Source Links
Human Review

54. Versionamento

Regras:

cada snapshot possui version/id;
snapshot utilizado por E3 é imutável para aquele uso histórico;
nova evidência pode gerar novo snapshot;
nova versão referencia a anterior;
reason de mudança material deve ser registrado;
versões anteriores permanecem recuperáveis conforme retenção e acesso;
não sobrescrever a verdade usada por decisões passadas.

55. Temporalidade e validade

Campos ou relações temporais recomendadas:

observed_at;
recorded_at;
last_confirmed_at;
valid_from;
valid_to;
next_review_at, quando aplicável;
superseded_by.

Princípio:

Current Need Truth é temporal, não eterna.

56. Historical Need Truth ≠ Current Need Truth

Quando uma conta retorna após intervalo relevante:

Historical Customer Need Truth
        ↓
REVALIDATION
        ↓
STILL VALID
CHANGED
RESOLVED
UNKNOWN
NEW

A classificação pode ser por dimensão ou NeedInstance, conforme implementação futura.

Nenhum snapshot antigo deve ser promovido automaticamente a verdade atual.

57. Revalidation flow

flowchart TB
    H["Historical Need Truth"] --> Q["Revalidation Questions"]
    Q --> N["New Evidence"]
    N --> C{"Current status?"}
    C -->|Still valid| V["New confirmed snapshot"]
    C -->|Changed| U["Update NeedInstance / new snapshot"]
    C -->|Resolved| R["Resolved / close"]
    C -->|Unknown| G["Gap / more evidence"]
    C -->|New| NN["New NeedInstance"]

58. Material Truth Change

Mudança é material quando altera de forma relevante a interpretação ou elegibilidade do fit, por exemplo:

Current Reality;
Impact;
Desired Future;
Priority;
Need Boundary;
What Is Not The Need;
constraint relevante;
timing decisivo;
implementation context material;
Decision Unit material;
Customer Recognition quando afeta premissa crítica;
nova evidência que contradiz base anterior.

59. Editorial Change

Mudança editorial não altera substância da Need.

Exemplos:

correção gramatical;
normalização de termo;
melhoria de legibilidade;
tradução sem mudança semântica;
reorganização visual.

Regra:

Editorial change não invalida E3 por padrão.

Critério técnico de materialidade pode ser refinado em ADR, mas decisão humana deve prevalecer em dúvida material.

60. Downstream invalidation

Se Customer Need Truth muda materialmente após E3 iniciado:

Need Truth v3
   ↓
material change
   ↓
Need Truth v4
   ↓
NEED_TRUTH_CHANGED
   ↓
review current E3

Resultados possíveis:

fit permanece válido após review;
fit precisa ser recalculado/reexecutado;
mais evidência requerida;
Opportunity deve ser reavaliada;
proposta deve ser bloqueada/revisada.

61. Handoff E2 → E3

Pacote mínimo:

Customer Need Truth Snapshot;
NeedInstance reference;
lifecycle state;
Need Isolation Gate decision;
Opportunity Gate decision;
Customer Recognition state;
material gaps;
evidence limitations;
Decision Unit context permitido;
validity/timestamp.

E3 não recebe apenas um resumo textual solto.

62. Relação com E3 Responsible Solution Fit

E3 compara:

Customer Need Truth
        +
Offer Passport
        ↓
Responsible Solution Fit

E2 não:

escolhe oferta;
calcula fit;
amplia promise;
define preço;
gera proposta;
negocia.

63. Retorno E3 → E2

E3 pode devolver:

MORE_EVIDENCE_REQUIRED;
Need boundary question;
evidence gap;
contradiction;
missing implementation context;
missing Decision Unit information.

Retorno não significa que E3 pode alterar Need Truth diretamente. Nova verdade deve ser processada em E2.

64. Relação com E4–E6

E4–E6 podem revelar nova informação sobre a necessidade.

Exemplos:

cliente redefine problema durante apresentação;
nova pessoa contradiz Current Reality;
negociação revela constraint material;
outcome mostra que premissa estava incorreta;
renovação revela nova necessidade.

Regras:

mudança material retorna a E2;
histórico permanece ligado ao snapshot utilizado;
learning de E6 pode propor mudança de Need Pattern, não reescrever Need histórica.

65. Relação com E0.CORE

E2 pode consumir contexto organizacional autorizado como:

organização;
unidade;
estratégia relevante;
estrutura conhecida;
change load;
riscos materiais;
sistemas;
contexto de implementação.

E2 não recria E0.CORE e não transforma contexto institucional em Need automaticamente.

66. Relação com E0.SALES

E2 deve reduzir exposição a Offer Truth para evitar viés prematuro.

Permitido:

seller conhecer seu portfólio;
sistema usar anti-bias safeguards internos;
E2 saber que algumas hipóteses podem estar fora de escopo comercial.

Não permitido:

selecionar Offer em E2;
perguntar apenas para provar fit de oferta conhecida;
preencher Desired Future com promessa da oferta.

67. One-Page — Customer Need Truth

Experiência principal:

CUSTOMER NEED TRUTH
 
NEED
Qual necessidade estamos tentando resolver?
 
CURRENT REALITY
O que acontece hoje?
 
IMPACT
Por que isso importa?
 
DESIRED FUTURE
O que deveria existir?
 
PRIORITY
Por que isso importa agora?
 
BOUNDARY
Onde começa e termina?
 
NOT THE NEED
O que não devemos tentar resolver?
 
RECOGNITION
Cliente reconheceu?
 
CONSTRAINTS
O que pode afetar?
 
GAPS
O que ainda não sabemos?
 
STATUS
EXPLORED / ISOLATED / CLIENT_VALIDATED
 
EVIDENCE
View →

One-Page First + Evidence on Demand.

68. Discovery Snapshot × Customer Need Truth

Discovery Snapshot permanece visão mais ampla da conversa/caso.

Customer Need Truth é projeção focada na necessidade.

Discovery Snapshot pode conter:

múltiplas Need Candidates;
Decision Unit;
communication signals;
relationship context;
gaps gerais;
observations;
next discovery priorities.

Customer Need Truth não deve absorver todo o Discovery.

69. Múltiplas necessidades

Se a conversa identifica duas necessidades materialmente distintas:

criar/relacionar NeedInstances separadas;
evitar uma “mega-Need” apenas para simplificar;
cada Need pode ter gate e Opportunity diferentes;
E3 pode avaliar uma, várias ou nenhuma conforme Opportunity Gate.

Relações entre Needs podem ser registradas sem fundir canonical truth.

70. Need split

Se uma Need inicialmente ampla se divide:

preservar Need original como histórica/superseded conforme modelagem;
criar NeedInstances derivadas;
registrar reason;
mapear evidências compartilhadas;
reexecutar gates necessários;
impedir E3 de continuar com snapshot antigo sem review.

71. Need merge

Merge deve ser excepcional.

Permitido apenas quando evidência mostra que duas Needs eram duplicações sem distinção material.

Regras:

preservar histórico;
não apagar links de decisão;
registrar Human Review;
manter trace dos IDs anteriores;
rever downstream.

72. Need rejection

Uma hipótese pode ser REJECTED quando:

cliente a contradiz com evidência suficiente;
evidência mostra que não ocorre;
foi resolvida;
é irrelevante para o contexto atual;
era interpretação inadequada.

Rejected hypothesis é conhecimento útil e deve permanecer recuperável conforme retenção.

73. Out of scope

OUT_OF_SCOPE não significa “problema inexistente”.

Pode significar:

fora do propósito comercial da conversa;
fora da autoridade da organização vendedora;
requer especialista;
pertence a outro domínio;
não deve ser tratado naquele engagement.

Registrar motivo e, quando adequado, encaminhamento.

74. Contradições entre stakeholders

Se atores divergem:

preservar cada Customer Statement;
não escolher automaticamente “a versão verdadeira”;
marcar contradiction;
avaliar se a divergência é parte da própria Need;
buscar evidência adicional;
usar Human Review quando material.

Customer Need Truth pode declarar:

“Existem visões conflitantes sobre X.”

75. Ausência de Decision Maker

Discovery pode ser útil mesmo sem decisor final presente.

Regras:

registrar actor role;
não presumir autoridade;
Customer Recognition de um ator não equivale ao reconhecimento de toda Decision Unit;
se reconhecimento de outro ator for material, manter gap.

76. Evidência histórica

Historical evidence deve registrar período e contexto.

Pode fortalecer investigação, mas:

não substitui revalidação atual;
não promove Need para ISOLATED sozinha quando temporalidade é material;
deve ser distinguida de current evidence.

77. Evidence sufficiency

O sistema pode auxiliar avaliação de suficiência, mas não deve usar score universal rígido sem validação.

Critérios qualitativos possíveis:

relevância;
atualidade;
proximidade da fonte;
consistência;
diversidade;
verificabilidade;
materialidade.

Decision final material permanece humana conforme policy.

78. Confidence

Se houver confidence, deve ser:

explicável;
contextual;
não confundida com probabilidade objetiva;
derivada de evidence basis conhecida;
nunca usada para esconder gaps.

No MVP, confidence textual/qualitativa pode ser suficiente.

79. Human Review — quando obrigatório

Human Review deve ser obrigatório ou fortemente recomendado quando houver:

contradiction material;
Need com impacto sensível;
causalidade relevante não comprovada;
mudança material após E3;
merge/split;
uso de evidência sensível;
decisão de OUT_OF_SCOPE com risco relevante;
IA sugerindo promoção de lifecycle;
cliente contradiz síntese utilizada downstream.

80. Human Review Record

Registrar:

reviewer;
role/membership;
objeto;
versão;
decisão;
reason;
evidence basis;
timestamp;
conditions;
next review, quando aplicável.

Aprovação de uma versão não aprova versões futuras.

81. IA — usos permitidos

IA pode:

organizar notas;
extrair Customer Statements;
sugerir Evidence links;
agrupar Need Candidates;
propor hipótese e counter-hypothesis;
sugerir perguntas abertas;
sintetizar Customer Need Truth draft;
detectar gaps;
detectar possíveis contradições;
comparar snapshots;
sugerir se mudança parece editorial ou material;
preparar Human Review;
gerar One-Page a partir de fonte governada.

82. IA — usos proibidos

IA não pode:

transformar observação em fato;
declarar diagnóstico organizacional definitivo sem base;
selecionar solução em E2;
ocultar gap para permitir gate;
fabricar Customer Recognition;
inventar evidência;
promover lifecycle material sem regra/revisão;
inferir vulnerabilidades psicológicas;
pressionar cliente;
reescrever snapshot histórico;
alterar E3 silenciosamente após mudança de Need Truth.

83. Proveniência de IA

Para outputs materiais registrar:

model/provider, quando aplicável;
prompt/template version interno sem expor IP desnecessário;
input references;
output timestamp;
tenant/purpose;
correlation id;
reviewer;
review status;
accepted/edited/rejected.

84. Permissões e need-to-know

Acesso deve considerar:

tenant;
engagement/case;
membership;
role;
purpose;
sensibilidade da fonte;
field-level restrictions quando necessário.

Nem todo seller precisa acessar toda evidência sensível para visualizar uma síntese autorizada.

85. Dados sensíveis

E2 pode conter:

dados pessoais;
opiniões sobre pessoas;
informações financeiras;
informações estratégicas;
problemas internos;
documentos confidenciais;
informação de terceiros.

Aplicar minimização, purpose limitation, retenção e acesso proporcional.

86. RLS e segregação

Regras mínimas:

nenhuma leitura cross-tenant;
nenhuma busca sem tenant scope;
background jobs preservam tenant;
exports preservam autorização;
links a Evidence não atravessam trust boundary;
mensagens de erro não revelam existência de dados de outro tenant.

87. Auditoria

Eventos candidatos:

meeting_prep_created;
need_candidate_created;
evidence_linked;
need_state_changed;
need_truth_draft_generated;
need_gate_reviewed;
need_isolated;
client_recognition_recorded;
opportunity_gate_decided;
need_truth_snapshot_created;
snapshot_pinned_to_e3;
material_change_detected;
downstream_review_requested;
need_revalidated;
need_rejected;
need_split;
need_merged.

88. Regras imutáveis

NeedInstance canônico não é substituído por Customer Need Truth.
Snapshot fixado por E3 não é editado in place.
Customer Recognition não é inventado.
Historical Need Truth não vira current truth automaticamente.
IA não promove hipótese a fato silenciosamente.
Need não é solução.
Gaps materiais não são escondidos.
mudança material downstream exige review.
cross-tenant access é negado.
decisões de gate possuem reason, actor e timestamp.
evidência material preserva fonte.
versões históricas permanecem ligadas às decisões que as utilizaram.

89. State machine — Customer Need Truth projection

Não criar lifecycle concorrente.

Estados de experiência possíveis:

WORKING_DRAFT
    ↓
SNAPSHOT_ELIGIBLE
    ↓
PINNED_TO_E3
 
lateral:
SUPERSEDED
INVALIDATED_FOR_CURRENT_FIT

Esses estados são de projeção/uso, não do Need Lifecycle canônico. Implementação física permanece ADR.

90. State machine — NeedInstance

Preservada:

SUSPECTED → EXPLORED → ISOLATED → CLIENT_VALIDATED
      ↘         ↘          ↘
              REJECTED

Transições exatas, rollback e estados auxiliares técnicos devem ser especificados no PRD de lifecycle.

91. Core flow — caminho feliz

E1 entrega Lead Intelligence Brief.
Seller abre Meeting Prep.
Sistema mostra o que sabemos, hipóteses, gaps e perguntas abertas sugeridas.
Reunião ocorre human-first.
Seller faz debrief depois.
Sistema estrutura Evidence, Knowledge Items e Need Candidates.
NeedInstance é criada/atualizada.
Customer Need Truth Working Draft é sintetizada.
Usuário revisa gaps, boundary e What Is Not The Need.
Need Isolation Gate é executado.
Se ISOLATED, snapshot é criado.
Opportunity Gate é executado.
Se CREATE, snapshot é elegível e pinado para E3.
E3 recebe Customer Need Truth + Offer Passport.

92. Empty states

Sem Lead Intelligence

Permitir preparação manual mínima ou redirecionar para E1 conforme regra de produto.

Sem Evidence

Não permitir Need ISOLATED; mostrar MORE_EVIDENCE_REQUIRED.

Sem Desired Future

Manter gap; se material, bloquear isolamento.

Sem Customer Recognition

Permitir ISOLATED, mas não marcar CLIENT_VALIDATED.

Sem Decision Unit conhecido

Não bloquear Need Isolation automaticamente; manter gap se material para Opportunity/Fit.

93. Error states

Em falha de IA:

preservar notas brutas;
permitir debrief manual;
não marcar processamento como concluído;
não perder Evidence já salva;
oferecer retry idempotente.

Em falha de snapshot:

não avançar E3 com versão incompleta;
manter NeedInstance intacto;
registrar erro técnico sem expor conteúdo sensível indevido.

94. Loading states

Processamentos assistidos devem indicar:

o que está sendo processado;
que a conversa/notas originais permanecem disponíveis;
que output da IA ainda não foi revisado;
possibilidade de continuar tarefas não bloqueadas.

Nunca mostrar “Need validada” durante loading.

95. Edge case — cliente pede solução imediatamente

Se cliente pede solução antes de Need suficientemente isolada:

registrar Customer Request;
responder humanamente conforme seller;
manter Need em investigação;
não promover Offer automaticamente;
preparar perguntas abertas sobre contexto, impacto e desired future.

96. Edge case — seller já conhece a solução

Conhecimento prévio da oferta não altera ordem metodológica.

Sistema pode alertar:

“Existing solution hypothesis — validate need independently.”

Não bloquear expertise humana; bloquear apenas atalhos de estado que violem gates.

97. Edge case — cliente contradiz Need na apresentação E4

Fluxo:

E4 customer statement
→ material change candidate
→ return E2
→ update Evidence
→ new Need Truth snapshot
→ review Opportunity/E3

Proposta não deve continuar como se nada tivesse mudado.

98. Edge case — nova necessidade durante E5

Não alterar Need antiga silenciosamente.

Possíveis decisões:

atualizar Need atual se for refinamento material do mesmo problema;
criar nova NeedInstance se for necessidade distinta;
retornar E2;
revisar E3/E4 conforme materialidade.

99. Edge case — outcome contradiz necessidade histórica

E6 pode gerar learning ou evidence sobre premissas anteriores.

Não reescrever Customer Need Truth histórico.

Registrar:

outcome evidence;
possible learning;
relation to historical Need;
proposed change em Need Pattern/metodologia, se aplicável.

100. Edge case — múltiplos stakeholders com verdades parciais

Customer Need Truth pode ser composta por múltiplas perspectivas, desde que cada afirmação preserve autoria e evidência.

Se conflito material permanecer:

declarar conflito;
manter gap;
não sintetizar consenso inexistente.

101. Edge case — causa-raiz desconhecida

Não exigir causalidade para toda Need.

Pode existir Need legítima com causa ainda desconhecida.

Exemplo:

Current Reality e Impact suficientemente conhecidos, mas causa-raiz ainda é hipótese.

Registrar causa como hypothesis/gap, sem bloquear automaticamente se solução puder ser avaliada responsavelmente em E3.

102. Edge case — problema resolvido antes de E3

Se nova evidência mostra que a Need foi resolvida:

atualizar lifecycle conforme regra;
Opportunity Gate → DO_NOT_CREATE;
preservar histórico;
impedir E3 novo;
gerar learning quando relevante.

103. Edge case — Need fora da competência da empresa vendedora

E2 pode isolar Need verdadeira mesmo que nenhuma Offer tenha fit.

Não distorcer Need para caber no portfólio.

Opportunity Gate e E3 devem decidir avanço/no-fit de forma independente.

104. Minimum Viable E2 Slice

Objetivo da fatia mínima:

provar que uma conversa humana pode ser preparada, estruturada depois e transformada em Customer Need Truth rastreável, capaz de passar por gates e alimentar E3 sem solution forcing.

Componentes mínimos:

Meeting Prep Brief;
debrief manual;
Evidence links;
classificação epistemológica;
NeedInstance;
Current Reality;
Impact;
Desired Future;
Priority;
Need Boundary;
What Is Not The Need;
Customer Recognition;
Open Gaps;
Need Isolation Gate;
Opportunity Gate;
Customer Need Truth Snapshot;
version/pinning para E3;
Human Review;
audit mínimo;
RLS.

105. O que não é requisito automático do MVP

Não exigir automaticamente:

gravação obrigatória de reunião;
transcrição em tempo real;
emotion recognition;
personality scoring;
questionário completo em tela;
análise causal automatizada;
scoring universal de Need;
NLP sofisticado de múltiplos idiomas;
integração com todos os CRMs;
graph database;
real-time copilot;
voice analytics;
predição de fechamento;
automação de follow-up.

Esses itens dependem de evidência e decisão futura.

106. Entidades e objetos afetados

Canônicos/reutilizados:

NeedInstance;
EvidenceItem;
KnowledgeItem;
Observation;
Hypothesis;
Gap;
DecisionUnit;
DecisionContext;
HumanReview;
Decision;
AuditEvent;
Version.

Projeções/experiências:

MeetingPrepBrief;
DiscoverySnapshot;
CustomerNeedTruthWorkingDraft;
CustomerNeedTruthSnapshot;
OpportunityDecisionOnePage.

107. Eventos mínimos

Eventos candidatos:

E2 prep created;
discovery completed;
debrief submitted;
evidence linked;
need created;
need updated;
need gate decided;
recognition recorded;
truth snapshot created;
opportunity gate decided;
snapshot pinned;
material change raised;
revalidation completed;
downstream review completed.

108. Critérios de aceite funcionais

109. Critérios de aceite técnicos e de segurança

110. Cenários mínimos de teste

A — Need bem isolada

Discovery gera Need completa, Gate ISOLATED, Opportunity CREATE, snapshot pinado em E3.

B — pedido de solução sem Need

Cliente pede “ERP”; sistema registra request e mantém Need em exploração.

C — gap crítico

Sem Desired Future/material Evidence; gate retorna MORE_EVIDENCE_REQUIRED.

D — cliente contradiz hipótese

Hypothesis é rejeitada; não vira Need.

E — múltiplas Needs

Duas NeedInstances separadas com gates próprios.

F — histórico

Snapshot antigo é revalidado como CHANGED e gera nova versão.

G — mudança material após E3

Novo snapshot gera review de fit.

H — mudança editorial

Texto corrigido sem invalidar E3.

I — cross-tenant

URL/API/search/export negam mistura.

J — IA indisponível

Fluxo manual permanece funcional.

111. Evidências de conclusão da fatia mínima

A fatia mínima estará demonstrada quando:

seller prepara Discovery em One-Page;
reunião pode ocorrer sem dependência de tela;
debrief pós-reunião é salvo;
Evidence e classes epistemológicas ficam rastreáveis;
NeedInstance percorre lifecycle mínimo;
Need Isolation Gate funciona;
Customer Need Truth Snapshot é criado;
Opportunity Gate funciona;
snapshot é pinado em E3;
versão histórica permanece acessível;
mudança material gera review;
RLS e permissions passam nos testes;
operação manual funciona quando IA falha;
fluxo é repetível com dados sintéticos e caso assistido.

Markdown e mockup não comprovam implementação.

112. Métricas candidatas

Sem metas aprovadas:

tempo para primeiro Meeting Prep;
tempo de Post-Meeting;
Need Candidates por caso;
% Needs isoladas;
% Needs rejeitadas;
% Needs client-validated;
gaps críticos por Need;
revisões por mudança material;
retornos E3 → E2;
snapshots revalidados;
tempo entre Discovery e Need Isolation;
esforço humano de correção da síntese da IA;
frequência de What Is Not The Need utilizado;
casos em que Customer Request ≠ Need final;
taxa de Opportunity DO_NOT_CREATE após Need isolada.

Não usar métricas como prova de valor antes de baseline e validação.

113. Learning candidates do E2

O E2 pode gerar learning candidates sobre:

padrões de Need;
perguntas mais úteis;
gaps recorrentes;
causas frequentes de falso positivo;
Customer Requests que não correspondem à Need;
Decision Unit gaps;
contextos de revalidação;
sinais de boundary relevantes.

Um caso não altera metodologia automaticamente.

114. Governança de learning

Fluxo:

Evidence
→ Learning Candidate
→ Review
→ Strengthen / Weaken / Reject
→ Proposed Change
→ Human Decision
→ Version

Learning não modifica Need historical snapshot, gates ou question map silenciosamente.

115. UX — princípios

One-Page First;
Evidence on Demand;
linguagem simples;
sem questionário obrigatório durante conversa;
mostrar gaps sem constranger seller;
usar status visíveis;
permitir operação manual;
explicar por que algo está bloqueado;
não esconder incerteza;
não sugerir solução antes da hora.

116. UX — seller

Seller deve conseguir responder em menos de um minuto:

o que sabemos;
o que não sabemos;
que Need estamos investigando;
o que falta para isolar;
se cliente reconheceu;
se Opportunity pode ser criada;
qual snapshot E3 está usando.

117. UX — liderança/reviewer

Reviewer deve conseguir:

comparar versões;
ver Evidence basis;
ver gaps;
ver quem mudou state;
ver motivo do gate;
ver reconhecimento do cliente;
ver downstream impact;
aprovar/rejeitar revisão material.

118. Export e artefatos

Exports devem indicar:

tenant/organization;
account/case;
NeedInstance;
snapshot version;
lifecycle state;
gate states;
validity;
generated/exported at;
confidentiality marker quando aplicável.

Evidence sensível pode ser omitida e referenciada conforme autorização.

119. Retenção

Retention deve ser definida por policy e contexto.

Preservar pelo menos o necessário para:

justificar decisões comerciais;
reconstruir snapshot usado em E3;
learning governado;
obligations legais/contratuais aplicáveis.

Não manter dados sensíveis indefinidamente sem finalidade.

120. Backward compatibility

Ao migrar casos antigos:

não inventar What Is Not The Need retroativamente;
marcar campos não disponíveis como unknown/gap;
preservar status histórico original;
gerar snapshot retrospectivo apenas quando fonte suficiente existir;
rotular reconstrução como retrospective/historical quando aplicável.

121. Impactos em E1

E1 deve fornecer contexto e hipóteses sem diagnosticar Need.

Retrofit mínimo:

permitir Historical Need Truth reference;
diferenciar hypothesis from previous truth;
alimentar revalidation questions.

122. Impactos em E3

E3 deve:

exigir Customer Need Truth Snapshot elegível;
pin version;
mostrar Client Recognition status;
mostrar material gaps/limitations;
reagir a NEED_TRUTH_CHANGED;
nunca editar Customer Need Truth diretamente.

123. Impactos em E4

E4 deve:

comunicar necessidade a partir do snapshot utilizado por E3;
não ampliar Need na narrativa;
bloquear/revisar quando apresentação revelar mudança material;
preservar linguagem do cliente quando apropriado.

124. Impactos em E5

E5 deve:

tratar nova informação como Evidence;
devolver mudança material a E2;
não resolver objeção redefinindo Need silenciosamente;
manter vínculo com snapshot de decisão.

125. Impactos em E6

E6 pode:

relacionar outcome à Need histórica;
gerar evidence e learning;
iniciar nova Need em renewal/expansion;
exigir revalidação em reactivation.

E6 não reescreve Customer Need Truth histórico.

126. Dependências técnicas

Candidatas:

identity/tenant/membership;
RLS;
Source/Evidence;
Knowledge Items;
NeedInstance storage;
versioning;
audit;
Human Review;
eventing mínimo;
UI One-Page;
optional AI service.

Não exigir microservices ou graph database para MVP.

127. ADRs abertos

Decisões futuras, não impeditivas da baseline:

CustomerNeedTruthSnapshot como tabela, JSON materializado ou view versionada;
enum final de Customer Recognition;
regra técnica de materiality classification;
lifecycle rollback/reopen detalhado;
retention por tenant/segmento;
evidence sufficiency policy;
version diff UX;
treatment de Need merge/split no banco;
event schema;
granularidade de field-level permissions;
política de transcrição/recording;
export formats.

128. Critérios para não expandir escopo

Não adicionar feature apenas porque melhora documentação.

Nova ideia deve ser classificada como:

necessária para completar fluxo;
necessária para segurança/segregação/confiabilidade;
necessária para piloto real;
melhoria baseada em evidência;
expansão pós-fatia mínima;
fora de escopo.

Somente as três primeiras são candidatas imediatas.

129. Invariantes finais do E2

NEED BEFORE SOLUTION.

EVIDENCE BEFORE CLAIM.

CUSTOMER REQUEST ≠ CUSTOMER NEED.

NEEDINSTANCE REMAINS CANONICAL.

CUSTOMER NEED TRUTH IS A GOVERNED PROJECTION.

WHAT IS NOT THE NEED PROTECTS FIT.

HISTORICAL NEED TRUTH ≠ CURRENT NEED TRUTH.

ISOLATED ≠ CLIENT_VALIDATED.

CLIENT RECOGNITION ≠ SOLUTION FIT.

WORKING DRAFT CANNOT AUTHORIZE E3.

E3 MUST PIN A SNAPSHOT.

MATERIAL NEED CHANGE REQUIRES FIT REVIEW.

GAPS REMAIN VISIBLE.

AI MAY SYNTHESIZE; IT MAY NOT FABRICATE TRUTH.

130. Tese final

O E2 não existe para produzir um diagnóstico bonito. Existe para transformar conversa humana em uma verdade comercial suficientemente estruturada para que a organização saiba o que está tentando resolver, como sabe, onde essa necessidade começa e termina, o que ainda não sabe e se existe base legítima para avançar.

131. Handoff para Sales Intelligence v0.3

Ao consolidar o Sales Intelligence v0.3, incorporar:

Customer Need Truth como saída oficial do E2;
simetria Customer Need Truth + Offer Passport → E3;
snapshot/versioning;
material change routing;
historical revalidation;
What Is Not The Need;
boundary e evidence limitations;
updated E2/E3 contracts.

132. Checklist de retrofit concluído

133. Glossário

Termo	Definição
NeedInstance	fonte canônica de uma necessidade comercial no caso
Customer Need Truth	projeção governada da melhor verdade comercial disponível sobre a Need
Working Draft	Need Truth ainda não elegível para E3
Customer Need Truth Snapshot	versão fixada e rastreável da Need Truth
Need Boundary	limite do que pertence à Need
What Is Not The Need	explicitação do que não deve ser confundido com a Need
Client Recognition	reconhecimento do cliente sobre a síntese
Need Isolation Gate	decisão sobre suficiência da estrutura da Need
Opportunity Gate	decisão independente sobre existência de oportunidade comercial
Material Truth Change	mudança que pode afetar fit/decisão downstream
Historical Need Truth	snapshot válido em contexto anterior, sujeito a revalidação
Discovery Snapshot	visão mais ampla do conhecimento do Discovery
Evidence Limitation	limite conhecido da força/abrangência da evidência

134. Bloco de inicialização para outra IA

CONTEXTO
Você está trabalhando no Orquestro™.
 
E2 v0.2 foi aprovado como:
E2.1 Meeting Preparation
→ E2.2 Human Discovery
→ E2.3 Post-Meeting Intelligence
→ Need Isolation Gate
→ Customer Need Truth Snapshot
→ Opportunity Gate
→ E3 Responsible Solution Fit
 
DECISÕES
- NeedInstance é canônico.
- Customer Need Truth é projeção governada/versionada.
- Working Draft não autoriza E3.
- E3 exige snapshot pinado.
- Need Lifecycle permanece SUSPECTED → EXPLORED → ISOLATED → CLIENT_VALIDATED ou REJECTED.
- Need Isolation Gate exige Current Reality, Evidence, Impact, Desired Future e Priority/Relevance.
- CLIENT_VALIDATED exige Client Recognition.
- Customer Request ≠ Customer Need.
- Need Boundary e What Is Not The Need protegem contra solution forcing.
- Historical Need Truth ≠ Current Need Truth.
- Mudança material exige review downstream.
- Discovery permanece human-first, com sistema mínimo durante a conversa.
- percepção não vira fato; hipótese não vira diagnóstico.
 
HANDOFF E3
Customer Need Truth + Offer Passport → Responsible Solution Fit.

135. Encerramento

Este documento substitui, para fins de arquitetura do E2, descrições anteriores que não formalizavam Customer Need Truth como projeção governada.

Ele não substitui os documentos standalone de E3–E6, E0.CORE ou E0.SALES.

Próximo movimento recomendado:

consolidar E0–E6 no Orquestro™ v0.3, preservando estas fronteiras como baseline arquitetural antes da decomposição em PRDs e incrementos de desenvolvimento.

E3 — Responsible Solution Fit v0.1

Fonte incorporada integralmente: Orquestro_E3_Responsible_Solution_Fit_v0.1_2026-08-22.md

Orquestro E3 — Responsible Solution Fit

Definição funcional: Need Truth, Offer Truth, Responsible Promise & Proposal Readiness
Versão: 0.1
Data: 22/08/2026
Status: baseline arquitetural aprovada pelas Founders para especificação e desenvolvimento incremental
Classificação: etapa especializada do Orquestro™
Escopo do documento: arquitetura funcional, decisão, conhecimento, experiência, dados, governança e Minimum Viable Responsible Solution Fit Slice
Dependências obrigatórias: E0.CORE — Organizational Context & Implementation Intelligence, E0.SALES — Offer Intelligence & Commercial Readiness, E1 Lead Intelligence, E2 Human Discovery, Need Isolation Gate e Opportunity Gate
Próxima etapa: E4 — Decision & Communication
Fonte metodológica aplicada: PRODUCT_PROMPT.md — Product Markdown Rail

Aviso de maturidade: este documento define a arquitetura pretendida e decisões aprovadas para o E3. Não comprova que o Responsible Solution Fit, o Customer Need Truth, o matching de Offers, a geração de proposta, os gates, a IA ou as integrações descritas estejam implementados, validados ou prontos para produção.

1. Finalidade do documento

Este documento especifica o E3 — Responsible Solution Fit, etapa responsável por transformar duas verdades governadas — a necessidade real do cliente e a verdade atual da oferta — em uma decisão comercial responsável sobre qual solução, se alguma, pode ser oferecida, sob quais condições, com quais limites e com qual promessa comercial.

O E3 deve orientar:

produto;
arquitetura de conhecimento;
Commercial Decision Engine™;
experiência do seller e da liderança;
matching entre necessidade e oferta;
Human Review;
governança de claims e promises;
configuração comercial;
readiness para geração de proposta;
geração assistida e governada de propostas;
integração com E4;
rastreabilidade entre Discovery, solução, promessa, proposta, decisão e outcome;
testes e pilotos.

Este é um documento de arquitetura e especificação modular. Funcionalidades técnicas menores, telas específicas e automações deverão gerar PRDs próprios conforme a taxonomia estrita do Product Markdown Rail.

2. Decisão arquitetural aprovada

Decisão:

E3 deixa de ser apenas uma análise genérica ou otimista de Solution Fit. Passa a ser o mecanismo bilateral de verdade entre Customer Need Truth e Offer Passport, com lógica adversarial ao fit, proteção contra solution forcing e capacidade explícita de concluir NO FIT.

Decisões complementares aprovadas:

Customer Need Truth é uma projeção governada do NeedInstance e de seus objetos relacionados, e não uma nova verdade canônica concorrente;
Offer Passport permanece a projeção governada da verdade atual da Offer Version;
E3 começa somente após Need Isolation Gate e Opportunity Gate permitirem avanço;
Need Pattern pode identificar ofertas candidatas, mas não pode declarar fit;
E3 deve procurar mismatch, condição, anti-fit, gap, constraint e unsupported promise antes de recomendar avanço;
algumas dimensões funcionam como hard stops e não podem ser compensadas por média ou score universal;
PARTIAL FIT não autoriza proposta diretamente;
customização fora do limite autorizado da Offer Version não pode ser criada silenciosamente em E3;
E3 deve produzir uma Responsible Commercial Promise específica para o caso;
o alinhamento explícito do cliente com essa promise autoriza o avanço para readiness de proposta, mas não equivale à aceitação da proposta comercial;
quando os parâmetros comerciais já estiverem governados e autorizados no E0.SALES, o sistema deve reutilizá-los, não redescobri-los;
um Proposal Readiness Gate mínimo determina se a proposta pode ser gerada, exige revisão ou ainda não está pronta;
proposta deve ser gerada por derivação de objetos governados, e não por redação livre da IA;
E4 recebe um Proposal Ready Package e transforma a decisão já estruturada em comunicação e decisão comercial.

3. Tese central

E3 não procura uma oferta para vender. E3 testa se existe uma oferta que a organização pode responsavelmente defender diante da verdade atual da necessidade do cliente.

A pergunta central não é:

“Qual dos nossos serviços encaixa aqui?”

É:

“Diante do que sabemos ser verdade sobre a necessidade e do que sabemos ser verdade sobre nossas ofertas, existe uma combinação que possamos responsavelmente oferecer, entregar e sustentar?”

O E3 deve ser construído para resistir a cinco desvios comuns:

selecionar uma solução porque ela está disponível;
reinterpretar a necessidade para caber no portfólio;
usar relacionamento como compensação para baixo fit;
ampliar escopo silenciosamente para “fazer caber”;
prometer resultado sem cadeia suficiente de capability, evidence e conditions.

4. Posição na jornada comercial

flowchart TB
    E0["E0.CORE + E0.SALES\nOrganization & Offer Truth"]
    E1["E1\nLead Intelligence"]
    E2["E2\nHuman Discovery"]
    NG{"Need Isolation Gate"}
    OG{"Opportunity Gate"}
    CNT["Customer Need Truth"]
    OP["Offer Passport"]
    E3["E3\nResponsible Solution Fit"]
    PA{"Promise Alignment"}
    PR{"Proposal Readiness Gate"}
    P["Proposal Generated"]
    E4["E4\nDecision & Communication"]
    E6["E6\nOutcome & Learning"]

    E0 --> E1 --> E2 --> NG --> OG --> CNT
    E0 --> OP
    CNT --> E3
    OP --> E3
    E3 --> PA
    PA --> PR
    PR --> P
    P --> E4
    E4 --> E6
    E6 --> E0

Regra:

Offer readiness não autoriza solution selection. Need isolation não prova fit. Promise alignment não equivale a proposal acceptance.

5. Fronteiras entre E0, E2, E3 e E4

Etapa	Pergunta central	Verdade / saída principal
E0.SALES	o que podemos responsavelmente oferecer?	Offer / Offer Version / Offer Passport / Commercial Configuration
E2	qual necessidade, se alguma, existe?	NeedInstance / Customer Need Truth
E3	qual oferta, se alguma, possui fit responsável?	SolutionFitAssessment / Responsible Commercial Promise / Proposal Ready Package
E4	como comunicar essa decisão e permitir que o cliente decida?	proposta, narrativa decisória e decisão comercial

E3 não deve:

refazer Discovery;
inventar necessidade;
editar silenciosamente Offer Version;
definir preço fora do que estiver autorizado;
redigir claims não suportados;
transformar promise alignment em fechamento;
substituir E4 na comunicação e decisão comercial.

6. Arquitetura de duas verdades

A base do E3 é a comparação entre duas projeções governadas.

flowchart LR
    N["NeedInstance + Evidence + Context"] --> CNT["Customer Need Truth"]
    O["Offer + OfferVersion + Evidence + Conditions"] --> OP["Offer Passport"]
    CNT --> E3["Responsible Solution Fit"]
    OP --> E3

6.1 Verdade do cliente

Customer Need Truth representa a síntese atual, rastreável e temporal da necessidade suficientemente isolada.

6.2 Verdade do seller

Offer Passport representa a síntese atual, rastreável e temporal do que a organização pode responsavelmente oferecer.

6.3 Regra de simetria

Customer Need Truth	Offer Passport
Current Reality	Offer Scope
Evidence	Capability Evidence
Impact	Intended Outcome
Desired Future	Promise
Priority	Intended Need
Need Boundary	Configuration Boundary
Customer Constraints	Customer Prerequisites / Seller Constraints
Gaps	Offer Gaps
Context	Conditions / Exclusions / Anti-fit
Need Snapshot	Offer Version

7. Customer Need Truth

7.1 Definição

Customer Need Truth é uma projeção governada, não uma nova entidade canônica de necessidade.

Ela deve ser derivada de:

NeedInstance;
EvidenceItem;
KnowledgeItem;
Customer Statements;
Seller Observations;
hipóteses e gaps ainda abertos;
Need Isolation Gate;
client recognition quando disponível;
Decision Context relevante;
snapshot temporal.

7.2 Conteúdo mínimo

Customer Need Truth
 
Need
Current Reality
Evidence
Impact
Desired Future
Priority / Relevance
Need Boundary
What Is Not The Need
Customer Recognition Status
Known Customer Constraints
Known Resources
Timing / Urgency
Implementation Context
Relevant Decision Unit
Open Gaps
Evidence Limitations
Need Version / Snapshot
Last Confirmation
Validity / Temporal Context

7.3 `What Is Not The Need`

O E3 deve preservar explicitamente hipóteses de necessidade rejeitadas, resolvidas, insuficientemente comprovadas ou que representem apenas solução desejada.

Exemplo:

Customer request:
Treinamento de liderança
 
Customer Need Truth:
Clareza de papéis + accountability + governança decisória
 
What Is Not Established As Need:
Déficit técnico de conhecimento de liderança

Regra:

Uma solução desejada ou inicialmente solicitada pelo cliente não deve retornar como “necessidade” sem evidência suficiente.

8. Offer Context Package

E3 consome um pacote governado do E0.SALES.

Conteúdo conceitual:

Offer;
Offer Version;
Offer Passport;
Need Patterns;
Intended Outcomes;
promises;
claims;
capabilities;
evidence;
customer prerequisites;
seller constraints;
partner dependencies;
conditions;
exclusions;
anti-fit;
current capacity;
Offer Readiness;
Commercial Configuration;
pricing/economics status permitido;
configuration boundaries;
approval boundaries;
gaps e conflicts materiais.

O formato técnico definitivo do E3 Offer Context Package permanece assunto de PRD/ADR próprio.

9. Preconditions de entrada em E3

O E3 pode iniciar apenas quando, no mínimo:

Need Isolation Gate = ISOLATED ou estado equivalente autorizado
Opportunity Gate = CREATE / ADVANCE
Need snapshot = válido
Offer portfolio = acessível conforme permissão

Se qualquer precondition obrigatória estiver ausente:

não executar matching material;
não selecionar solução;
não gerar promise comercial;
não gerar proposta.

Estados possíveis:

retornar E2;
solicitar Human Review;
encerrar oportunidade;
aguardar atualização do E0.SALES.

10. E3.1 — Candidate Eligibility

10.1 Objetivo

Reduzir o universo de ofertas para aquelas que podem legitimamente ser avaliadas.

10.2 Sinais permitidos para candidatura

Need Pattern;
Intended Need;
Intended Outcome;
contexto organizacional;
segmento quando material;
prerequisites conhecidos;
Offer lifecycle;
Offer readiness;
disponibilidade;
boundaries.

10.3 Regra imutável

Need Pattern identifica candidato; não declara fit.

10.4 Saídas

CANDIDATE OFFERS FOUND
NO CANDIDATE OFFER
MORE OFFER INFORMATION REQUIRED
HUMAN REVIEW REQUIRED

Zero ofertas candidatas é um resultado legítimo.

11. E3.2 — Multidimensional Responsible Fit

A arquitetura preserva as nove dimensões aprovadas de fit, mas as organiza em camadas funcionais.

11.1 Camada I — Need & Outcome Fit

Dimensão	Pergunta
Need Fit	a oferta responde à necessidade suficientemente isolada?
Solution Fit	componentes e abordagem são adequados para a necessidade?
Strategic Fit	a intervenção contribui para prioridade realmente relevante?

Pergunta crítica:

Estamos atacando a necessidade ou apenas algo que sabemos vender?

11.2 Camada II — Delivery & Implementation Fit

Dimensão	Pergunta
Capability Fit	a organização vendedora possui capability suficiente?
Implementation Fit	o cliente possui condições mínimas para implantar?
Resource Fit	orçamento, pessoas, tempo e recursos são compatíveis?
Timing Fit	existe janela adequada para executar e absorver a solução?

Regra:

Saber fazer não significa poder entregar agora.

11.3 Camada III — Decision & Relationship Context

Dimensão	Pergunta
Relationship Fit	existe legitimidade e confiança suficientes para uma conversa comercial útil?
Decision Context	os atores, autoridade, aprovação e condições decisórias estão suficientemente compreendidos?

Regra:

Relationship Fit nunca compensa ausência de Need Fit.

Relacionamento influencia viabilidade comercial, acesso e decisão; não altera a verdade técnica da necessidade.

11.4 Camada IV — Responsible Fit

Dimensão	Pergunta
Risk Fit	riscos, efeitos não desejados, compliance, reputação e dependências são aceitáveis e tratáveis?
Promise Integrity	a promessa necessária pode ser sustentada por capability, evidence e conditions?
Boundary Integrity	a solução permanece dentro dos limites autorizados da oferta?

12. Sem score universal obrigatório

E3 não deve depender de média, nota universal ou score composto obrigatório.

Exemplo proibido:

Need Fit = 2
Relationship Fit = 10
Strategic Fit = 9
 
Média = 7
→ vender

Regra:

Algumas dimensões não são compensatórias.

Scores auxiliares podem existir futuramente para navegação ou priorização, desde que não substituam regras, evidências, hard stops e Human Review.

13. Hard Stops

Hard stops bloqueiam ou redirecionam o avanço independentemente de outras dimensões positivas.

Exemplos:

Condição	Consequência mínima
Need Fit material = falso	`NO FIT`
anti-fit confirmado	`NO FIT` ou specialist review
capability essencial inexistente	`NO FIT` ou Offer Change process
claim material necessário sem sustentação	remover claim, reformular promise ou bloquear
prerequisite essencial inexistente	`CONDITIONAL FIT`, `MORE EVIDENCE REQUIRED` ou `NO FIT`
risco legal/ético inaceitável	`NO FIT`
informação essencial desconhecida	`MORE EVIDENCE REQUIRED`
Offer Version inválida/retirada	bloquear matching
commercial configuration fora do autorizado	`REVIEW REQUIRED`
escopo necessário excede configuration boundary	Offer Change Proposal / nova Offer Version

A lista definitiva de hard stops por tipo de oferta poderá ser refinada por domínio e PRD.

14. Promise Integrity Chain

E3 deve testar a cadeia:

flowchart LR
    N["NEED"] --> P["PROMISE"]
    P --> C["CAPABILITY"]
    C --> E["EVIDENCE"]
    E --> CO["CONDITIONS"]

Pergunta material:

Conseguimos sustentar cada promessa relevante que precisaremos fazer para defender esta solução neste caso?

A cadeia deve permitir rastrear:

qual necessidade sustenta a promise;
qual resultado pretendido está relacionado;
qual capability sustenta a promise;
qual evidence apoia a capability ou claim;
quais limitations se aplicam;
quais prerequisites precisam existir;
quais constraints permanecem;
quem revisou;
qual versão estava vigente.

15. Estados do Solution Fit Assessment

Estados aprovados:

STRONG FIT;
CONDITIONAL FIT;
PARTIAL FIT;
NO FIT;
MORE EVIDENCE REQUIRED;
SPECIALIST REVIEW REQUIRED.

15.1 Semântica

Estado	Significado	Movimento mínimo
STRONG FIT	necessidade, solução, entrega e responsabilidade são compatíveis	preparar Responsible Commercial Promise
CONDITIONAL FIT	existe fit desde que condições explícitas sejam satisfeitas	registrar condições, revisar e só então avançar
PARTIAL FIT	a oferta atende apenas parte material da necessidade	reconfigurar, fasear, combinar ou não avançar
NO FIT	não existe oferta responsável para aquela necessidade	não vender / registrar learning
MORE EVIDENCE REQUIRED	não existe evidência suficiente para concluir	retornar E2 ou obter evidência específica
SPECIALIST REVIEW REQUIRED	decisão excede autoridade, conhecimento ou risco permitido	Human/Specialist Review

16. Regra especial para `PARTIAL FIT`

PARTIAL FIT não autoriza diretamente proposta.

Fluxo:

flowchart LR
    PF["PARTIAL FIT"] --> A["Authorized Configuration"]
    PF --> PH["Phased Solution"]
    PF --> PA["Partner / Third-party"]
    PF --> RO["Reduced Objective"]
    A --> R["Reassess Fit"]
    PH --> R
    PA --> R
    RO --> R

A nova configuração deve passar novamente por fit antes de gerar promise comercial definitiva.

17. Alternativas legítimas de E3

E3 deve permitir:

oferta atual sem alteração;
oferta adaptada dentro de limites autorizados;
solução em fases;
combinação autorizada de componentes;
solução de parceiro ou terceiro, quando legítimo e governado;
investigação adicional;
não oferecer solução;
encerrar o ciclo;
propor alteração de Offer Version fora do caso corrente.

Não vender é uma saída legítima.

18. Customização e Offer Boundary

E3 não pode ampliar silenciosamente a oferta para fazê-la caber na necessidade.

Quando a configuração necessária exceder o configuration boundary:

flowchart TB
    E3["E3"] --> OOB["Outside Authorized Offer Boundary"]
    OOB --> OCP["Offer Change Proposal"]
    OCP --> E0["E0.SALES + Human Review"]
    E0 --> NV["New / Revised Offer Version"]
    NV --> E3R["Re-run E3"]

Regra:

Necessidade do cliente não autoriza criação silenciosa de capacidade, escopo, preço ou promise.

19. Responsible Commercial Promise

19.1 Definição

Responsible Commercial Promise é a promessa específica, contextualizada, limitada e sustentada que a organização pode fazer para aquele caso após conclusão adequada do fit.

Não é:

slogan;
claim de marketing genérico;
garantia de resultado;
cópia da descrição da oferta;
solução desejada pelo cliente sem validação;
compromisso fora da capacidade atual.

19.2 Estrutura conceitual

Responsible Commercial Promise
 
Need reference
Offer Version reference
Intended transformation
Scope of promise
Expected contribution
Conditions
Limitations
Customer prerequisites
Seller constraints
Supported claims
Prohibited / unsupported claims
Evidence references
Reviewer
Version / timestamp

19.3 Regra

A promise deve ser mais específica do que a promessa genérica da oferta e nunca mais ampla do que a evidência e a capacidade autorizam.

20. Exemplo de Responsible Commercial Promise

Offer Passport genérico:

Melhorar governança e eficiência da gestão.

Customer Need Truth:

Dependência excessiva de sócios para decisões operacionais, baixa clareza de responsabilidades e necessidade reconhecida de maior autonomia com governança.

Responsible Commercial Promise possível:

Estruturar responsabilidades, mecanismos de decisão e controles gerenciais para reduzir a dependência operacional atualmente identificada, dentro do escopo e das condições acordadas.

Claims não autorizados sem evidência específica:

aumentar lucro;
garantir crescimento;
eliminar conflitos;
profissionalizar integralmente a empresa;
garantir autonomia plena.

21. Promise Alignment

21.1 Objetivo

Antes de gerar proposta, o cliente deve reconhecer que a promise representa adequadamente a transformação que está sendo considerada.

Pergunta conceitual:

“É essa transformação que faz sentido enfrentar agora?”

21.2 Regra crítica

Promise Alignment não equivale a Proposal Acceptance.

Promise Alignment significa:

o problema foi compreendido de forma suficiente;
a transformação proposta faz sentido;
existe base para estruturar a oferta comercial.

Não significa:

aceite de preço;
aceite de prazo;
aceite contratual;
fechamento;
WON.

21.3 Estados conceituais

Até definição técnica final, considerar semanticamente:

ALIGNED;
PARTIALLY ALIGNED;
NOT ALIGNED;
NOT CONFIRMED.

Esses nomes não constituem ainda enum técnico definitivo sem PRD específico.

22. O que acontece se a Promise não for aceita

`PARTIALLY ALIGNED`

registrar o ponto de divergência;
distinguir mudança de necessidade, mudança de expectativa e problema de redação;
retornar ao ponto correto;
revalidar fit se houver alteração material.

`NOT ALIGNED`

não gerar proposta;
retornar E2 se a divergência indicar necessidade mal compreendida;
reexecutar E3 se a necessidade permanecer e a solução estiver inadequada;
encerrar quando não houver fit legítimo.

`NOT CONFIRMED`

proposta automática fica bloqueada;
Human Review pode autorizar exceção somente se existir regra comercial aprovada para esse cenário e sem presumir reconhecimento do cliente.

23. Commercial Configuration

23.1 Decisão aprovada

E0.SALES deve disponibilizar, quando aplicável e governado, parâmetros comerciais reutilizáveis pela jornada.

Objetivo:

Evitar que E3 ou E4 redescubram preço, pacote, esforço, horas, condições e limites que a organização já conhece e autorizou.

23.2 Conteúdo conceitual

Commercial Configuration
 
Pricing Model
Base Price / Authorized Range
Package / Tier
Effort Basis
Included Hours, when applicable
Included Components
Optional Components
Implementation Fee, when applicable
Recurring Fee, when applicable
Payment Terms
Discount Boundary
Configuration Boundary
Validity Rules
Capacity Dependency
Partner Costs, when applicable
Commercial Exceptions
Approval Authority
Pricing / Economics Status

23.3 Regra de proporcionalidade

Nem toda oferta exige horas, pacote ou preço fixo.

O modelo deve suportar, sem presumir equivalência:

preço fixo;
preço por pacote;
preço por hora;
faixa autorizada;
fórmula simples governada;
recorrência;
implantação + recorrência;
preço sob revisão humana;
proposta customizada dentro de boundary;
oferta sem pricing suficientemente definido.

23.4 Não virar CPQ complexo

No MVP, o objetivo não é pricing optimization, configuration engine universal ou cálculo econômico avançado.

A pergunta mínima é:

“Esta configuração comercial está dentro do que foi autorizado?”

24. Pricing e economics

E3 não valida pricing automaticamente como verdade econômica universal.

Deve consumir o pricing/economics status do E0.SALES e decidir se ele é suficiente para proposta.

Exemplos de condições conceituais:

valor fixo autorizado;
faixa autorizada;
fórmula autorizada;
preço que exige aprovação;
preço ainda tratado como hipótese;
informação indisponível.

O enum técnico definitivo deve ser fixado em PRD/ADR próprio.

Regra:

Preço conhecido não é necessariamente preço validado pelo mercado; preço autorizado não é preço aceito pelo cliente.

25. Proposal Readiness Gate

25.1 Objetivo

Determinar se o conhecimento já é suficiente para gerar uma proposta comercial governada.

25.2 Checklist mínimo

Proposal Readiness
 
Need Truth válida
Responsible Solution Fit aprovado
Responsible Commercial Promise definida
Promise Alignment confirmado
Offer Version fixada
Scope/configuração dentro dos limites
Pricing vigente e autorizado
Capacity suficiente ou condição explícita
Conditions conhecidas
Customer prerequisites registrados
Sem unsupported claims materiais
Sem gap impeditivo
Human/Specialist Review concluído quando obrigatório

25.3 Estados

READY;
REVIEW REQUIRED;
NOT READY.

25.4 `READY`

Permite gerar proposta a partir dos objetos governados.

25.5 `REVIEW REQUIRED`

Exemplos:

desconto fora do limite;
horas diferentes do pacote autorizado;
escopo novo;
parceiro ainda não aprovado;
condição comercial excepcional;
prazo excepcional;
customização além do boundary;
pricing/economics ainda sob hipótese ou revisão;
capacidade de entrega duvidosa;
claim material que exige especialista.

25.6 `NOT READY`

Exemplos:

Offer sem readiness suficiente;
fit insuficiente;
promise não sustentada;
Promise Alignment ausente quando obrigatório;
preço inexistente para uma oferta que exige preço definido;
scope fora da oferta;
capability essencial ausente;
gap material não resolvido.

26. Proposal Ready Package

26.1 Definição

Proposal Ready Package é uma projeção/handoff governado do E3 para geração de proposta e E4.

Não deve duplicar desnecessariamente objetos canônicos.

26.2 Conteúdo

Proposal Ready Package
 
Customer Need Truth snapshot
Need Version
Offer
Offer Version
Responsible Commercial Promise
Solution Fit Decision
Fit Conditions
Selected Components
Included Scope
Excluded Scope
Customer Prerequisites
Seller Constraints
Commercial Configuration snapshot
Pricing Basis
Hours / Effort, when applicable
Timeline Basis
Payment Conditions
Claims Allowed
Claims Prohibited
Evidence References
Risks
Open non-blocking Gaps
Human Reviews
Proposal Readiness Decision
Version / timestamp

27. Geração da proposta por derivação

27.1 Princípio

A IA não deve receber apenas “faça uma proposta para a empresa X”.

Ela deve receber os objetos governados e compor o documento dentro deles.

27.2 Fluxo

flowchart TB
    CNT["Customer Need Truth"]
    OV["Offer Version"]
    RCP["Responsible Commercial Promise"]
    CC["Commercial Configuration"]
    SF["Solution Fit Decision"]
    PR["Proposal Readiness = READY"]
    GEN["Governed Proposal Generation"]
    PROP["Proposal Draft / Version"]
    E4["E4 Decision & Communication"]

    CNT --> GEN
    OV --> GEN
    RCP --> GEN
    CC --> GEN
    SF --> GEN
    PR --> GEN
    GEN --> PROP --> E4

27.3 Conteúdo derivável

Quando disponível, a proposta pode derivar:

contexto;
necessidade compreendida;
objetivo / transformação pretendida;
Responsible Commercial Promise;
solução selecionada;
escopo incluído;
exclusões;
abordagem ou metodologia permitida;
entregáveis;
responsabilidades das partes;
prerequisites;
cronograma ou base de cronograma;
investimento;
condições de pagamento;
validade;
condições e limites;
evidências ou cases autorizados;
próxima decisão.

28. Regras de segurança para geração da proposta

A geração automática/assistida não pode:

inventar preço;
inventar desconto;
inventar horas;
ampliar scope;
incluir componente não autorizado;
omitir exclusion material para aparentar maior aderência;
alterar Responsible Commercial Promise silenciosamente;
criar claim não suportado;
transformar intended outcome em garantia;
inserir case sem autorização;
inferir capacity inexistente;
substituir Human Review obrigatório;
mudar Offer Version de referência;
esconder condition de fit;
marcar oportunidade como ganha.

29. Relação entre E3 e E4

E3 decide:

o que é responsável oferecer.

E4 decide e executa:

como comunicar essa decisão e permitir que o cliente a compreenda, compare e decida.

29.1 Handoff

E3
Customer Need Truth
+
Selected Offer Version
+
Responsible Commercial Promise
+
Fit Conditions
+
Commercial Configuration
+
Pricing Basis
+
Proposal Readiness
 
↓
 
Proposal Ready Package
 
↓
 
E4 — Decision & Communication
 
↓
 
Proposal
Decision Narrative
Decision Conversation
Commercial Decision

E4 não deve precisar redescobrir a necessidade ou reconstruir a lógica econômica da oferta quando essas informações já estiverem governadas.

30. Acceptance da Promise versus acceptance da Proposal

A arquitetura deve preservar eventos diferentes.

flowchart LR
    PA["Promise Alignment"] --> PG["Proposal Generated"]
    PG --> PP["Proposal Presented"]
    PP --> CD["Commercial Decision"]
    CD --> W["WON"]
    CD --> L["LOST"]
    CD --> P["POSTPONED / NO DECISION"]

Regra:

Promise Alignment confirma compreensão da transformação. Proposal Acceptance confirma decisão comercial. São fatos diferentes e devem permanecer diferentes.

31. Human Review

Human Review deve ser proporcional ao risco e materialidade.

Pode ser obrigatório quando houver:

SPECIALIST REVIEW REQUIRED;
preço ou margem sensível;
desconto excepcional;
alteração de scope;
condition material;
parceiro;
claim de resultado relevante;
compliance/legal risk;
decisão de vender apesar de warning significativo;
proposal generation com dados incompletos autorizada por política excepcional.

Registrar:

reviewer;
papel;
decisão;
justificativa;
objeto e versão revisados;
timestamp;
conditions;
expiry, quando aplicável.

32. Papéis conceituais

Papel	Responsabilidade no E3
Seller	consulta fit, conduz alinhamento humano e prepara decisão
Sales Manager / Offer Owner	revisa fit e configuração material
Offer Owner	protege Offer Truth e boundaries
Delivery Reviewer	valida capacidade/execução quando necessário
Financial Reviewer	revisa price, cost ou margin quando necessário
Compliance/Specialist Reviewer	revisa risco e claims especializados
Partner Reviewer	confirma condição de terceiro quando aplicável
Platform Operator	suporte técnico sem autoridade comercial por padrão

Field-level access definitivo para price, cost e margin depende de ADR/PRD próprio e não deve ser presumido por este documento.

33. Objetos e entidades

33.1 Objetos canônicos compartilhados

Organization/Tenant;
Project/Engagement;
Source;
EvidenceItem;
KnowledgeItem;
Observation;
Hypothesis;
Gap;
NeedInstance;
HumanReview;
Decision;
Action;
Outcome;
Learning;
AuditEvent;
Version.

33.2 Objetos consumidos de E0.SALES

Offer;
OfferVersion;
OfferPromise;
OfferClaim;
IntendedOutcome;
NeedPattern;
Capability;
CapabilityEvidenceLink;
CustomerPrerequisite;
SellerConstraint;
OfferCondition;
OfferExclusion;
AntiFitPattern;
OfferGap;
OfferConflict;
OfferReadinessAssessment;
CommercialCapacitySignal;
OfferPassport como projeção.

33.3 Objetos próprios ou especializados de E3

A modelagem física definitiva deve ser deliberada por ADR, mas conceitualmente E3 necessita de:

SolutionFitAssessment — objeto canônico da avaliação;
CandidateOfferAssessment — pode ser entidade ou estrutura interna conforme necessidade técnica;
ResponsibleCommercialPromise — objeto versionado ou registro especializado relacionado ao fit;
PromiseAlignment — evento/registro de reconhecimento;
ProposalReadinessDecision — decisão do gate;
ProposalReadyPackage — projeção/handoff;
CustomerNeedTruth — projeção, não entidade canônica concorrente;
CommercialConfiguration — objeto/projeção pertencente à verdade comercial de E0.SALES e consumido em E3.

Regra:

Não criar uma tabela para cada conceito sem necessidade de persistência, consulta, versionamento ou auditoria.

34. Versionamento e pinning

Toda avaliação material deve fixar:

Need snapshot/version;
Offer Version;
Offer Passport version/snapshot;
Commercial Configuration válida no momento;
evidence relevante;
Responsible Commercial Promise version;
Human Reviews;
Proposal Ready Package version.

Se Offer Version mudar materialmente antes da proposta:

reavaliar readiness;
reexecutar dimensões de fit impactadas;
não substituir silenciosamente a versão anterior.

Se Need Truth mudar materialmente:

invalidar ou colocar em revisão o fit anterior;
reexecutar E3 conforme impacto.

35. Eventos de auditoria candidatos

Sem fixar schema técnico definitivo, considerar eventos como:

solution_fit_started;
candidate_offer_added;
candidate_offer_removed;
fit_dimension_assessed;
hard_stop_triggered;
fit_decision_recorded;
responsible_promise_created;
responsible_promise_revised;
promise_alignment_recorded;
commercial_configuration_selected;
commercial_exception_requested;
proposal_readiness_evaluated;
proposal_ready_package_created;
proposal_generation_requested;
proposal_generated;
human_review_requested;
human_review_completed;
fit_invalidated_by_need_change;
fit_invalidated_by_offer_change.

Os nomes de eventos não são ainda contrato técnico definitivo.

36. Rastreabilidade mínima

Uma proposta gerada deve conseguir responder:

de qual Need Truth veio;
quais evidências sustentam a necessidade;
qual Offer Version foi usada;
por que a oferta foi considerada fit;
quais dimensões limitaram a decisão;
qual Responsible Commercial Promise foi aprovada;
quais claims são permitidos;
quais claims foram bloqueados;
qual Commercial Configuration foi aplicada;
quem aprovou exceções;
quais condições ainda existem;
qual Proposal Ready Package originou a proposta.

37. IA — responsabilidades permitidas

A IA pode auxiliar em:

comparar Need Truth e Offer Passport;
sugerir ofertas candidatas;
destacar mismatch;
detectar anti-fit potencial;
mapear prerequisites ausentes;
identificar gaps;
comparar intended outcomes e Desired Future;
verificar cadeia promise-capability-evidence-condition;
sugerir perguntas adicionais;
resumir dimensões de fit;
sugerir Responsible Commercial Promise;
preparar Human Review;
checar configuração contra boundaries;
compor proposta a partir de objetos autorizados;
detectar divergência entre proposta e Proposal Ready Package.

38. IA — proibições

A IA não pode, por decisão autônoma não governada:

declarar necessidade inexistente;
sobrescrever client recognition;
transformar hipótese em fato;
selecionar oferta antes dos gates;
compensar hard stop por score;
criar Offer Version;
alterar preço autorizado;
criar desconto;
criar capability;
remover constraint;
eliminar exclusion;
autorizar claim material sem regra;
garantir outcome;
aceitar proposal em nome do cliente;
transformar silence em consentimento;
marcar oportunidade como WON;
criar promessa além da Offer Truth.

39. UX — One-Page First

A experiência principal do E3 deve ser simples apesar da rastreabilidade profunda.

39.1 Responsible Solution Fit One-Page

Conteúdo prioritário:

RESPONSIBLE SOLUTION FIT
 
CUSTOMER NEED
Customer Need Truth + version
 
CANDIDATE / SELECTED OFFER
Offer + Offer Version
 
FIT DECISION
STRONG / CONDITIONAL / PARTIAL / NO FIT / ...
 
WHY
principais razões
 
WHAT FITS
componentes aderentes
 
WHAT DOES NOT FIT
lacunas e limites
 
CONDITIONS
condições necessárias
 
CUSTOMER PREREQUISITES
responsabilidades/condições do cliente
 
SELLER CONSTRAINTS
limites internos
 
RESPONSIBLE COMMERCIAL PROMISE
promessa específica
 
PROHIBITED / UNSUPPORTED CLAIMS
claims não permitidos
 
RISKS
riscos materiais
 
GAPS
o que ainda não sabemos
 
COMMERCIAL CONFIGURATION
somente campos permitidos ao papel
 
HUMAN REVIEW
status
 
NEXT DECISION
E4 / E2 / Review / Close

39.2 Evidence on Demand

A One-Page não deve despejar toda a evidência na tela principal.

Drill-down deve permitir:

fontes;
evidências;
versões;
limits;
claim support;
review history;
audit trail.

40. Empty States

Sem Need Truth válida

Mensagem funcional:

Ainda não existe necessidade suficientemente isolada para avaliar solução.

Ação:

retornar ao Discovery;
não mostrar “melhores ofertas”.

Sem oferta candidata

Mensagem funcional:

Nenhuma oferta atual atende aos critérios mínimos para avaliação responsável.

Ações possíveis:

encerrar;
registrar learning;
encaminhar terceiro/parceiro quando autorizado;
Offer Change Proposal sem alterar o caso silenciosamente.

Sem Commercial Configuration suficiente

Mensagem funcional:

Existe fit de solução, mas a configuração comercial ainda não está pronta para proposta.

Ação:

REVIEW REQUIRED ou NOT READY.

41. Loading States

Quando IA ou serviços auxiliares estiverem processando:

não bloquear acesso às verdades já aprovadas;
indicar que a avaliação está em processamento;
não mostrar fit provisório como decisão final;
preservar última decisão aprovada com timestamp;
permitir retry seguro quando aplicável;
evitar duplicar avaliações por clique repetido.

42. Error States

Falha técnica durante matching, avaliação, readiness ou geração de proposta não deve alterar estado comercial automaticamente.

Regras:

preservar última versão válida;
registrar erro técnico sem transformar em NO FIT;
permitir retry idempotente quando possível;
não perder Human Review já concluído;
não gerar proposta parcial como se fosse final;
informar ao usuário qual etapa falhou;
manter trilha de auditoria.

43. Edge Cases — Need mudou durante E3

Se informação nova alterar materialmente Current Reality, Impact, Desired Future, Priority ou Need Boundary:

registrar nova evidência;
invalidar ou colocar em revisão a Customer Need Truth anterior;
retornar ao gate apropriado;
reexecutar E3 somente após nova verdade suficiente.

Não remendar o fit sobre uma necessidade que mudou de identidade.

44. Edge Cases — Offer mudou durante E3

Se Offer Version, pricing boundary, capability, capacity, exclusion ou claim mudar materialmente:

preservar avaliação anterior;
registrar alteração;
fixar nova Offer Version/configuration;
reavaliar dimensões impactadas;
reemitir Proposal Readiness.

45. Edge Cases — cliente quer solução diferente da Need Truth

Registrar separadamente:

Customer Requested Solution;
Customer Need Truth;
motivo da divergência;
risco de solution forcing.

E3 pode avaliar a solução desejada como candidata, mas não deve presumir fit apenas porque foi solicitada.

46. Edge Cases — relacionamento forte, fit fraco

Resultado mínimo:

relacionamento permanece registrado como contexto;
fit técnico não é elevado artificialmente;
NO FIT continua permitido;
pode haver recomendação de terceiro/parceiro quando legítimo.

47. Edge Cases — fit forte, capacity insuficiente

E3 deve distinguir:

solução correta em tese;
indisponibilidade atual de entrega.

Possíveis saídas:

CONDITIONAL FIT com janela futura autorizada;
proposta com condição explícita, se política permitir;
NOT READY;
nova alternativa;
não vender naquele momento.

48. Edge Cases — preço fora do boundary

Não ajustar silenciosamente.

Fluxo:

Commercial Configuration
→ outside authorized boundary
→ REVIEW REQUIRED
→ Financial / Commercial Review
→ authorized exception OR rejected
→ new Proposal Readiness Decision

49. Edge Cases — desconto solicitado após Promise Alignment

Promise Alignment permanece válido enquanto a transformação pretendida não mudar.

A solicitação de desconto:

não altera Need Truth;
não altera Responsible Commercial Promise automaticamente;
pode alterar Commercial Configuration;
pode exigir revisão financeira/comercial;
pode inviabilizar Proposal Readiness.

50. Edge Cases — proposta exige parceiro

Antes de READY, confirmar:

parceiro elegível;
papel;
scope;
responsabilidade;
preço/custo quando aplicável;
data sharing;
compliance;
capacity;
claim permitido;
aprovação interna.

Caso contrário: REVIEW REQUIRED ou NOT READY.

51. Edge Cases — múltiplas ofertas com fit

E3 pode comparar mais de uma alternativa legítima.

Não deve escolher automaticamente apenas por:

maior preço;
maior margem inferida;
pacote mais amplo;
histórico de vendas;
popularidade;
similaridade superficial.

A comparação deve preservar:

need/outcome fit;
delivery fit;
customer prerequisites;
timing;
risks;
promise integrity;
boundaries;
decisão humana quando material.

52. Edge Cases — bundle ou solução em fases

Bundle ou phased solution devem ser tratados como configuração explícita.

Cada fase deve declarar:

qual parte da necessidade enfrenta;
resultado pretendido;
dependencies;
prerequisites;
promises;
boundaries;
preço/configuração quando aplicável;
decisão de continuidade quando existir.

Não usar faseamento para esconder PARTIAL FIT.

53. Edge Cases — nenhum preço definido

Se a oferta exige valor antes da proposta e não existe pricing/configuration suficiente:

fit técnico pode permanecer registrado;
Proposal Readiness = NOT READY ou REVIEW REQUIRED;
não inventar preço;
solicitar responsável adequado.

54. Edge Cases — oferta gratuita, piloto ou experimental

A ausência de preço não elimina governance.

Ainda registrar:

scope;
effort;
capacity;
duration;
conditions;
intended learning;
data use;
customer prerequisites;
exit conditions;
approval authority.

55. Responsible No-Sell

NO FIT é conhecimento comercial válido.

Registrar quando possível:

motivo;
dimensão impeditiva;
evidence;
anti-fit;
alternativa oferecida ou não;
possibilidade futura;
learning candidate.

Não transformar NO FIT em failure do seller por padrão.

56. Integração com E6 — Offer Reality Loop

Após proposta, decisão e eventual entrega, resultados devem retornar ao conhecimento.

flowchart LR
    P["Promise"] --> C["Contracted"]
    C --> D["Delivered"]
    D --> PE["Perceived"]
    PE --> R["Realized"]
    R --> L["Learning"]
    L --> E0["E0.SALES"]
    L --> F["Future E3"]

Learning pode:

fortalecer evidence;
limitar claim;
revisar prerequisite;
identificar anti-fit;
alterar Offer Readiness;
propor nova Offer Version;
melhorar futuras avaliações.

Nunca alterar retroativamente o que foi prometido em um caso anterior.

57. Dados e privacidade

E3 deve respeitar:

tenant isolation;
role-based access;
finalidade;
minimização;
classificação de dados;
retenção;
audit trail;
redaction de evidência quando necessário;
restrição de price, cost e margin por papel;
proteção de material comercial confidencial;
uso permitido de cases e evidence.

58. Regras imutáveis

Need antes de solution.
Need Pattern não prova fit.
Offer readiness não prova fit.
Relacionamento não compensa Need Fit.
Não existe score universal obrigatório.
Hard stop não pode ser compensado por média.
PARTIAL FIT não gera proposta diretamente.
NO FIT é decisão legítima.
E3 não cria escopo fora do Offer boundary silenciosamente.
Offer Change exige governança e nova versão quando material.
Responsible Commercial Promise deve ser rastreável.
Promise Alignment não é Proposal Acceptance.
Proposal Readiness deve anteceder geração governada de proposta.
Proposta não pode inventar preço, horas, scope ou claim.
Alteração material de Need ou Offer pode invalidar fit.
Toda decisão material deve retornar a versão e evidência.
IA auxilia; Human Review permanece proporcional ao risco.
Resultado de um caso não vira regra universal automaticamente.

59. Minimum Viable Responsible Solution Fit Slice

A fatia mínima funcional deve permitir que um caso real ou fictício percorra:

abrir Customer Need Truth válida;
carregar ao menos uma Offer Version elegível;
listar oferta candidata;
avaliar dimensões essenciais de fit;
registrar ao menos um hard stop/condition quando existir;
produzir Solution Fit Decision;
produzir Responsible Commercial Promise;
registrar Promise Alignment;
selecionar Commercial Configuration autorizada;
executar Proposal Readiness Gate;
gerar Proposal Ready Package;
gerar um draft de proposta derivado do pacote;
registrar Human Review quando obrigatório;
preservar versionamento e audit trail básicos;
impedir proposal generation quando gate não estiver READY ou autorizado por exceção explícita.

60. Critério de primeira prova funcional

Um cenário de teste deve demonstrar:

Need Isolated
→ Customer Need Truth
→ Candidate Offer
→ Responsible Fit Assessment
→ Responsible Commercial Promise
→ Promise Alignment
→ Commercial Configuration
→ Proposal Readiness = READY
→ Proposal Generated
→ E4 Handoff

E ao menos um cenário negativo:

Need Isolated
→ Candidate Offer
→ Hard Stop / NO FIT
→ No Proposal
→ Learning / Close

61. Critérios de aceite arquiteturais

62. Cenários de teste prioritários

Cenário A — Strong Fit + configuração autorizada

Esperado:

fit aprovado;
promise criada;
cliente alinhado;
pricing e scope dentro do boundary;
READY;
proposta gerada.

Cenário B — Need Fit falso

Esperado:

NO FIT;
nenhum draft comercial final gerado;
motivo rastreável.

Cenário C — Partial Fit

Esperado:

bloqueio de proposta;
alternativa em fases ou nova configuração;
reavaliação obrigatória.

Cenário D — Promise alinhada, desconto fora do limite

Esperado:

Promise Alignment permanece;
Commercial Configuration vai para revisão;
REVIEW REQUIRED;
nenhuma alteração silenciosa de preço.

Cenário E — Offer Version muda após fit

Esperado:

fit anterior preservado historicamente;
reavaliação das dimensões impactadas;
Proposal Readiness anterior invalidado quando material.

Cenário F — Need muda após alinhamento

Esperado:

Promise Alignment anterior não é reutilizado como verdade atual;
retorno ao ponto apropriado de E2/E3;
nova version/snapshot.

Cenário G — sem oferta candidata

Esperado:

NO CANDIDATE OFFER;
não inventar oferta;
permitir no-sell, partner route ou Offer Change Proposal governada.

Cenário H — preço inexistente

Esperado:

fit pode ser registrado;
Proposal Readiness não fica READY;
preço não é inferido pela IA.

63. Métricas candidatas

Ainda sem metas aprovadas:

tempo de Need Truth até Fit Decision;
candidatos por caso;
percentual de NO FIT;
percentual de MORE EVIDENCE REQUIRED;
fit por dimensão;
hard stops mais frequentes;
promises revisadas antes de alignment;
Proposal Readiness por estado;
exceções comerciais por tipo;
propostas geradas sem retrabalho de escopo;
diferença entre Offer Version e proposta;
claims bloqueados;
alterações de preço fora do boundary;
tempo de Promise Alignment até Proposal Generated;
proposals geradas e depois corrigidas por divergência de truth;
outcomes posteriores por fit state.

Nenhuma dessas métricas deve ser apresentada como benefício comprovado antes de evidência real.

64. Não objetivos do MVP E3

Não é objetivo imediato:

CPQ universal;
pricing optimization;
margem preditiva;
auto-negotiation;
dynamic discounting autônomo;
recommendation engine por ML;
ranking opaco de ofertas;
previsão de fechamento;
geração autônoma de contrato;
assinatura eletrônica nativa;
procurement completo;
marketplace de parceiros;
proposal design studio avançado;
personalização profunda por segmento;
causalidade automática entre solução e resultado.

65. Horizons

Horizon 1 — Minimum Viable E3

Customer Need Truth projection;
candidate eligibility;
core multidimensional fit;
hard stops;
Responsible Commercial Promise;
Promise Alignment;
Commercial Configuration mínima;
Proposal Readiness Gate;
Proposal Ready Package;
proposal draft governado;
Human Review básico;
versioning e audit trail.

Horizon 2 — Robustez

richer boundary rules;
comparação estruturada de múltiplas ofertas;
better specialist routing;
configuration variants;
proposal templates governados;
automated consistency checks;
richer value evidence;
partner governance.

Horizon 3 — Evidence-informed Intelligence

Somente após evidência suficiente:

outcome-informed recommendations;
pattern learning;
explicabilidade comparativa avançada;
probabilistic assistance governada;
recommendations baseadas em histórico interno validado;
economics intelligence avançada.

66. Impactos obrigatórios em outros documentos

66.1 E0.SALES

Atualizar para incorporar explicitamente:

Commercial Configuration;
packages/tiers quando aplicáveis;
effort basis e included hours quando aplicáveis;
pricing boundary;
discount boundary;
payment terms;
configuration boundary;
validity rules;
approval authority;
Proposal Readiness support;
handoff do Offer Context Package para E3.

66.2 Sales Intelligence Module

Atualizar E3 de Multidimensional Solution Fit para Responsible Solution Fit, preservando as nove dimensões já aprovadas e incorporando:

Customer Need Truth;
adversarial fit;
hard stops;
Responsible Commercial Promise;
Promise Alignment;
Commercial Configuration;
Proposal Readiness Gate;
Proposal Ready Package;
geração governada de proposta.

66.3 E4

E4 deve receber proposta ou Proposal Ready Package sem precisar reconstruir Need Truth, Offer Truth e pricing autorizado.

66.4 E6

Outcome e learning devem alimentar:

future fit;
Offer Reality Loop;
claims;
conditions;
anti-fit;
Offer Change Proposals;
future Need/Offer pattern learning.

67. Decisões técnicas ainda abertas

Estas lacunas não invalidam a arquitetura, mas exigem ADR/PRD antes de implementação definitiva:

representação física de ResponsibleCommercialPromise;
representação física de PromiseAlignment;
se CandidateOfferAssessment merece tabela própria;
canonical source do Commercial Configuration dentro do E0.SALES;
field-level access para price, cost e margin;
enums definitivos de pricing/economics status;
formato técnico do E3 Offer Context Package;
regras definitivas de invalidation por mudança de Need/Offer;
approval authority por exception type;
proposal template governance;
proposal versioning e relação com eventual contrato;
event schemas;
idempotência da geração de proposta;
optimistic locking em revisões concorrentes;
exact thresholds de materialidade para Human Review.

68. Truthmode e fronteira de evidência

68.1 Estruturado ou aprovado

E3 ocorre somente após necessidade suficientemente isolada e Opportunity Gate compatível;
fit multidimensional já fazia parte da arquitetura Sales;
as nove dimensões de fit permanecem;
não existe score universal obrigatório;
NO FIT, MORE EVIDENCE REQUIRED e specialist review são resultados legítimos;
E0.SALES estrutura Offer Truth, capabilities, evidence, conditions, exclusions e readiness;
a presente revisão aprova Customer Need Truth como projeção;
a presente revisão aprova fit adversarial e hard stops;
a presente revisão aprova Responsible Commercial Promise;
a presente revisão aprova Promise Alignment separado de Proposal Acceptance;
a presente revisão aprova Commercial Configuration como extensão necessária do E0.SALES;
a presente revisão aprova Proposal Readiness Gate;
a presente revisão aprova proposal generation por derivação governada.

68.2 Ainda não comprovado

qualidade do matching;
precisão do fit;
redução de propostas inadequadas;
redução de retrabalho comercial;
velocidade de geração de propostas;
melhoria de conversão;
melhoria de margem;
melhor experiência do seller;
melhor experiência do cliente;
redução de risco;
valor econômico do E3;
defensabilidade competitiva;
Product-Market Fit.

Não transformar arquitetura aprovada em benefício comprovado.

69. Síntese executiva

O E3 passa a operar como ponte governada:

CUSTOMER NEED TRUTH
        ↕
OFFER PASSPORT
        ↓
RESPONSIBLE SOLUTION FIT
        ↓
RESPONSIBLE COMMERCIAL PROMISE
        ↓
PROMISE ALIGNMENT
        ↓
COMMERCIAL CONFIGURATION
        ↓
PROPOSAL READINESS GATE
        ↓
READY
        ↓
PROPOSAL GENERATED
        ↓
E4 — DECISION & COMMUNICATION

A mudança fundamental é simples:

O vendedor não começa “fazendo uma proposta”. Ele conduz Discovery, chega a uma necessidade suficientemente verdadeira, testa essa verdade contra uma oferta suficientemente verdadeira, formula uma promessa responsável e, quando essa promessa é reconhecida e os parâmetros comerciais estão autorizados, o conhecimento estruturado produz a proposta.

Esse desenho preserva o princípio central do Orquestro:

transformar conhecimento empresarial disperso em decisões estruturadas, rastreáveis e executáveis.

70. Invariantes finais para implementação

NEED BEFORE SOLUTION
TRUTH BEFORE FIT
FIT BEFORE PROMISE
PROMISE BEFORE PROPOSAL
EVIDENCE BEFORE CLAIM
CAPABILITY BEFORE COMMITMENT
BOUNDARY BEFORE CUSTOMIZATION
ALIGNMENT BEFORE PROPOSAL GENERATION
READINESS BEFORE PROPOSAL
HUMAN REVIEW WHEN MATERIAL
VERSION BEFORE REUSE
OUTCOME BEFORE GENERALIZATION

Fim do documento.

E4 — Decision & Communication v0.1

Fonte incorporada integralmente: Orquestro_E4_Decision_Communication_v0.1_2026-08-22.md

Orquestro E4 — Decision & Communication

Definição funcional: Decision Communication Intelligence, Protected Proposal, Human Presentation & Responsible Influence
Versão: 0.1
Data: 22/08/2026
Status: baseline arquitetural aprovada pelas Founders para especificação e desenvolvimento incremental
Classificação: etapa especializada do Orquestro™
Escopo do documento: arquitetura funcional, comunicação decisória, proteção de conhecimento, proposta, apresentação, comportamento observável, influência ética, experiência, dados, governança e Minimum Viable Decision & Communication Slice
Dependências obrigatórias: E0.CORE — Organizational Context & Implementation Intelligence, E0.SALES — Offer Intelligence & Commercial Readiness, E1 Lead Intelligence, E2 Human Discovery, E3 Responsible Solution Fit, Decision Unit, Customer Need Truth, Offer Passport, Responsible Commercial Promise, Commercial Configuration e Proposal Ready Package
Próxima etapa: E5 — Decision Conversation
Fonte metodológica aplicada: PRODUCT_PROMPT.md — Product Markdown Rail

Aviso de maturidade: este documento define a arquitetura pretendida e decisões aprovadas para o E4. Não comprova que geração de proposta, Decision Communication Profile, adaptação de apresentação, classificação de disclosure, Behavioral Communication Intelligence, mecanismos de IA, gates, integrações ou qualquer efeito sobre conversão comercial estejam implementados, validados ou prontos para produção.

1. Finalidade do documento

Este documento especifica o E4 — Decision & Communication, etapa responsável por transformar uma solução já considerada responsável e comercialmente pronta em uma decisão que o cliente consiga compreender, avaliar, discutir e tomar livremente, preservando a propriedade intelectual da organização vendedora e adaptando a comunicação à forma de decidir demonstrada pelos atores daquele caso.

O E4 deve orientar:

produto;
arquitetura de conhecimento;
Commercial Decision Engine™;
geração governada de proposta;
proteção de know-how;
arquitetura da apresentação comercial;
personalização por comportamento e critérios observados;
Decision Unit Intelligence;
Human Review;
influência ética;
comunicação verbal e material;
versionamento de proposta;
apresentação obrigatória antes do envio;
captura do que o cliente diz durante a apresentação;
detecção de mudança material;
handoff para E5;
rastreabilidade entre necessidade, solução, promessa, comunicação e decisão;
testes e pilotos.

2. Decisão arquitetural aprovada

Decisão:

E4 não cria a solução e não ensina o HOW proprietário. E4 recebe do E3 uma decisão comercial responsável e pronta, protege o conhecimento estrutural da organização vendedora, organiza proposta e apresentação para o decisor real daquele caso, conduz a primeira apresentação de forma human-first e somente depois autoriza o envio da proposta.

Decisões complementares aprovadas:

a proposta é derivada do Proposal Ready Package, não redigida livremente do zero;
a proposta deve mostrar WHAT, WHY, VALUE, SCOPE e CONDITIONS em nível suficiente para decisão e contratação;
o HOW proprietário permanece protegido;
a quantidade de informação revelada deve obedecer a um Knowledge Disclosure Boundary;
a primeira experiência do cliente com a proposta deve ocorrer em apresentação humana, e não por recebimento isolado do arquivo;
no fluxo v0.1, SENT exige PRESENTED; não existe bypass silencioso;
a apresentação é construída para a Decision Unit, especialmente para os atores com autoridade e influência relevantes;
comunicação pode mudar sequência, ênfase, profundidade, formato, ritmo e densidade conforme evidências comportamentais do caso;
a verdade comercial não muda para se adaptar ao perfil;
Decision Communication Profile deve ser baseado principalmente em comportamento observável, perguntas, critérios, histórico de interação e preferências expressas;
estilos como Analytical, Driving, Amiable e Expressive podem funcionar como lentes assistivas, nunca como diagnóstico psicológico, rótulo rígido ou verdade sobre personalidade;
gênero, rótulo geracional e outros atributos demográficos não podem ser usados para inferir vulnerabilidades, preferências decisórias ou técnicas de convencimento;
segurança, conforto, reputação, evidência, velocidade, relacionamento ou qualquer outra preferência só podem orientar personalização quando houver evidência observada, declaração explícita ou contexto decisório legítimo;
métodos de storytelling, design comportamental e persuasão podem ser usados somente como camadas de comunicação responsável, nunca para criar falsa urgência, falsa escassez, pressão ou ocultação material;
a apresentação deve gerar novos dados: dúvidas, objeções, preocupações, reconhecimento, mudança de necessidade e condições;
mudança material detectada durante apresentação não pode ser absorvida silenciosamente na proposta;
quando necessário, o caso retorna a E2, E3 ou E0.SALES;
E4 termina com proposta apresentada, versão autorizada enviada e Decision Ready Package entregue ao E5.

3. Tese central

Uma proposta comercial não deve ser um manual de execução nem um documento criado para pressionar. Deve ser a manifestação clara, suficiente e protegida de uma decisão construída sobre necessidade, fit, capacidade, condições e promessa responsável.

Princípios comerciais aprovados pelas Founders:

Quem isola, vende.
Quem compreende e isola a necessidade antes da solução conquista legitimidade para recomendar.

Quem ouve, vende melhor.
Quanto mais a comunicação nasce do que o cliente realmente demonstrou valorizar, perguntar, temer, precisar compreender e precisar decidir, menor a necessidade de pressão comercial.

O E4 não deve otimizar convencimento a qualquer custo.

Deve otimizar:

compreensão;
relevância;
confiança legítima;
segurança decisória;
clareza de valor;
proteção de propriedade intelectual;
adequação da comunicação;
autonomia do cliente;
rastreabilidade.

4. Posição na jornada comercial

flowchart TB
    E3["E3\nResponsible Solution Fit"]
    PRP["Proposal Ready Package"]
    DCI["E4.1\nDecision Communication Intelligence"]
    PA["E4.2\nProposal Architecture"]
    PRA["E4.3\nPresentation Architecture"]
    HP["E4.4\nHuman Presentation & Listening"]
    SG{"Send Authorization Gate"}
    SEND["E4.5\nProposal Release"]
    DRP["Decision Ready Package"]
    E5["E5\nDecision Conversation"]

    E3 --> PRP --> DCI --> PA --> PRA --> HP --> SG
    SG -->|AUTHORIZED| SEND --> DRP --> E5
    SG -->|MATERIAL CHANGE| E3

Retornos possíveis durante E4:

necessidade mudou materialmente → E2;
fit ou solução mudou materialmente → E3;
configuração comercial excedeu boundary → E0.SALES / Human Review;
apenas forma de comunicação mudou → permanece em E4;
nenhuma mudança material → autorizar envio e avançar para E5.

5. Fronteira entre E3, E4 e E5

Etapa	Pergunta central	Saída principal
E3	o que podemos responsavelmente oferecer neste caso?	`Proposal Ready Package`
E4	como proteger, estruturar, apresentar e comunicar essa decisão para os atores certos?	proposta apresentada e enviada + `Decision Ready Package`
E5	como apoiar a conversa decisória após apresentação, incluindo objeções, negociação e compromissos?	decisão, compromisso, revisão ou próximo passo

Regra:

E4 prepara e realiza a primeira apresentação formal da proposta. E5 assume o ciclo decisório subsequente.

Isso evita que E4 e E5 dupliquem a mesma conversa.

6. Entradas obrigatórias do E4

E4 deve consumir, quando aplicável:

Customer Need Truth snapshot;
Need Instance;
Decision Unit;
Decision Context;
SolutionFitAssessment;
Fit Decision;
Fit Conditions;
Selected Offer;
Offer Version;
Offer Passport snapshot;
Responsible Commercial Promise;
Promise Alignment;
selected components;
included scope;
excluded scope;
customer prerequisites;
seller constraints;
Commercial Configuration;
price;
effort / hours quando autorizado;
package;
timeline;
payment terms;
validity;
commercial conditions;
allowed claims;
unsupported or prohibited claims;
risks;
dependencies;
evidence links;
Proposal Readiness = READY;
histórico de interações relevantes;
comunicação e comportamento observável dos atores.

E4 não deve exigir que o seller recadastre manualmente informações já aprovadas em E3 ou E0.SALES.

7. O que o E4 não é

E4 não é:

gerador genérico de PDFs;
ferramenta de copywriting sem governança;
CRM completo;
CPQ completo;
engine de manipulação;
perfil psicológico de comprador;
sistema de discriminação por gênero, idade ou geração;
script rígido de apresentação;
mecanismo para criar urgência falsa;
biblioteca de truques de fechamento;
substituto da relação humana;
autorização para mostrar propriedade intelectual;
autorização para inventar case, prova, autoridade ou escassez;
autorização para alterar preço ou escopo fora de boundary;
garantia de conversão.

8. Princípios operacionais

Need truth before message — a narrativa deriva da necessidade, não da vontade de vender.
Fit before proposal — E4 só recebe proposta pronta após E3.
Protect the HOW — decisão comercial não exige revelar o método proprietário.
Enough to decide, not enough to copy — proposta deve ser suficiente para decisão e contratação, sem ensinar execução.
Presentation before send — no v0.1, proposta é apresentada antes de ser enviada.
Listen before persuade — apresentação é também instrumento de escuta.
Observed behavior before labels — evidência comportamental prevalece sobre tipologias.
Adapt emphasis, never truth — personalização muda forma, não conteúdo material.
No demographic shortcuts — gênero e geração não viram atalhos de persuasão.
Audience as decision protagonist — comunicação começa pela realidade do cliente.
Ethical influence only — influência deve preservar autonomia e factualidade.
No silent material change — mudança relevante reabre o gate adequado.
One truth, many expressions — proposta, apresentação, e-mail e resumo devem derivar da mesma verdade governada.
Evidence on demand — detalhe adicional deve estar disponível sem poluir a comunicação principal.
Human Review for material communication — proposta externa e claims materiais exigem revisão proporcional.
Temporal validity — proposta e perfil decisório podem envelhecer e precisam de revalidação.

9. Arquitetura funcional do E4

E4 é dividido em cinco subetapas:

E4.1 — Decision Communication Intelligence;
E4.2 — Proposal Architecture & Knowledge Disclosure;
E4.3 — Presentation Architecture;
E4.4 — Human Presentation & Listening;
E4.5 — Proposal Release & E5 Handoff.

flowchart LR
    A["Proposal Ready Package"] --> B["Decision Communication Intelligence"]
    B --> C["Protected Proposal"]
    C --> D["Presentation Architecture"]
    D --> E["Human Presentation"]
    E --> F{"Material Change?"}
    F -->|NO| G["Send Authorization"]
    F -->|YES| H["Return to E2/E3/E0"]
    G --> I["Proposal Sent"]
    I --> J["Decision Ready Package"]

E4.1 — Decision Communication Intelligence

10. Objetivo

Compreender como os atores relevantes daquele caso demonstram decidir, avaliar risco, consumir informação e construir confiança, utilizando somente evidência legítima e temporal.

E4.1 não pergunta:

“Que tipo de pessoa é esse cliente?”

Pergunta:

“O que esse ator demonstrou precisar para compreender e tomar esta decisão?”

11. Decision Communication Profile

Decision Communication Profile é uma projeção assistiva e versionada, derivada do comportamento e contexto do ator naquele caso.

Não deve ser tratado como:

diagnóstico psicológico;
traço permanente;
rótulo universal;
justificativa para pressão;
inferência de vulnerabilidade.

Pode reunir:

Decision Communication Profile
 
Actor
Decision Role
Observed Decision Pace
Detail Appetite
Evidence Appetite
Risk Sensitivity
Strategic vs Operational Orientation
Visual vs Textual Preference
Relationship Orientation
Need for Consensus
Decision Autonomy
Preferred Communication Channel
Known Decision Criteria
Known Concerns
Known Trust Signals
Known Reputation Signals
Known Comfort / Safety Signals
Typical Questions
Communication Watch-outs
Evidence Links
Confidence
Last Observed
Validity

12. Hierarquia de evidência do perfil de comunicação

Ordem preferencial:

declaração explícita do próprio ator;
comportamento observado em interações atuais;
perguntas e critérios repetidamente utilizados;
decisões anteriores documentadas no mesmo contexto;
observação do seller com evidência suficiente;
hipótese assistida pela IA, sempre marcada como hipótese;
lente tipológica auxiliar.

Regra:

Tipologia nunca pode superar evidência direta.

13. Behavioral Communication Evidence

Exemplos de sinais legítimos:

solicita dados antes de discutir solução;
pede resumo executivo antes de detalhes;
retorna repetidamente a risco de implantação;
solicita referências e cases;
demonstra preferência por visão de futuro;
pergunta primeiro investimento e prazo;
precisa consultar outros atores;
verbaliza desconforto com incerteza;
prefere documento curto;
pede memória de cálculo;
valoriza reputação e credibilidade;
tende a decidir após reflexão;
tende a decidir em reunião;
solicita comparações;
pergunta sobre impacto nas pessoas;
reage negativamente a excesso de detalhes;
pede espaço para perguntas antes de conclusão.

Cada sinal material deve registrar:

fonte;
data;
contexto;
ator;
nível de confiança;
interpretação separada da observação.

O Orquestro pode utilizar, como lente assistiva, quatro padrões comportamentais amplamente difundidos no modelo SOCIAL STYLE:

ANALYTICAL;
DRIVING;
AMIABLE;
EXPRESSIVE.

Regra metodológica:

O estilo descreve um padrão comportamental percebido; não define inteligência, motivação, caráter, profissão ou personalidade completa.

O sistema deve manter a evidência subjacente, mesmo quando apresentar um estilo resumido ao seller.

14.1 Analytical / Analisador

Sinais possíveis:

busca consistência;
solicita evidência;
avalia premissas;
prefere tempo para analisar;
tende a reduzir incerteza antes da decisão.

Adaptação possível:

estrutura lógica;
mais evidência disponível;
premissas explícitas;
riscos e limites claros;
tempo para perguntas e análise;
evitar pressão por decisão imediata.

14.2 Driving / Diretor

Sinais possíveis:

foco em resultado;
comunicação direta;
ritmo rápido;
baixa tolerância a rodeios;
interesse em impacto, prazo e decisão.

Adaptação possível:

conclusão cedo;
poucos slides;
impacto e decisão visíveis;
investimento e prazo claros;
opções objetivas;
detalhe disponível sob demanda.

14.3 Amiable / Relacional

Sinais possíveis:

busca confiança;
interesse no efeito sobre pessoas;
preferência por segurança de implementação;
maior atenção a harmonia e suporte;
pode não verbalizar discordância imediatamente.

Adaptação possível:

deixar papéis e suporte claros;
explicitar mudança de forma segura;
criar espaço real para discordância;
perguntar diretamente por preocupações;
não confundir cordialidade com aceite.

14.4 Expressive / Visionário

Sinais possíveis:

energia alta;
visão de futuro;
pensamento por possibilidades;
preferência por síntese e narrativa;
discussão mais aberta de ideias.

Adaptação possível:

mostrar futuro desejado;
usar narrativa e elementos visuais;
conectar solução a transformação;
preservar foco e decisão;
deixar detalhe técnico acessível sem sobrecarregar a apresentação.

15. Regra anti-caixa

Não é permitido concluir:

Actor = ANALYTICAL
therefore
Actor always decides slowly

É permitido:

Observed Evidence:
- pediu evidências em 3 interações;
- solicitou tempo para revisar;
- pediu comparação de riscos.
 
Assistive Lens:
ANALYTICAL-like communication preference
Confidence: MEDIUM

16. Decision Unit e múltiplos perfis

Uma oportunidade pode envolver:

Economic Approver;
Decision Owner;
Technical Evaluator;
Sponsor;
User;
Influencer;
Blocker;
Resource Owner;
Implementation Owner.

A apresentação não deve assumir um único perfil quando múltiplos atores participam.

O sistema deve priorizar:

autoridade sobre a decisão;
importância do critério daquele ator;
necessidade de compreensão coletiva;
conflito entre critérios;
informações que precisam ser comuns a todos;
detalhes que podem ser oferecidos sob demanda.

17. Demographic Safeguard

17.1 Gênero

Gênero não pode ser usado para inferir:

aversão a risco;
emotividade;
necessidade de acolhimento;
preferência por reputação;
sensibilidade a autoridade;
ritmo decisório;
estilo de persuasão;
vulnerabilidade.

Pode ser considerado somente quando necessário para:

linguagem respeitosa;
pronomes, se informados e pertinentes;
representação apropriada;
experiência e acessibilidade;
contexto que o próprio ator tenha explicitamente trazido.

17.2 Geração

Rótulos como Baby Boomer, Gen X, Millennial ou Gen Z não podem funcionar como regra de comunicação.

O sistema deve preferir:

preferências expressas;
contexto de carreira;
experiência;
familiaridade tecnológica observada;
canal preferido;
comportamento decisório atual;
estágio de vida apenas quando material e legitimamente conhecido.

17.3 Regra geral

Personalizar a partir do indivíduo observado, não do grupo presumido.

18. Confidence e validade temporal

Cada Decision Communication Profile deve poder receber:

LOW CONFIDENCE;
MEDIUM CONFIDENCE;
HIGH CONFIDENCE.

Perfil com baixa confiança:

não pode automatizar sequência rígida;
deve apresentar recomendações como sugestões;
deve incentivar seller a observar e perguntar.

Mudança de contexto, papel ou Decision Unit pode invalidar o perfil anterior.

E4.2 — Proposal Architecture & Knowledge Disclosure

19. Objetivo

Produzir uma proposta que seja:

suficiente para compreensão;
suficiente para comparação legítima;
suficiente para contratação;
coerente com o E3;
comercialmente clara;
protegida contra transferência indevida do know-how estrutural.

20. Knowledge Disclosure Boundary

O E4 deve classificar o conhecimento em três camadas.

20.1 `PROPOSAL_SAFE`

Pode constar na proposta enviada:

contexto resumido;
problema / necessidade compreendida;
objetivo;
transformação pretendida;
escopo macro;
frentes de atuação;
entregáveis;
responsabilidades;
premissas;
condições;
prazo;
investimento;
limites;
exclusões;
critérios de início / aceite quando necessários.

20.2 `PRESENTATION_ONLY`

Pode ser explicado verbalmente e exibido em apresentação controlada quando necessário à decisão:

racional aprofundado da recomendação;
leitura integrada do cenário;
interpretação dos principais riscos;
lógica de valor;
exemplos selecionados;
por que determinada configuração foi escolhida;
nuances que ajudam a compreender a proposta;
comparação entre alternativas legítimas.

Não deve ser automaticamente incorporado ao arquivo enviado.

20.3 `PROTECTED_KNOW_HOW`

Não deve ser entregue na proposta nem revelado de forma suficiente para permitir reprodução independente:

frameworks proprietários detalhados;
sequência metodológica interna;
prompts;
pesos;
regras da Engine;
critérios proprietários;
templates operacionais internos;
roteiros de oficina;
questionários proprietários completos;
instrumentos de diagnóstico;
playbooks;
lógica de análise;
cálculos internos não necessários à decisão;
arquitetura de conhecimento;
mecanismos de produção do entregável;
SOPs de delivery;
know-how que constitua vantagem competitiva.

21. Regra WHAT / HOW

A proposta deve responder:

WHAT: o que será entregue;
WHY: por que faz sentido diante da necessidade;
VALUE: que transformação pretende apoiar;
SCOPE: onde começa e termina;
CONDITIONS: o que precisa ser verdade para entrega.

A proposta não deve responder em nível copiável:

HOW: exatamente como a organização produz aquela transformação.

Regra:

Enough to decide, not enough to replicate.

22. Proteção contra proposta vaga

Proteger o HOW não autoriza proposta genérica.

A proposta deve deixar claro, no mínimo:

objeto contratado;
fronteira de escopo;
principais entregáveis;
duração ou lógica temporal quando aplicável;
responsabilidades das partes;
investimento;
condições comerciais;
exclusões materiais;
critérios relevantes para início ou continuidade.

Exemplo inadequado:

“Consultoria estratégica completa conforme necessidade.”

Exemplo melhor:

“Estruturação do modelo de governança e responsabilidades, com definição dos mecanismos necessários à sustentação do modelo, dentro das frentes e entregáveis descritos nesta proposta.”

A segunda versão informa o objeto sem revelar o método operacional.

23. Proposal Assembly por derivação

Fluxo:

Proposal Ready Package
→ semantic mapping
→ disclosure classification
→ proposal template
→ proposal draft
→ consistency check
→ Human Review
→ Presentation Ready

A IA não deve receber apenas:

“faça uma proposta para o cliente X”.

Deve receber objetos governados e regras de disclosure.

24. Estrutura semântica mínima da proposta

Uma proposta pode variar visualmente por tenant, mas deve poder derivar os seguintes blocos:

identificação e contexto;
entendimento resumido da necessidade;
objetivo / transformação pretendida;
solução recomendada em nível macro;
Responsible Commercial Promise em linguagem apropriada;
escopo;
entregáveis;
limites e exclusões;
responsabilidades do cliente;
responsabilidades da organização vendedora;
cronograma ou duração;
investimento;
condições comerciais;
validade;
próximos passos.

A ordem pode variar conforme Decision Communication Profile, desde que o conteúdo material permaneça.

25. Claim Integrity da proposta

Toda afirmação material deve poder retornar a:

Proposal Claim
→ Responsible Commercial Promise
→ Offer Promise / Offer Claim
→ Capability
→ Evidence
→ Conditions / Limitations

Se não houver rastreabilidade suficiente:

remover claim;
limitar claim;
solicitar Human Review;
retornar ao E3 quando material.

26. Proibição de melhoria retórica da promessa

Exemplo:

Promise aprovada:

“Estruturar responsabilidades e mecanismos de decisão para reduzir a dependência operacional identificada.”

A proposta não pode elevar para:

“Garantir autonomia completa e aumento de produtividade.”

A redação comercial pode ser mais clara e elegante, mas não pode aumentar causalidade, certeza ou alcance.

27. Proposal Versioning

Toda versão deve registrar:

proposal_id;
proposal_version_id;
tenant;
opportunity / case;
generated_at;
Need Truth snapshot;
Offer Version;
Solution Fit Assessment;
Responsible Commercial Promise version;
Commercial Configuration version;
Decision Communication Profile snapshot;
template version;
disclosure policy version;
price;
scope;
conditions;
validity;
generated_by;
reviewed_by;
approved_by;
presentation session vinculada;
sent_at;
superseded_by.

Nunca sobrescrever silenciosamente uma versão enviada ou apresentada.

28. Lifecycle da proposta

Estados mínimos:

DRAFT
→ READY_FOR_REVIEW
→ INTERNAL_REVIEWED
→ PRESENTATION_READY
→ PRESENTED
→ SEND_AUTHORIZED
→ SENT

Estados terminais ou laterais:

SUPERSEDED;
WITHDRAWN;
EXPIRED.

Invariante v0.1:

SENT exige PRESENTED e SEND_AUTHORIZED.

29. Proposal Internal Review Gate

Antes de PRESENTATION_READY, verificar:

Need Truth válida;
Offer Version válida;
Fit válido;
Promise não ampliada;
escopo autorizado;
preço autorizado;
claims autorizados;
conditions presentes;
exclusions materiais presentes;
disclosure adequado;
nenhum Protected Know-How incorporado indevidamente;
nenhuma mudança material não revisada.

Resultados:

PRESENTATION_READY;
REVIEW_REQUIRED;
RETURN_TO_E3;
RETURN_TO_E2.

E4.3 — Presentation Architecture

30. Objetivo

Construir uma apresentação que coloque o cliente e sua decisão no centro, utilizando a verdade do caso, o Decision Communication Profile e metodologias de comunicação de forma responsável.

A apresentação não deve ser uma simples leitura da proposta.

Ela deve:

enquadrar a decisão;
tornar a necessidade reconhecível;
mostrar o futuro desejado;
explicar a recomendação sem entregar o HOW;
dar segurança suficiente;
permitir objeção e dúvida;
preparar o cliente para decidir.

31. Audience-as-Decision-Protagonist

A apresentação deve priorizar:

realidade do cliente;
consequência / impacto;
futuro desejado;
decisão a ser tomada;
solução recomendada;
racional necessário;
condições;
investimento;
próximos passos.

Evitar abertura excessivamente centrada em:

história da empresa vendedora;
currículos longos;
lista de serviços;
autopromoção genérica.

Reputação e autoridade devem aparecer quando forem relevantes ao critério de decisão.

32. Estrutura `WHAT IS ↔ WHAT COULD BE`

Como lente narrativa, o E4 pode utilizar contraste entre:

WHAT IS
Customer Need Truth
Current Reality
Impact
 
↕ tension / decision gap
 
WHAT COULD BE
Desired Future
Responsible Commercial Promise

A solução aparece como ponte responsável, não como protagonista.

33. Proposal Imagineering Loop

O E4 pode usar internamente uma adaptação do ciclo Dreamer → Realist → Critic para estruturar proposta e apresentação.

33.1 DREAMER — Transformation Narrative

Perguntas:

que futuro o cliente está tentando construir?;
que mudança reconhecida importa?;
qual transformação precisa ficar clara?;
o que o cliente deveria conseguir enxergar depois da apresentação?

33.2 REALIST — Decision Architecture

Perguntas:

que evidência precisa aparecer?;
que informações são necessárias para decisão?;
quais condições são materiais?;
que investimento, prazo e responsabilidades precisam estar claros?;
quem precisa decidir?

33.3 CRITIC — Decision Stress Test

Perguntas:

onde pode surgir desconfiança?;
o que parece exagerado?;
o que está vago?;
o que entrega HOW demais?;
que objeção legítima não foi considerada?;
que claim não está sustentado?;
o cliente conseguiria explicar essa decisão a outro decisor?

O ciclo pode repetir até convergir.

Não tratar o método como prova de aumento de conversão.

34. Ethical Influence Layer

O E4 pode utilizar princípios de influência somente quando factualmente verdadeiros e compatíveis com autonomia do cliente.

34.1 Authority

Permitido:

credenciais reais;
certificações reais;
experiência documentada;
evidência de competência.

Proibido:

autoridade fabricada;
exagero de experiência;
logos sem autorização;
associação enganosa.

Permitido:

case real;
referência comparável;
dado com fonte;
depoimento autorizado.

Proibido:

case inventado;
número sem base;
generalização indevida de um caso;
cliente semelhante apenas por estereótipo.

34.3 Consistency

Permitido:

conectar proposta a prioridades que o próprio cliente validou;
lembrar critérios explicitamente declarados.

Proibido:

usar fala antiga fora de contexto para constranger;
transformar compromisso exploratório em obrigação.

34.4 Reciprocity

Permitido:

insight genuíno;
síntese útil;
devolutiva real de Discovery.

Proibido:

presente ou favor usado para criar obrigação imprópria;
dar algo para pressionar aceitação.

34.5 Scarcity

Permitido somente se existir de fato:

capacidade limitada;
agenda limitada;
condição com prazo real;
disponibilidade real.

Proibido:

falsa escassez;
“última vaga” inventada;
prazo artificial;
ameaça de perda inexistente.

34.6 Liking / Rapport

Permitido:

cordialidade;
empatia;
interesses reais em comum;
cooperação.

Proibido:

mimetização manipulativa;
elogio falso;
afinidade inventada.

34.7 Unity

Permitido:

propósito, identidade ou valores realmente compartilhados.

Proibido:

fabricar pertencimento;
explorar identidade sensível.

35. EAST como Decision UX

O E4 pode usar o framework EAST como lente de experiência da decisão.

EASY

mensagem simples;
decisão explícita;
reduzir ruído;
evitar jargão desnecessário;
próximos passos claros.

ATTRACTIVE

hierarquia visual;
destaque para o que importa;
design coerente;
saliência sem sensacionalismo.

referências legítimas;
prova social comparável quando realmente útil;
nunca inventar norma social.

TIMELY

apresentar quando contexto e atores estiverem adequados;
fazer Decision Ask no momento correto;
não acelerar artificialmente decisão imatura.

36. Sequência sugerida por padrão comportamental

Estas sequências são assistivas, não obrigatórias.

36.1 Analytical

Evidence
→ Current Reality
→ Criteria
→ Risks / Conditions
→ Recommendation
→ Scope
→ Investment
→ Decision / Time to Review

36.2 Driving

Bottom Line
→ Business Impact
→ Recommendation
→ Scope
→ Investment / Timeline
→ Key Risk
→ Decision Ask

36.3 Amiable

Shared Reality
→ People / Organizational Impact
→ Desired Future
→ Safety of Implementation
→ Support / Responsibilities
→ Recommendation
→ Investment
→ Space for Concerns

36.4 Expressive

Desired Future
→ Gap
→ Transformation Narrative
→ Recommendation
→ Evidence / Proof
→ Scope
→ Investment
→ Decision Ask

Regra:

A apresentação não precisa se limitar a um estilo quando Decision Unit for heterogênea.

37. Matriz de adaptação da apresentação

Dimensão	Analytical	Driving	Amiable	Expressive
Abertura	evidência/contexto	conclusão/impacto	realidade compartilhada	futuro/visão
Ritmo	moderado	rápido	moderado	dinâmico
Detalhe	alto disponível	baixo na superfície	suficiente para segurança	síntese primeiro
Risco	explícito	crítico apenas	segurança e suporte	contextualizado
Visual	estruturado	enxuto	claro e humano	narrativo
Perguntas	tempo para pensar	diretas	abertas e seguras	exploratórias
Decision Ask	sem pressão	objetivo	confirmar conforto/consenso	conectar a visão à ação

Essa matriz não deve ser usada sem evidência comportamental.

38. Reputação, segurança e confiança

O sistema pode recomendar sinais como:

credenciais;
cases;
governança;
metodologia em nível não proprietário;
referências;
garantias contratuais permitidas;
papéis e responsabilidades;
controles de risco;
experiência da equipe.

Somente quando:

forem verdadeiros;
forem relevantes para o ator;
não excederem disclosure autorizado.

Reputação não deve ser inflada para compensar baixo fit.

39. Presentation Plan

Presentation Plan é uma projeção de execução e pode conter:

Presentation Plan
 
Case
Decision Unit
Primary Decision Actors
Communication Profile Snapshot
Meeting Objective
Decision Ask
Narrative Order
Key Evidence
Key Risks
Claims Allowed
Claims To Avoid
Presentation-only Explanations
Protected Know-how Watch-outs
Questions to Ask
Signals to Listen For
Expected Concerns
Timebox
Presentation Owner
Reviewer

E4.4 — Human Presentation & Listening

40. Objetivo

Realizar a primeira apresentação formal da proposta como conversa humana de decisão, não como reprodução automática de slides.

Princípio:

O Orquestro prepara a comunicação. A pessoa conduz a conversa.

41. Invariante Presentation Before Send

No v0.1:

PRESENTATION_READY
→ HUMAN PRESENTATION
→ PRESENTED
→ SEND AUTHORIZATION
→ SENT

Não é permitido:

PRESENTATION_READY
→ SENT

sem mudança formal da arquitetura aprovada.

Se um futuro contexto de procurement exigir exceção, deve haver ADR específica; não criar bypass implícito.

42. Objetivos da apresentação

A apresentação deve permitir verificar:

o cliente reconhece a realidade sintetizada?;
a necessidade permanece verdadeira?;
o futuro desejado permanece válido?;
a proposta foi compreendida?;
a Responsible Commercial Promise foi interpretada corretamente?;
o escopo está claro?;
condições e limitações estão claras?;
novas objeções ou gaps apareceram?;
a Decision Unit presente é suficiente?;
existe mudança material?;
o próximo passo está claro?

43. Listen-First Protocol

Durante apresentação, o seller deve ser apoiado a:

observar perguntas;
permitir silêncio;
pedir feedback;
esclarecer sem defender automaticamente;
distinguir objeção de dúvida;
distinguir cordialidade de concordância;
registrar linguagem do cliente;
verificar entendimento;
capturar novo gap;
reconhecer quando não sabe;
evitar pressionar resposta.

O Orquestro deve incentivar perguntas como:

“O que aqui representa melhor o cenário de vocês?”;
“O que não representa?”;
“Qual ponto gera mais dúvida ou risco para vocês?”;
“Existe algo material que mudou desde nossa última conversa?”;
“Quem mais precisa compreender ou participar desta decisão?”

Essas perguntas são exemplos de interação, não scripts obrigatórios.

44. Presentation Intelligence

Após ou durante a apresentação, registrar:

Presentation Intelligence
 
Presentation Session
Attendees
Decision Roles
Questions Asked
Concerns
Objections
New Evidence
Customer Statements
Recognition Signals
Misunderstandings
Decision Criteria Confirmed
Decision Criteria Changed
Scope Questions
Price Questions
Timeline Questions
Implementation Concerns
Trust / Reputation Questions
New Gaps
Material Change Assessment
Next Step

Separar sempre:

Customer Statement;
Seller Observation;
Engine Hypothesis;
Gap.

45. Objection ≠ manipulation opportunity

E4 não deve transformar objeções automaticamente em técnicas para vencer resistência.

Classificar, por exemplo:

misunderstanding;
missing evidence;
legitimate risk;
pricing constraint;
resource constraint;
trust concern;
scope mismatch;
internal alignment issue;
timing issue;
no fit signal;
unknown.

A resposta pode ser:

esclarecer;
mostrar evidência;
reconhecer limitação;
investigar;
revisar;
retornar a E2/E3;
não avançar.

46. Material Change Classifier

Após a apresentação, mudanças devem ser classificadas.

46.1 Need Change

Exemplo:

“Na verdade, o problema principal agora não é governança; é liquidez.”

Ação:

bloquear envio;
retornar a E2;
revalidar Need Truth.

46.2 Solution / Fit Change

Exemplo:

“Queremos que vocês assumam também a operação financeira.”

Ação:

bloquear envio;
retornar a E3;
avaliar nova solução / boundary.

46.3 Commercial Configuration Change dentro do boundary

Exemplo:

mudança permitida de forma de pagamento.

Ação:

permanecer em E4;
gerar nova Proposal Version;
revisar.

46.4 Commercial Configuration fora do boundary

Exemplo:

desconto acima da autoridade do seller.

Ação:

Human Review / E0.SALES;
não enviar até aprovação.

46.5 Communication-only Change

Exemplo:

decisor solicita resumo de uma página.

Ação:

permanecer em E4;
adaptar artefato sem alterar verdade material.

47. Human Presentation Record

Registrar no mínimo:

data;
canal;
participantes;
presenter;
Proposal Version apresentada;
Presentation Plan version;
duração quando disponível;
reconhecimento da necessidade;
principais dúvidas;
principais objeções;
mudança material;
resultado;
next step;
revisão humana.

E4.5 — Proposal Release & E5 Handoff

48. Send Authorization Gate

Uma proposta somente recebe SEND_AUTHORIZED quando:

Proposal Version foi apresentada;
Presentation Session foi registrada;
não existe material change não resolvida;
Need Truth continua válida;
Offer Version continua válida;
Solution Fit continua válido;
Responsible Commercial Promise continua válida;
escopo continua autorizado;
pricing continua autorizado;
claims continuam autorizados;
Knowledge Disclosure Boundary foi respeitado;
Human Review necessário foi concluído.

Resultados:

SEND_AUTHORIZED;
REVISION_REQUIRED;
RETURN_TO_E2;
RETURN_TO_E3;
COMMERCIAL_REVIEW_REQUIRED;
WITHDRAW.

49. Envio da proposta

Após autorização:

congelar Proposal Version enviada;
registrar destinatários;
registrar canal;
registrar sent_at;
vincular à Presentation Session;
registrar próxima decisão / compromisso;
criar Decision Ready Package;
avançar para E5.

A versão enviada nunca deve ser alterada retroativamente.

50. Comunicação de envio

A mensagem de envio pode ser adaptada ao Decision Communication Profile, mas deve:

ser factual;
refletir o que foi apresentado;
indicar versão / validade quando necessário;
registrar próximo passo;
não adicionar novas promessas;
não criar urgência artificial;
não reabrir o HOW proprietário.

51. Commercial Decision Case

E4 preserva e aprofunda o Commercial Decision Case já previsto na arquitetura do Sales.

Ele organiza:

Componente	Pergunta
Current Reality	o que acontece hoje?
Evidence	como sabemos?
Impact	por que importa?
Desired Future	o que deveria existir no lugar?
Priority	por que considerar agora?
Decision Unit	quem participa, influencia, aprova e implementa?
Options	quais caminhos legítimos existem?
Solution Fit	por que a solução escolhida possui fit?
Responsible Promise	o que podemos responsavelmente prometer?
Value Hypothesis	que valor pode ser produzido e sob quais condições?
Constraints	que limites, riscos e dependências existem?
Investment	qual configuração comercial autorizada?
Decision Ask	que decisão precisa ser tomada?
Next Step	o que acontece depois?

52. Decision One-Page

A experiência One-Page pode apresentar:

What Is Happening
Why It Matters
What Needs To Change
What We Are Proposing
What We Can Responsibly Promise
What It Requires
What It Costs
What It Does Not Include
What Must Be Decided
What Happens Next

O One-Page não substitui a proposta contratual quando necessária.

53. Decision Ask

O Decision Ask deve ser explícito e proporcional ao estágio.

Exemplos legítimos:

aprovar;
rejeitar;
avançar para contratação;
solicitar revisão;
escolher alternativa A ou B;
validar condição;
envolver outro decisor;
confirmar próximo passo;
adiar com data e motivo;
encerrar;
solicitar mais informação.

Regra:

Decision Ask não é técnica de pressão. É clareza sobre qual decisão está pendente.

54. Decision Ready Package

Handoff governado de E4 para E5.

Pode conter:

Decision Ready Package
 
Case
Customer Need Truth Snapshot
Decision Unit
Decision Communication Profile Snapshot
Proposal Version SENT
Commercial Decision Case
Decision One-Page
Presentation Session
Presentation Intelligence
Responsible Commercial Promise
Fit Conditions
Commercial Configuration
Known Concerns
Known Objections
Known Decision Frictions
Relevant Evidence
Decision Ask
Next-Step Options
Commitment if any
Validity
Human Review

55. Handoff para E5

E5 não deve reconstruir a proposta.

E5 deve receber:

o que foi apresentado;
o que foi enviado;
quem participou;
quem ainda precisa decidir;
o que foi compreendido;
o que gerou dúvida;
quais objeções permanecem;
qual Decision Ask está aberto;
quais condições estão pendentes;
que compromisso foi assumido;
que mudança exigiria reabrir E2/E3/E4.

Dados, governança e rastreabilidade

56. Objetos conceituais próprios do E4

Objetos canônicos candidatos mínimos:

Proposal;
ProposalVersion;
PresentationSession;
CommunicationObservation;
SendAuthorization.

Projeções / experiências, sem obrigação de tabela própria:

DecisionCommunicationProfile;
PresentationPlan;
CommercialDecisionCase quando modelado no Core;
DecisionOnePage;
PresentationIntelligence;
DecisionReadyPackage;
KnowledgeDisclosureClassification.

Reutilizar objetos transversais sempre que possível.

57. Objetos compartilhados

Organization/Tenant;
User / Membership / Role;
Project / Engagement;
Domain Case;
Actor / Decision Unit;
Source;
Evidence Item;
Knowledge Item;
Observation;
Hypothesis;
Gap;
Need Instance;
Customer Need Truth;
Offer;
Offer Version;
Offer Passport;
Solution Fit Assessment;
Responsible Commercial Promise;
Commercial Configuration;
Human Review;
Decision;
Commitment;
Action;
Outcome;
Learning;
Audit Event;
Version.

58. Decision Communication Profile: canonical vs projection

Regra recomendada para o MVP:

DecisionCommunicationProfile deve ser uma projeção versionada derivada de evidências e observações, não uma identidade psicológica persistente do ator.

O ator mantém sua identidade.

O perfil pertence ao contexto de decisão e período.

59. Knowledge Disclosure Policy

Cada tenant pode futuramente possuir política própria, mas o MVP deve suportar ao menos:

PROPOSAL_SAFE;
PRESENTATION_ONLY;
PROTECTED_KNOW_HOW.

O default para conhecimento metodológico proprietário sem classificação deve ser conservador:

não incluir automaticamente em proposta externa.

60. Permissões mínimas

Papéis conceituais:

Papel	Permissão principal
Seller	preparar proposta e apresentação dentro de boundaries
Proposal Reviewer	revisar conteúdo externo
Offer Owner	validar coerência com Offer Version
Claim Reviewer	revisar promises e claims
Financial Reviewer	revisar exceptions de price / terms
Delivery Reviewer	revisar capacidade e escopo quando necessário
Compliance/Specialist Reviewer	revisar conteúdo restrito
Founders / Leadership	aprovar exceções conforme política
Platform Operator	suporte técnico sem acesso comercial por padrão

RLS e tenant isolation permanecem obrigatórios.

61. Auditoria obrigatória

Registrar eventos materiais como:

proposal_created;
proposal_generated;
proposal_review_requested;
proposal_reviewed;
disclosure_flagged;
proposal_presentation_ready;
presentation_started;
presentation_completed;
communication_observation_added;
material_change_detected;
proposal_revision_created;
send_authorization_requested;
send_authorized;
proposal_sent;
proposal_superseded;
proposal_withdrawn;
proposal_expired;
handoff_to_e5_created.

62. Proveniência de IA

Quando IA participar de:

perfil de comunicação;
classificação de estilo;
resumo de evidências;
proposta;
apresentação;
sugestão de narrativa;
classificação de disclosure;
análise de objeções;
material change assessment;

registrar, conforme proporcionalidade:

input source IDs;
output;
model / service;
timestamp;
reviewer;
status de aceitação;
alterações humanas relevantes.

IA e influência responsável

63. Usos permitidos de IA

A IA pode:

consolidar evidências de comunicação;
sugerir Decision Communication Profile;
sinalizar baixa confiança;
sugerir sequência de apresentação;
adaptar densidade e ordem;
gerar proposta a partir do pacote governado;
verificar claims;
detectar possível vazamento de know-how;
comparar versões;
preparar Decision One-Page;
sugerir perguntas de escuta;
resumir Presentation Intelligence;
classificar possível material change;
preparar Human Review.

64. Usos proibidos de IA

A IA não pode:

inferir vulnerabilidade psicológica para exploração;
usar gênero ou geração para escolher técnica de persuasão;
criar medo artificial;
fabricar urgência;
inventar escassez;
inventar social proof;
falsificar autoridade;
ocultar condição material;
ampliar promise;
revelar Protected Know-How sem autorização;
diagnosticar personalidade;
tratar estilo comportamental como certeza;
criar perfil sensível permanente;
recomendar discriminação;
sugerir manipulação emocional;
enviar proposta antes de PRESENTED no fluxo v0.1;
alterar versão enviada;
contornar Human Review.

65. Guardrail de atributos protegidos e sensíveis

O sistema deve separar:

dados necessários para relacionamento respeitoso;
dados necessários para decisão comercial;
atributos sem finalidade legítima de personalização.

Não utilizar atributo protegido ou sensível para inferir:

susceptibilidade;
propensão de compra;
medo;
pressão ideal;
argumento psicológico;
perfil de risco presumido.

Experiência e estados

66. One-Page First

A experiência interna do seller deve mostrar primeiro:

Decision Communication Brief
 
Who decides?
What do they demonstrably care about?
What evidence supports that?
How should we structure the presentation?
What must be communicated?
What must not be disclosed?
What should we listen for?
What is the Decision Ask?

Drill-down fornece evidência e histórico.

67. Empty States

Sem Decision Communication Evidence

Mostrar:

perfil indisponível;
confidence = insufficient;
recomendações neutras;
perguntas para descobrir preferências durante interação.

Não inferir a partir de gênero, idade, cargo ou geração.

Sem Decision Unit suficiente

Bloquear adaptação excessivamente personalizada e sinalizar gap.

Sem Proposal Ready Package

E4 não inicia geração de proposta.

Sem disclosure classification

Usar política conservadora e exigir revisão para conteúdo metodológico.

68. Loading States

Quando IA processar:

perfil;
proposta;
apresentação;
consistency check;

mostrar estado de processamento sem permitir envio prematuro.

Nunca apresentar sugestão de IA como decisão humana concluída.

69. Error States

Falhas de geração não podem:

alterar estado da proposta;
marcar PRESENTED;
marcar SEND_AUTHORIZED;
apagar versão anterior;
perder evidência.

Permitir retry controlado com audit event.

70. Estados de revisão

Sugestão mínima:

NOT_REQUIRED;
PENDING;
APPROVED;
CHANGES_REQUIRED;
REJECTED.

Material promise, pricing exception, disclosure sensível ou mudança de escopo podem exigir reviewer específico.

Invariantes e regras imutáveis

71. Invariantes do E4

E4 não inicia sem Proposal Readiness READY.
Proposta deriva de objetos governados.
Proposta não aumenta a Promise.
Proposal claim material possui rastreabilidade.
Protected Know-How não é incluído automaticamente em artefato externo.
PRESENTATION_ONLY não é enviado automaticamente.
SENT exige PRESENTED no v0.1.
SENT exige SEND_AUTHORIZED.
versão apresentada e versão enviada permanecem rastreáveis.
versão enviada nunca é sobrescrita.
mudança material não vira simples edição silenciosa.
Need Change retorna a E2.
Solution/Fit Change retorna a E3.
commercial exception fora do boundary exige autoridade apropriada.
Decision Communication Profile mantém evidência e confidence.
tipologia não substitui comportamento observado.
gênero e geração não podem inferir técnica de convencimento.
comunicação pode adaptar ênfase, não verdade.
influência exige factualidade.
falsa escassez é proibida.
falsa autoridade é proibida.
social proof inventado é proibido.
cordialidade do cliente não equivale a aceite.
apresentação deve capturar perguntas, concerns e mudanças.
E4 preserva autonomia do cliente.
IA não toma decisão comercial material sem revisão autorizada.

72. Matriz de retorno por mudança

Mudança detectada	Destino
nova realidade / necessidade	E2
novo objetivo material	E2
nova solução ou escopo fora do fit	E3
novo claim material	E3 / Claim Review
nova configuração dentro do boundary	E4
preço fora do boundary	E0.SALES / Financial Review
apenas linguagem / ordem / formato	E4
ausência de fit	encerrar / E6 conforme arquitetura

Minimum Viable Decision & Communication Slice

73. Objetivo do MVP slice

Provar que o Orquestro consegue transformar um Proposal Ready Package em:

proposta protegida;
plano de apresentação adaptado por evidência;
apresentação registrada;
controle de mudança material;
autorização de envio;
handoff rastreável para E5.

Sem construir uma suíte completa de sales enablement.

74. Escopo mínimo candidato

Necessário para completar o fluxo atual

receber Proposal Ready Package;
Proposal + ProposalVersion;
template simples;
disclosure classification mínima;
geração governada;
consistency / claim check;
Human Review;
Presentation Plan simples;
Decision Communication Brief;
Presentation Session;
Presentation Intelligence básica;
Material Change classifier assistido;
Send Authorization Gate;
Proposal Release;
Decision Ready Package;
auditoria;
RLS;
versionamento.

Necessário para piloto real

possibilidade de registrar estilos / preferências como hipótese;
evidence links;
export de proposta;
registro manual da apresentação;
capture de objeções / concerns;
bloqueio de send antes de presentation;
revisão de exceções.

75. Não necessário automaticamente no MVP

engine psicométrica;
reconhecimento facial;
análise emocional por vídeo;
voice stress analysis;
inferência de personalidade;
automação de apresentação ao vivo;
geração autônoma de slides hiperpersonalizados;
A/B testing em escala;
recommendation engine probabilística de fechamento;
previsão de conversão;
nudges ocultos;
persuasive dark patterns;
integração com dezenas de canais;
tracking invasivo de abertura;
scoring demográfico;
CPQ completo;
pricing optimization;
biblioteca universal de “técnicas para objeção”.

76. Incrementos sugeridos

Incremento 1 — Proposal Integrity

Proposal Ready Package intake;
Proposal / ProposalVersion;
Knowledge Disclosure Boundary;
geração derivada;
claim consistency;
Human Review.

Incremento 2 — Decision Communication Intelligence

Communication Evidence;
Decision Communication Profile projection;
confidence;
Decision Unit view;
brief.

Incremento 3 — Presentation Architecture

Presentation Plan;
narrative ordering;
ethical influence guardrails;
one-page;
presentation-ready state.

Incremento 4 — Human Presentation & Release

Presentation Session;
Presentation Intelligence;
Material Change assessment;
Send Authorization;
Proposal Sent;
E5 handoff.

Edge cases

77. Perfil divergente entre atores

Se Economic Approver e Technical Evaluator tiverem preferências opostas:

não escolher um e ignorar outro;
construir uma superfície executiva comum;
disponibilizar detalhe sob demanda;
explicitar quem precisa de qual informação.

78. Perfil incorreto

Se seller ou cliente demonstrar que a hipótese de estilo estava errada:

registrar nova evidence;
reduzir confidence anterior;
atualizar projection;
não apagar histórico;
adaptar comunicação.

79. Cliente pede metodologia detalhada antes de contratar

Resposta do sistema:

identificar conteúdo solicitado;
verificar Knowledge Disclosure Boundary;
oferecer detalhe suficiente para avaliar segurança / qualidade;
não entregar Protected Know-How;
permitir Human Review quando decisão exigir exceção.

80. Cliente pede proposta antes da reunião

No v0.1, o fluxo aprovado continua:

não marcar como SENT;
oferecer agendamento para apresentação;
registrar pedido como evidence / constraint.

Se isso impedir comercialmente um canal específico, registrar learning e avaliar ADR futura, sem bypass ad hoc.

81. Cliente não aceita reunião de apresentação

Estados possíveis:

PRESENTATION_PENDING;
COMMUNICATION_CONSTRAINT;
WITHDRAW;
futura revisão de política mediante evidência.

Não enviar automaticamente apenas para “não perder o lead”.

82. Cliente pede alteração durante apresentação

Classificar antes de editar:

communication-only;
commercial within boundary;
commercial outside boundary;
solution change;
need change.

Somente os dois primeiros podem permanecer integralmente em E4.

83. Apresentação revela novo decisor

atualizar Decision Unit;
avaliar se Presentation Plan precisa mudar;
decidir se nova apresentação é necessária;
não assumir que o primeiro interlocutor representa todos.

84. Cliente quer encaminhar a proposta internamente

Permitido após SENT.

O Orquestro deve garantir que o arquivo enviado seja suficientemente compreensível sem depender de exposição do HOW.

Decision One-Page pode apoiar circulação interna.

85. Proposal Version expira antes da decisão

marcar EXPIRED;
revalidar preço, capacity, Offer Version e Need Truth quando material;
gerar nova versão;
não reciclar condições expiradas silenciosamente.

Human Review e autoridade

86. Human Review obrigatório quando

claim material novo;
disclosure possivelmente proprietário;
preço fora do boundary;
condição excepcional;
escopo ambíguo;
método precisa ser explicado acima do nível usual;
Decision Communication Profile tem efeito material com low confidence;
material change classification é incerta;
compliance / reputação podem ser afetados;
proposta de alto risco ou alto valor conforme política futura.

87. Decisão humana registrada

Toda revisão material deve registrar:

reviewer;
authority;
decisão;
justificativa;
timestamp;
objeto / versão;
conditions;
evidence utilizada.

Critérios de aceite e verificação objetiva

88. Critérios funcionais

89. Critérios de segurança e ética

90. Critérios de experiência

Seller consegue ver em uma página quem decide, o que importa, como sabemos e como comunicar.
Seller consegue acessar evidência subjacente sob demanda.
Proposal Draft diferencia conteúdo externo de conteúdo presentation-only.
Presentation Plan mostra o que dizer, o que perguntar e o que não revelar.
Após apresentação, seller consegue registrar concerns e material change sem reconstruir o caso.
Send Authorization mostra claramente qualquer bloqueio.

Métricas candidatas para validação

91. Métricas sem meta aprovada

Podem ser observadas em pilotos:

tempo de montagem da proposta;
tempo de preparação da apresentação;
percentual de propostas com revisão humana;
disclosure flags por proposta;
claims removidos ou limitados;
apresentações com material change;
reabertura de E2/E3 após apresentação;
proporção de propostas apresentadas antes de envio;
tempo apresentação → envio;
quantidade de Decision Unit actors presentes;
quantidade de concerns capturados;
percepção do seller sobre utilidade do Decision Communication Brief;
percepção do cliente sobre clareza da proposta;
esforço humano consumido.

Não afirmar que personalização aumenta conversão até existir evidência própria.

Learnings e validação

92. O que precisa ser validado

se sellers conseguem usar perfis de comunicação sem engessar a conversa;
se proposta protegida continua suficientemente clara;
se presentation-first melhora compreensão;
se bloqueio de envio gera fricção operacional aceitável;
se clientes aceitam apresentação antes do recebimento;
se Decision One-Page ajuda circulação interna;
se Material Change classifier reduz drift;
se adaptação de ordem e densidade é útil;
se a proteção de HOW preserva valor sem gerar percepção de vagueza;
se os frameworks externos agregam valor ou complexidade.

93. Learning discipline

Um case não autoriza afirmar:

“Analytical compra com dados” universalmente;
“Driving fecha rápido”;
“mulheres precisam de segurança”;
“homens preferem objetividade”;
“Gen X prefere reputação”;
“Millennials querem inovação”;
“presentation-first aumenta conversão”.

Learnings devem permanecer contextualizados até replicação suficiente.

Referências metodológicas externas

94. Uso responsável das referências

As referências abaixo funcionam como fontes de inspiração e lentes, não como propriedade do Orquestro nem como prova de eficácia do produto.

Uso no Orquestro:

lente de comportamento observável;
Analytical, Driving, Amiable, Expressive;
adaptação de comunicação;
evitar “colocar pessoas em caixas”.

Fontes públicas consultadas:

94.2 Disney Planning Strategy — Robert Dilts / NLPU

Uso no Orquestro:

Dreamer → Realist → Critic como ciclo interno de construção e stress test da narrativa.

Fonte pública consultada:

https://www.nlpu.com/Patterns/pattern7.htm

94.3 Duarte / Resonate

Uso no Orquestro:

audiência como protagonista;
contraste what is ↔ what could be;
storytelling aplicado à decisão.

Fontes públicas consultadas:

94.4 Cialdini — Principles of Persuasion

Uso no Orquestro:

authority;
social proof;
consistency;
reciprocity;
scarcity;
liking;
unity;

Sempre sob condição de factualidade e uso ético.

Fonte pública consultada:

https://www.influenceatwork.com/7-principles-of-persuasion/

94.5 Behavioural Insights Team — EAST

Uso no Orquestro:

Easy;
Attractive;
Social;
Timely;

como lente de Decision UX, não como dark pattern.

Fontes públicas consultadas:

94.6 Evidência contrária a atalhos geracionais

A arquitetura v0.1 não utiliza rótulos geracionais como mecanismo de personalização comportamental.

Referência pública:

Rudolph CW, Rauvola RS, Costanza DP, Zacher H. Generations and Generational Differences: Debunking Myths in Organizational Science and Practice and Paving New Paths Forward. Journal of Business and Psychology. 2021.
https://pubmed.ncbi.nlm.nih.gov/32901173/

94.7 Estereótipos e decisão

A arquitetura evita inferir comportamento a partir de gênero e outros estereótipos.

Referência pública exemplificativa:

Carr PB, Steele CM. Stereotype threat affects financial decision making. Psychological Science. 2010.
https://pubmed.ncbi.nlm.nih.gov/20855899/

Decisões arquiteturais que ainda podem exigir ADR

95. ADR candidates

canonical model de DecisionCommunicationProfile se a projection se mostrar insuficiente;
política de validade do perfil de comunicação;
nível mínimo de evidence para style suggestion;
política tenant-specific de Knowledge Disclosure;
mecanismo de export e proteção de artefatos;
templates por tenant;
assinatura / aprovação de Proposal Version;
requisitos legais de proposta e contratação por mercado;
exception policy futura para canais que exijam proposta antes da apresentação;
integração com e-signature;
integração com CRM;
critérios de material change automatizáveis;
field-level access a price / cost / margin;
retention de Presentation Intelligence;
recording / transcription policy, se algum dia utilizada;
política de uso de fontes externas e cases na apresentação.

Não resolver automaticamente sem evidência ou necessidade de desenvolvimento.

Handoff de implementação

96. Fluxo funcional mínimo esperado

Proposal Ready Package
→ Decision Communication Brief
→ Proposal Draft
→ Disclosure Check
→ Human Review
→ PRESENTATION_READY
→ Presentation Plan
→ Human Presentation
→ Presentation Intelligence
→ Material Change Check
→ Send Authorization Gate
→ Proposal Version SENT
→ Decision Ready Package
→ E5

97. Prova funcional do E4

Um caso fictício ou real deve conseguir demonstrar:

E3 envia Proposal Ready Package;
sistema apresenta evidências de comunicação do decisor;
sistema sugere profile com confidence;
proposta é gerada sem Protected Know-How;
proposta preserva Promise e pricing autorizados;
Presentation Plan é produzido;
proposta não pode ser enviada antes da apresentação;
seller registra Presentation Session;
seller registra concern / objection;
Material Change é classificada;
se não houver mudança impeditiva, send é autorizado;
Proposal Version é enviada e congelada;
Decision Ready Package é criado;
toda conclusão retorna aos objetos e evidências relevantes.

98. Truthmode final

Aprovado / estruturado neste documento

E4 como Decision & Communication;
protection of HOW;
Knowledge Disclosure Boundary;
proposal by derivation;
Decision Communication Profile baseado em evidence;
SOCIAL STYLE como lente assistiva;
demographic safeguards;
Disney/Dilts como Proposal Imagineering Loop;
Duarte como lente narrativa;
Cialdini apenas sob influência ética;
EAST como Decision UX;
presentation before send;
Listen-First Protocol;
Material Change routing;
Send Authorization Gate;
E5 handoff.

Ainda não comprovado

implementação funcional;
qualidade da classificação de disclosure;
precisão do perfil de comunicação;
valor da adaptação por estilo;
aceitação de presentation-first em diferentes mercados;
efeito sobre conversão;
efeito sobre ciclo de venda;
redução de commoditização;
proteção efetiva de propriedade intelectual;
melhor percepção de reputação;
melhora de win rate;
Product-Market Fit.

99. Síntese executiva

E3 — RESPONSIBLE SOLUTION FIT
        ↓
Proposal Ready Package
        ↓
E4.1 — DECISION COMMUNICATION INTELLIGENCE
        ↓
Observed Behavior
Decision Unit
Decision Communication Profile
        ↓
E4.2 — PROPOSAL ARCHITECTURE
        ↓
WHAT / WHY / VALUE / SCOPE / CONDITIONS
Knowledge Disclosure Boundary
Protected HOW
        ↓
E4.3 — PRESENTATION ARCHITECTURE
        ↓
Audience as protagonist
What Is ↔ What Could Be
Dreamer → Realist → Critic
Ethical Influence
EAST Decision UX
        ↓
E4.4 — HUMAN PRESENTATION & LISTENING
        ↓
Present
Listen
Clarify
Observe
Capture
        ↓
Material Change?
  YES ↙       ↘ NO
E2/E3/E0     Send Authorization
                   ↓
E4.5 — PROPOSAL RELEASE
                   ↓
Proposal SENT
                   ↓
Decision Ready Package
                   ↓
E5 — DECISION CONVERSATION

Princípios finais:

Quem isola, vende.

Quem ouve, vende melhor.

A comunicação pode mudar a ênfase, nunca a verdade.

A proposta deve ser suficiente para decidir, não suficiente para copiar.

A primeira experiência com a proposta é uma conversa, não um anexo.

100. Bloco de inicialização para outra IA

Você está trabalhando no Orquestro™.
 
Aplique como baseline aprovada:
 
- E3 entrega Proposal Ready Package;
- E4 é Decision & Communication;
- proposta deriva de objetos governados;
- proposta mostra WHAT, WHY, VALUE, SCOPE e CONDITIONS;
- HOW proprietário deve ser protegido;
- usar Knowledge Disclosure Boundary: PROPOSAL_SAFE, PRESENTATION_ONLY, PROTECTED_KNOW_HOW;
- Decision Communication Profile deriva de comportamento observado e evidence;
- SOCIAL STYLE pode ser lente assistiva, nunca diagnóstico;
- não usar gênero ou rótulo geracional para inferir técnica de persuasão;
- personalizar sequência, ênfase, profundidade, ritmo e formato sem alterar verdade;
- usar metodologias externas apenas como lentes e sob guardrails éticos;
- apresentação humana acontece antes do envio da proposta;
- SENT exige PRESENTED e SEND_AUTHORIZED no v0.1;
- apresentação deve gerar nova evidence e detectar material change;
- Need Change retorna a E2;
- Solution/Fit Change retorna a E3;
- commercial exception fora do boundary retorna a review apropriado;
- E4 termina com Proposal Version SENT + Decision Ready Package;
- E5 assume Decision Conversation subsequente;
- preserve rastreabilidade, Human Review, versionamento, RLS e auditabilidade;
- não trate arquitetura documentada como funcionalidade implementada.

E5 — Decision Conversation & Feedback Intelligence v0.1

Fonte incorporada integralmente: Orquestro_E5_Decision_Conversation_Feedback_Intelligence_v0.1_2026-08-22.md

Orquestro E5 — Decision Conversation & Feedback Intelligence

Definição funcional: Listen, Understand, Reframe, Prepare & Decide
Versão: 0.1
Data: 22/08/2026
Status: baseline arquitetural aprovada para especificação e desenvolvimento incremental
Classificação: etapa especializada do Orquestro™
Escopo do documento: arquitetura funcional, conhecimento, experiência, dados, governança e Minimum Viable E5 Slice
Fundação obrigatória: E0.CORE + E0.SALES + E1 + E2 + E3 Responsible Solution Fit + E4 Decision & Communication
Fonte metodológica aplicada: Product Markdown Rail

Aviso de maturidade: este documento define a arquitetura pretendida do E5. Não comprova que os fluxos, classificadores, IA, ciclos de feedback, negociação assistida ou integrações estejam implementados, validados ou prontos para produção.

1. Finalidade do documento

Este documento especifica o E5 — Decision Conversation & Feedback Intelligence, etapa responsável por transformar o que aconteceu após a apresentação presencial da proposta em conhecimento estruturado, preparar respostas responsáveis a objeções e fricções, orientar novos contatos humanos e sustentar ciclos de decisão sem pressão indevida.

O E5 deve orientar:

produto;
arquitetura de conhecimento;
experiência do seller;
preparação de follow-ups;
tratamento responsável de objeções;
negociação dentro de limites autorizados;
Decision Unit;
Decision Communication Profile;
Human Review;
modelagem de dados;
desenvolvimento assistido por IA;
testes e pilotos;
handoff para E6 — Momentum, Outcome & Learning.

Este é um documento de arquitetura e especificação modular. Funcionalidades técnicas menores deverão gerar PRDs próprios conforme o Product Markdown Rail.

2. Decisão arquitetural aprovada

Decisão:

A apresentação da proposta ocorre presencialmente e pertence ao E4. O Orquestro não ocupa a conversa. Se a proposta for aceita na apresentação, o caso pode seguir diretamente para fechamento/E6. Se não houver fechamento, o seller alimenta o sistema depois da reunião e o E5 começa a partir desse debrief.

O fluxo padrão é:

E4 — Decision & Communication
        ↓
Proposal + Presentation Ready
        ↓
PRESENTAÇÃO PRESENCIAL / HUMANA
        ↓
Decision?
   ↙           ↘
 YES            NOT YET
  ↓                ↓
Proposal sent   Proposal sent
  ↓                ↓
E6 / Close      Presentation Debrief
                   ↓
        E5 — Decision Conversation
                   ↓
        Feedback & Closing Cycles

3. Tese central

O Orquestro não deve ocupar o espaço da conversa. Deve tornar cada próxima conversa melhor do que a anterior.

O E5 parte de cinco princípios operacionais:

Quem isola, vende.
Quem ouve, vende melhor.
Objeção é informação antes de ser negociação.
Interesse vem antes da concessão.
Uma boa conversa comercial não empurra uma decisão; remove aquilo que impede uma decisão consciente.

4. O que o E5 é

O E5 é:

ciclo de inteligência pós-apresentação;
mecanismo de debrief estruturado;
sistema de identificação de fricções decisórias;
preparação de respostas e perguntas abertas;
apoio à negociação dentro de boundaries aprovados;
memória governada das interações de fechamento;
mecanismo de atualização da Decision Unit;
mecanismo de atualização do Decision Communication Profile;
ponte entre a proposta apresentada e o outcome comercial;
fonte de learning para E0, E1, E2, E3, E4 e E6.

5. O que o E5 não é

Não é:

objection killer;
script automático de convencimento;
teleprompter em tempo real;
IA soprando respostas durante a reunião;
ferramenta de manipulação;
sistema de pressure selling;
gerador de falsa urgência;
autorizador automático de desconto;
ferramenta de psychological profiling;
sistema que interpreta silêncio como rejeição;
mecanismo que inventa motivo de perda;
autorização para alterar necessidade, promise, fit ou escopo sem reavaliação;
substituto do seller;
CRM completo.

6. Fronteira E4 → E5

6.1 E4 termina quando

Existe uma proposta aprovada, uma apresentação preparada, uma Decision One-Page e um Decision Ask coerentes, e a apresentação presencial foi realizada.

6.2 E5 somente é ativado quando

Após a apresentação:

não houve aceite definitivo; ou
existe condição pendente; ou
existe objeção; ou
outro decisor precisa participar; ou
há necessidade de informação adicional; ou
existe pedido de alteração; ou
a oportunidade permanece em decisão.

6.3 Bypass legítimo

Se o cliente aceitar a proposta na apresentação e não existir gap material, o E5 pode ser bypassado.

PRESENTED
   ↓
ACCEPTED
   ↓
Proposal Sent
   ↓
E6 / Contracting / Outcome

Não criar artificialmente E5 quando a decisão já ocorreu.

7. Princípio Human Interaction → Intelligence → Human Interaction

A experiência padrão deve ser:

HUMAN INTERACTION
      ↓
DEBRIEF
      ↓
Orquestro INTELLIGENCE
      ↓
PREPARAÇÃO
      ↓
NEXT HUMAN INTERACTION
      ↓
DEBRIEF
      ↓
Orquestro INTELLIGENCE
      ↺

O sistema opera principalmente antes e depois do contato humano.

8. Invariante de presença do sistema

Durante apresentação, reunião de follow-up, ligação, videoconferência ou conversa presencial:

o uso do Orquestro deve ser mínimo e opcional;
o sistema não deve conduzir o diálogo;
o sistema não deve recomendar fala em tempo real como condição da conversa;
o sistema não deve substituir escuta;
o sistema não deve alterar proposta ou concessão sem autoridade;
gravação, transcrição ou análise de pessoas dependem de base adequada, transparência e autorização aplicável.

9. Entrada principal do E5 — Presentation Debrief

O objeto de entrada principal é o Presentation Debrief.

Ele registra, após a reunião:

participantes;
data e contexto;
Proposal Version apresentada;
Decision Ask utilizado;
Customer Statements;
perguntas feitas pelo cliente;
objeções declaradas;
condições solicitadas;
alterações solicitadas;
Decision Unit observada;
compromissos assumidos;
próximo passo combinado;
Seller Observations;
Hypotheses;
Gaps;
estado atual da decisão.

10. Epistemologia obrigatória do debrief

Cada informação deve ser classificada.

Tipo	Regra
`CUSTOMER_STATEMENT`	algo efetivamente dito pelo cliente
`SELLER_OBSERVATION`	percepção do seller sobre comportamento/contexto
`HYPOTHESIS`	interpretação ainda não confirmada
`GAP`	informação relevante ainda desconhecida
`EVIDENCE`	evidência identificável ligada à conclusão
`DECISION`	escolha explicitamente tomada
`COMMITMENT`	ação assumida por ator, com condição/data quando disponível

Regra:

Reação percebida não vira fato. Silêncio não vira objeção. Hipótese não vira motivo de perda.

11. Presentation Debrief — campos mínimos

PresentationDebrief
 
id
tenant_id
opportunity_id
proposal_version_id
presentation_date
participants[]
customer_statements[]
questions_raised[]
surface_objections[]
seller_observations[]
hypotheses[]
gaps[]
requested_changes[]
requested_concessions[]
decision_unit_changes[]
commitments[]
next_step
next_step_owner
next_step_date
decision_state
created_by
created_at
review_status

12. Estado inicial após a apresentação

O debrief deve permitir estados explícitos como:

ACCEPTED;
REJECTED;
NOT_YET;
MORE_INFORMATION_REQUIRED;
ANOTHER_DECISION_MAKER_REQUIRED;
CHANGE_REQUESTED;
COMMERCIAL_CONDITION_REQUESTED;
NO_DECISION;
UNKNOWN.

Esses estados não substituem os estados comerciais canônicos de E6. Servem ao roteamento imediato do E5.

13. Conceito central — Decision Friction

DecisionFriction representa algo que dificulta, atrasa ou impede a decisão naquele contexto.

Não é sinônimo de objeção.

Uma objeção é uma manifestação observável. Uma fricção é a interpretação estruturada do que pode estar por trás da manifestação.

14. Surface Objection

SurfaceObjection registra o que foi dito.

Categorias operacionais preservadas:

FINANCIAL;
TIME;
AUTHORITY;
NEED;
TECHNICAL;
UTILITY;
ATTRACTIVENESS;
OTHER.

Essas categorias ajudam organização e preparação, mas não autorizam diagnóstico causal automático.

15. Decision Friction — categorias candidatas

Categorias conceituais:

CLARITY;
VALUE_CLARITY;
ECONOMIC;
CASH_FLOW;
RISK;
TRUST;
IMPLEMENTATION;
CAPACITY;
TIMING;
PRIORITY;
AUTHORITY;
CONSENSUS;
SCOPE;
COMMERCIAL_TERM;
COMPETITIVE_COMPARISON;
INFORMATION;
INTERNAL_PROCESS;
NO_DECISION;
UNKNOWN.

16. Objeção ≠ fricção

Exemplo:

CUSTOMER STATEMENT:
"Achei o investimento alto."
 
Surface Objection:
FINANCIAL
 
Possible Decision Frictions:
- VALUE_CLARITY
- BUDGET
- CASH_FLOW
- PRIORITY
- COMPETITIVE_COMPARISON
- AUTHORITY
 
Status:
HYPOTHESIS until explored

O sistema deve preparar investigação, não assumir a causa.

17. Regra oficial para objeções — CRR + Open Question

Toda preparação de resposta a objeção no E5 deve seguir:

CONCORDA
   ↓
REFORÇA
   ↓
REITERA
   ↓
PERGUNTA ABERTA

Nome operacional:

CRR + Open Question

18. CONCORDA

Objetivo: reconhecer legitimidade da preocupação sem validar automaticamente uma premissa incorreta.

Exemplo correto:

“Faz sentido vocês analisarem esse investimento com cuidado.”

Exemplo incorreto:

“Sim, realmente está caro.”

Regra:

Concordar significa legitimar o direito de questionar, não fabricar concordância factual.

19. REFORÇA

Objetivo: reforçar a validade do critério decisório utilizado pelo cliente.

Exemplo:

“Inclusive, um projeto como esse só deveria avançar se o investimento fizer sentido diante do problema que ele pretende resolver.”

O reforço reduz confronto e mantém a conversa no critério real de decisão.

20. REITERA

Objetivo: retornar à verdade já construída.

A reiteração deve usar apenas elementos autorizados e relevantes:

Customer Need Truth;
Responsible Commercial Promise;
fit confirmado;
USF1 pertinente;
USF2 pertinente;
USP pertinente;
evidência autorizada;
condição comercial aprovada;
Relevant Value Stack.

Não deve:

inventar benefício;
inflar claim;
prometer resultado não controlável;
revelar Protected Know-How;
utilizar argumento irrelevante apenas para aumentar pressão.

21. PERGUNTA ABERTA — obrigatória

Toda preparação de resposta a objeção deve terminar com pergunta aberta.

Objetivo:

devolver a palavra ao cliente;
ampliar conhecimento;
testar hipótese;
identificar a fricção real;
evitar monólogo defensivo;
preservar autonomia.

Exemplos de forma:

“O que mais pesa nessa avaliação para vocês?”
“O que precisaria ficar mais claro para conseguirem avaliar esse ponto?”
“Como vocês estão comparando esse investimento com o impacto do problema que discutimos?”
“O que hoje impede vocês de se sentirem confortáveis com essa decisão?”

Regra:

A resposta à objeção deve produzir novo conhecimento.

22. Perguntas abertas como padrão do E5

Nos ciclos de feedback e fechamento:

perguntas investigativas são abertas por padrão;
perguntas para compreender objeção são abertas;
perguntas para identificar interesse por trás de posição são abertas;
perguntas para explorar autoridade, prioridade, risco e timing são abertas;
perguntas para pedir próximo movimento são preferencialmente abertas.

Perguntas binárias ficam restritas a confirmações formais ou registros operacionais quando necessárias, nunca como substituto da exploração.

23. Estrutura completa de uma resposta preparada

Customer Statement
      ↓
Surface Objection
      ↓
Possible Friction(s)
      ↓
Relevant Need Truth
      ↓
Responsible Promise
      ↓
Relevant Value Stack
      ↓
CRR
      ↓
Open Question(s)
      ↓
Negotiation Boundary
      ↓
Next Human Contact

24. Arquitetura de valor — origem no E0

O E5 não cria valor narrativo do zero.

A arquitetura de valor deve ser conhecida desde E0 e versionada.

No nível organizacional:

Organization Value Architecture
 
Organization USF1
Organization USF2
Organization USP

No nível de oferta:

Offer Value Architecture
 
Offer USF1
Offer USF2
Offer USP

O E5 seleciona e contextualiza; não inventa.

25. USF1 — dimensão tangível

USF1 representa os elementos concretos e diferenciais do que é oferecido.

Pode incluir, conforme a Offer Version:

entregáveis;
estruturas;
artefatos;
acompanhamento;
indicadores;
reuniões;
ferramentas;
componentes;
resultados intermediários controláveis.

Pergunta semântica:

O que existe concretamente nesta oferta que ajuda a enfrentar a necessidade?

26. USF2 — valor intangível da entrega

USF2 representa o valor intangível da forma de entrega e da experiência de aplicação.

Pode comunicar:

integração;
proximidade;
clareza;
personalização governada;
implementação assistida;
decisões baseadas em evidência;
redução de carga cognitiva;
segurança de execução;
continuidade;
capacidade de aprendizagem.

Pergunta semântica:

Que valor adicional existe na maneira responsável pela qual a oferta é entregue?

27. USF2 e Knowledge Disclosure Boundary

USF2 comunica o valor do HOW, mas não revela o HOW protegido.

Pode dizer:

“implementação assistida e baseada em evidência”.

Não deve necessariamente revelar:

sequência proprietária;
framework interno detalhado;
taxonomia sensível;
prompts;
critérios internos;
instrumentos proprietários;
lógica detalhada da Engine.

Regra:

USF2 comunica o valor do HOW, não entrega o HOW.

28. USP — síntese diferencial

USP representa a síntese clara do benefício diferencial da empresa ou da oferta.

Deve ser:

compreensível;
curta;
relevante;
coerente com evidência;
compatível com a Offer Version;
compatível com claims autorizados.

Não autoriza afirmar automaticamente:

“somos os únicos”;
“somos os melhores”;
“somos os mais rápidos”;
“temos o melhor custo-benefício”.

Superioridade comparativa exige evidência adequada.

29. Organization Value Architecture

A organização vendedora pode possuir uma arquitetura transversal de valor, reutilizável por suas ofertas.

Campos conceituais:

OrganizationValueArchitecture
 
organization_id
version
usf1_items[]
usf2_items[]
usp_statement
evidence_links[]
limitations[]
owner
review_status
valid_from
valid_until

30. Offer Value Architecture

Cada Offer Version pode especializar a arquitetura transversal.

Campos conceituais:

OfferValueArchitecture
 
offer_version_id
usf1_items[]
usf2_items[]
usp_statement
audience_notes[]
allowed_claims[]
evidence_links[]
limitations[]
owner
review_status

31. Relevant Value Stack

O E5 não deve despejar todos os benefícios disponíveis em toda objeção.

Cria-se o conceito:

Relevant Value Stack

Definição:

seleção mínima e relevante de USF1, USF2, USP, promise, evidence e benefícios diretamente relacionados à fricção em análise.

32. Regra de relevância do Value Stack

Um item só entra no Relevant Value Stack se houver vínculo justificável com:

Customer Need Truth;
Desired Future;
Responsible Commercial Promise;
Decision Friction;
critério decisório demonstrado;
objeção declarada;
evidência pertinente.

Não usar “empilhamento” como volume retórico.

Mais argumentos não significam mais clareza.

33. Quatro dimensões históricas de avaliação

A metodologia comercial histórica utilizava quatro lentes:

custo-benefício / financeira;
técnica;
atratividade;
utilidade.

No Orquestro, essas lentes podem ser preservadas como Decision Evaluation Dimensions, sem assumir que todo comprador decide da mesma forma.

Dimensão	Pergunta atualizada
Financial	o investimento é compreendido e considerado viável?
Technical	a solução parece adequada e confiável para a necessidade?
Attractiveness	a alternativa é relevante e prioritária diante de outras opções?
Utility	o cliente acredita que conseguirá usar, implementar e capturar valor?

34. Heurísticas históricas não viram causalidade

Mapeamentos antigos entre tipos de objeção e falhas de venda podem permanecer como memória metodológica, nunca como regra causal.

Exemplo:

“objeção de autoridade pode sinalizar falha de pre-work”

é hipótese investigativa.

Não é fato automático.

35. E5.1 — Presentation Debrief

Objetivo:

transformar a apresentação presencial em conhecimento estruturado sem contaminar fatos com interpretação.

Fluxo:

Presentation completed
      ↓
Seller opens debrief
      ↓
records statements
      ↓
records observations
      ↓
records objections/requests
      ↓
records decision state
      ↓
records commitments
      ↓
Human Review
      ↓
E5.2

36. E5.2 — Decision Friction Intelligence

Objetivo:

organizar o que está dificultando a decisão e definir o que ainda precisa ser compreendido.

O sistema pode:

agrupar Surface Objections;
sugerir possíveis fricções;
apontar hipóteses concorrentes;
detectar gaps;
ligar fricções a Need Truth;
ligar fricções a Decision Unit;
sugerir perguntas abertas;
sugerir evidência a recuperar;
recomendar reabertura de etapa quando necessário.

Toda inferência permanece explicável e revisável.

37. E5.3 — Objection & Negotiation Preparation

Objetivo:

preparar o próximo contato humano com resposta responsável, perguntas abertas e boundaries explícitos.

Saída principal:

Decision Feedback Brief.

38. E5.4 — Decision Feedback Cycle

Objetivo:

sustentar sucessivos ciclos de contato humano e aprendizado até ocorrer decisão, commitment explícito ou roteamento material.

Decision Feedback Brief
       ↓
HUMAN FOLLOW-UP
       ↓
Customer Response
       ↓
Debrief
       ↓
New Knowledge
       ↓
Prepare Next Contact
       ↺

39. Decision Feedback Brief

O One-Page do E5 deve conter:

Decision needed
Current Proposal Version
Current Decision State
 
What customer said
Known Surface Objections
Possible Decision Frictions
Known gaps
 
Relevant Customer Need
Responsible Promise
Relevant Value Stack
 
CRR preparation
Open questions
Relevant evidence
 
Negotiation boundaries
What can change
What requires review
What cannot be promised
 
Decision Unit notes
Communication profile notes
Recommended next human contact

40. Posição ≠ interesse

O E5 deve distinguir:

Position — o que o cliente pede ou declara;
Interest — o motivo subjacente confirmado ou suficientemente evidenciado.

Exemplo:

POSITION:
"Quero 20% de desconto."
 
INTEREST:
UNKNOWN

O sistema deve preparar pergunta aberta antes de presumir o interesse.

41. Interesse antes da concessão

Invariante:

Nenhuma concessão deve ser recomendada apenas porque existe uma posição explícita. Primeiro deve-se compreender o interesse que a posição procura resolver.

Pergunta operacional:

“O que precisaria ser resolvido para que essa condição econômica fizesse sentido para vocês?”

42. Negotiation Boundary Package

O E5 herda de E0/E3/E4:

Negotiation Boundary Package
 
Approved Price
Discount Boundary
Payment Boundary
Scope Boundary
Timeline Flexibility
Included Components
Optional Components
Capacity Constraints
Partner Constraints
Claim Boundaries
Negotiable Items
Non-Negotiable Items
Human Review Required Items

43. Regra de negociação

E5 negocia somente dentro do espaço comercial autorizado.

Se a solicitação estiver fora do boundary:

OUTSIDE AUTHORITY
      ↓
HUMAN REVIEW REQUIRED

O sistema não deve sugerir concessão fora de autoridade.

44. Concessão governada

Toda concessão material deve registrar:

pedido do cliente;
Customer Statement relacionado;
interesse subjacente, quando conhecido;
valor/condição anterior;
valor/condição proposto;
impacto conhecido;
autoridade necessária;
approver;
decisão;
validade;
Proposal Version resultante, quando aplicável.

45. Material Change Classifier

Nem toda solicitação pertence ao E5.

O sistema deve classificar mudança material e rotear.

Mudança	Rota
cliente redefine a necessidade	E2
nova necessidade material	E2
nova solução necessária	E3
novo componente fora do fit	E3
nova promise necessária	E3
alteração textual sem efeito material	E4
nova Proposal Version dentro do boundary	E4
pagamento dentro do boundary	E5
desconto dentro da autoridade	E5
condição fora da autoridade	Human Review / E0.SALES
novo decisor	Decision Unit update
aceite	E6
rejeição	E6

46. Regra de reabertura

Negociação não autoriza violar o fit.

Se uma mudança altera:

Need Truth;
Responsible Commercial Promise;
Offer Version;
Solution Fit;
Scope boundary;
capability essencial;
claim material;

então a etapa correspondente deve ser reaberta.

47. Decision Unit Intelligence viva

O E5 pode atualizar a Decision Unit quando surgir nova evidência.

Exemplo:

Customer Statement:
"Meu sócio financeiro precisa aprovar."
 
Decision Unit update:
Economic Approver added
 
Evidence:
Customer Statement

Papéis permanecem contextuais à decisão.

48. Decision Communication Profile vivo

O E5 pode fortalecer, enfraquecer ou corrigir preferências observadas.

Exemplo:

Previous hypothesis:
Detail Appetite = LOW
 
New Customer Statement:
"Quero ver premissas e riscos antes de decidir."
 
Update:
Detail Appetite = HIGH
Evidence = Customer Statement
Confidence = HIGH

Regra:

Comportamento observado vence inferência anterior.

49. Personalização sem estereótipo

O E5 pode adaptar preparação por:

Decision Communication Profile;
papel na Decision Unit;
perguntas efetivamente feitas;
critérios demonstrados;
ritmo decisório observado;
preferência de detalhe observada;
confiança, risco e clareza demonstrados.

Não deve inferir estratégia de fechamento a partir de gênero, geração, etnia, religião ou outra característica sensível.

Quando utilizado, estilos como Relator/Amiable, Socializador/Expressive, Analisador/Analytical e Diretor/Driving são lentes comportamentais auxiliares, nunca diagnóstico permanente.

A evidência primária permanece em comportamento observado e Customer Statements.

51. Decision Confidence — sem score psicológico

O sistema pode organizar sinais de clareza decisória:

entendimento da solução;
clareza de valor;
clareza de risco;
clareza de implementação;
clareza econômica;
alinhamento interno;
fricções pendentes.

Não deve transformar isso em falsa precisão como:

“Buyer Confidence = 82%”.

52. Sensemaking

Quando existir excesso de informação, o sistema deve ajudar o seller a reduzir complexidade.

Pergunta recomendável:

“Quais são hoje as informações que ainda faltam para vocês conseguirem decidir?”

Regra:

Em dúvida decisória, priorizar clareza antes de volume de material.

53. IA — usos permitidos

A IA pode apoiar:

organização do debrief;
classificação preliminar de Surface Objections;
sugestão de possíveis Decision Frictions;
criação de hipóteses concorrentes;
identificação de gaps;
ligação com Customer Need Truth;
seleção de Relevant Value Stack;
preparação de CRR;
geração de perguntas abertas;
síntese de evidências relevantes;
preparação de Decision Feedback Brief;
detecção de material change;
comparação de versões;
preparação de Human Review.

54. IA — usos proibidos

A IA não deve:

inventar motivo da objeção;
inventar orçamento;
inventar autoridade;
sugerir pressão indevida;
sugerir falsa escassez;
sugerir urgência inexistente;
produzir mentira comparativa sobre concorrentes;
usar gênero ou geração para inferir vulnerabilidade;
revelar Protected Know-How;
alterar preço fora de boundary;
aceitar concessão automaticamente;
alterar Solution Fit silenciosamente;
fabricar social proof;
converter hipótese em Customer Statement;
marcar oportunidade como perdida sem evidência.

55. Feedback response plan

ObjectionResponsePlan deve ser estruturado, não apenas texto livre.

Campos:

objection_id
surface_category
customer_statement_id
possible_friction_ids[]
relevant_need_links[]
responsible_promise_link
relevant_value_stack_id
agree_block
reinforce_block
reiterate_block
open_questions[]
negotiation_boundary_reference
claims_used[]
evidence_links[]
review_status

56. Decision Feedback Cycle

Cada ciclo deve possuir identidade própria.

DecisionFeedbackCycle
 
id
opportunity_id
cycle_number
trigger
debrief_id
feedback_brief_id
human_contact_type
contact_date
outcome
next_commitment
route
created_at
closed_at

57. Estados do ciclo E5

Estados mínimos:

DEBRIEF_REQUIRED;
ANALYSIS_PENDING;
PREPARED;
HUMAN_CONTACT_PENDING;
DEBRIEF_PENDING;
ROUTED;
DECISION_REACHED;
CLOSED.

Não transformar esses estados em pipeline CRM completo.

58. Commitments

Todo commitment relevante deve registrar:

quem;
o que;
para quando;
condição, se houver;
origem;
status.

Exemplos:

cliente envia dado;
seller revisa condição;
sócio participa de reunião;
proposta revisada será apresentada;
decisão será tomada após reunião interna.

59. Next Step sem pressão artificial

O próximo passo deve ser:

explícito;
mutuamente compreendido;
proporcional;
compatível com o estado real;
registrado quando houver compromisso.

Evitar follow-up genérico recorrente sem razão.

60. No Decision é estado legítimo

NO_DECISION não deve ser automaticamente convertido em:

rejeição;
oportunidade quente;
silêncio positivo;
convite para pressão crescente.

Deve produzir investigação proporcional e, depois, E6 pode tratar No-Decision Intelligence.

61. Decisão negativa é válida

Se o cliente rejeitar claramente:

registrar o que foi efetivamente dito;
não pressionar por justificativa além do razoável;
distinguir motivo declarado de hipótese;
preservar oportunidade de learning;
seguir para E6.

Uma decisão negativa clara é conhecimento comercial melhor do que uma oportunidade artificialmente aberta.

62. Decision Ask no E5

O E5 pode preparar perguntas abertas que conduzam à clareza decisória, como:

“Como vocês gostariam de seguir a partir daqui?”
“O que ainda precisaria acontecer para conseguirem tomar uma decisão?”
“Quem mais precisa participar para essa decisão avançar?”
“Quais condições vocês consideram essenciais para seguir?”
“Como essa prioridade está sendo avaliada internamente agora?”

Perguntas binárias ficam para formalização final quando apropriado.

63. Respostas por categoria de objeção

O sistema pode possuir padrões estruturais por categoria, mas nunca canned scripts universais.

Financeira

Preparar:

critério econômico declarado;
Need/Impact relevante;
promise;
valor tangível/intangível pertinente;
boundary de preço/pagamento;
perguntas abertas sobre viabilidade e critério.

Tempo

Preparar:

timing real;
change load;
prerequisites;
impacto de postergar, somente se sustentado;
perguntas abertas sobre janela e capacidade.

Autoridade

Preparar:

Decision Unit;
novo approver;
informação necessária para esse ator;
perguntas abertas sobre processo decisório.

Necessidade

Preparar:

Customer Need Truth;
evidência;
Desired Future;
possibilidade de reabrir E2;
perguntas abertas sobre mudança percebida.

Técnica

Preparar:

Solution Fit;
capability;
evidence;
boundaries;
perguntas abertas sobre critérios técnicos.

Utilidade

Preparar:

Implementation Fit;
customer prerequisites;
adoção;
esforço esperado;
perguntas abertas sobre uso e implementação.

Atratividade

Preparar:

prioridade;
alternativas legítimas;
Desired Future;
Strategic Fit;
perguntas abertas sobre relevância e comparação.

64. Regra de comparação com concorrentes

O Orquestro não deve afirmar superioridade sem base.

Pode comunicar:

diferencial comprovado;
capability documentada;
condição específica;
abordagem validamente distinta;
evidência comparável quando disponível.

Não pode inventar:

concorrente pior;
velocidade superior;
ROI superior;
exclusividade inexistente.

65. Roteamento após cada ciclo

Após cada debrief, o sistema deve produzir uma rota explícita:

CONTINUE_E5;
RETURN_E2;
RETURN_E3;
RETURN_E4;
HUMAN_REVIEW;
GO_E6_ACCEPTED;
GO_E6_REJECTED;
GO_E6_NO_DECISION.

66. Objetos próprios do E5

Objetos candidatos:

PresentationDebrief;
SurfaceObjection;
DecisionFriction;
PositionStatement;
InterestHypothesis;
RelevantValueStack;
ObjectionResponsePlan;
NegotiationRequest;
NegotiationDecision;
DecisionFeedbackBrief;
DecisionFeedbackCycle.

Evitar criar entidade quando projeção ou objeto compartilhado for suficiente.

67. Objetos compartilhados reutilizados

Organization;
Offer / OfferVersion;
OrganizationValueArchitecture;
OfferValueArchitecture;
NeedInstance;
Customer Need Truth;
Responsible Commercial Promise;
SolutionFitAssessment;
CommercialConfiguration;
ProposalVersion;
DecisionUnit;
DecisionCommunicationProfile;
Source;
EvidenceItem;
Observation;
Hypothesis;
Gap;
HumanReview;
Decision;
Commitment;
Action;
Outcome;
Learning;
AuditEvent;
Version.

68. Permissões mínimas

Papéis conceituais:

Papel	Permissão
Seller	registrar debrief, consultar brief e preparar contato
Sales Lead / Offer Owner	revisar valor, boundaries e mudanças
Financial Reviewer	revisar preço, desconto e condições
Specialist Reviewer	revisar claims, riscos ou questões técnicas
Compliance Reviewer	revisar restrições quando aplicável
Platform Operator	suporte técnico sem acesso comercial por padrão
Board Viewer	visão executiva agregada conforme autorização

Permissões detalhadas dependem do modelo canônico de roles e RLS.

69. Segurança e privacidade

E5 pode conter informação comercial sensível e observações sobre pessoas.

Aplicar:

tenant isolation;
least privilege;
purpose limitation;
minimização;
retenção definida;
trilha de acesso quando material;
proteção de dados pessoais;
não armazenar características sensíveis sem necessidade e base adequada;
não usar perfis comportamentais para discriminação.

70. Versionamento

Devem ser versionados ou temporalmente rastreáveis:

Proposal Version;
Decision Communication Profile quando material;
Organization/Offer Value Architecture;
Relevant Value Stack;
ObjectionResponsePlan;
Negotiation Decision;
Decision Feedback Brief;
material changes.

Histórico não deve ser reescrito silenciosamente.

71. Auditoria

Eventos materiais devem produzir Audit Event ou equivalente:

debrief criado;
debrief revisado;
friction criada/alterada;
response plan aprovado;
concessão solicitada;
concessão aprovada/rejeitada;
material change identificado;
rota alterada;
Decision Unit atualizada;
decisão registrada.

72. Proveniência de IA

Conteúdo gerado por IA deve permitir identificar:

modelo/serviço quando aplicável;
timestamp;
inputs/context package relevante;
campos gerados;
confiança/limitações quando aplicável;
revisão humana;
versão após edição humana.

73. Human Review proporcional

Revisão humana é obrigatória para:

concessão fora de authority;
alteração material de pricing;
claim material novo;
mudança de promise;
mudança de fit;
informação sensível;
conteúdo comparativo sobre concorrente;
decisão de rotear para fechamento quando houver conflito material de evidência.

74. UX — One-Page First

A tela principal do E5 deve priorizar:

estado da decisão;
o que o cliente disse;
principais fricções/gaps;
Relevant Value Stack;
CRR preparado;
perguntas abertas;
boundaries;
próximo contato humano.

Evidências e histórico ficam disponíveis sob demanda.

75. Empty states

Sem debrief

Mostrar:

“Registre o que aconteceu na apresentação para preparar o próximo ciclo de decisão.”

Não inferir resultado.

Sem objeções

Mostrar:

“Nenhuma objeção explícita registrada. Verifique estado da decisão, compromissos e gaps antes de preparar follow-up.”

Sem fricção conhecida

Mostrar:

“A fricção ainda é desconhecida. Prepare perguntas abertas antes de concluir o motivo.”

76. Loading states

Durante processamento assistido por IA:

indicar análise em andamento;
não bloquear edição de fatos já registrados quando tecnicamente possível;
diferenciar conteúdo salvo de sugestão ainda não persistida;
permitir retry seguro;
não duplicar objetos em reprocessamento.

77. Error states

Em falha:

preservar dados já salvos;
não inventar classificação;
permitir edição manual;
registrar erro técnico sem expor dado sensível indevidamente;
manter retry idempotente quando possível.

78. Edge case — debrief incompleto

Se faltarem informações essenciais:

salvar draft;
marcar gaps;
não gerar conclusão definitiva;
permitir geração parcial claramente rotulada;
solicitar revisão humana antes do próximo ciclo quando necessário.

79. Edge case — sellers discordam

Se duas pessoas presentes registrarem interpretações diferentes:

preservar ambas como Observation;
manter Customer Statements separados;
não resolver conflito por votação automática;
permitir Human Review;
gerar Gap se necessário.

80. Edge case — cliente pede Protected HOW

Se o cliente solicitar detalhes que cruzem o Knowledge Disclosure Boundary:

não responder automaticamente;
identificar informação segura para explicar decisão;
preservar IP;
escalar quando necessário;
nunca usar recusa como pressão comercial.

81. Edge case — desconto fora do limite

Resultado:

REQUESTED_CONCESSION
      ↓
OUTSIDE_BOUNDARY
      ↓
HUMAN_REVIEW_REQUIRED

Nenhum preço novo é apresentado antes da aprovação aplicável.

82. Edge case — necessidade mudou

Se a conversa revelar que a necessidade isolada não representa mais a realidade:

MATERIAL NEED CHANGE
      ↓
RETURN E2

E5 não tenta vender a solução antiga para a nova necessidade.

83. Edge case — novo escopo

Se o cliente pedir solução adicional:

NEW SCOPE
   ↓
E3 Responsible Solution Fit

Não inserir silenciosamente no documento comercial.

84. Edge case — proposta expirou

Se a Proposal Version ou condição comercial expirar:

bloquear reutilização automática de preço/condição;
solicitar atualização de Commercial Configuration;
revalidar capacidade quando aplicável;
gerar nova Proposal Version antes de comunicação.

85. Edge case — cliente não responde

Silêncio não possui interpretação automática.

Registrar:

último commitment;
prazo combinado;
tentativas realizadas;
ausência de resposta como evento;
gaps.

E6 poderá aprofundar No-Decision Intelligence.

86. Edge case — repetição de “vamos pensar”

Não gerar automaticamente nova técnica de fechamento.

Preparar pergunta aberta proporcional, por exemplo:

“O que vocês entendem que ainda precisa ser avaliado antes de tomar uma decisão?”

Se não houver commitment ou evidência nova, E6 deve tratar o estado de no-decision/momentum.

87. Edge case — objeção baseada em premissa falsa

No CRR:

CONCORDA com a legitimidade de verificar;
REFORÇA o critério de decisão;
REITERA fatos/evidências corretos;
faz PERGUNTA ABERTA;
não concorda com informação falsa apenas para gerar rapport.

88. Métricas candidatas

Sem metas aprovadas:

tempo entre apresentação e debrief;
ciclos E5 por oportunidade;
percentual de debriefs completos;
fricções confirmadas vs hipotéticas;
material changes detectadas;
concessões dentro/fora de authority;
retorno E2/E3/E4;
commitments com owner/date;
decisão após ciclo E5;
no-decision;
esforço humano por ciclo.

Essas métricas não provam causalidade ou aumento de conversão.

89. Learnings

E5 deve alimentar Learning Registry com candidatos como:

objeções recorrentes;
gaps de comunicação;
claims que geram dúvida;
conditions que geram fricção;
padrões de authority não mapeados;
USFs que são percebidas como relevantes;
gaps do Offer Passport;
material changes recorrentes;
pontos do processo que geram atraso.

Um caso não vira regra universal.

90. Offer Reality Loop

E5 pode gerar sinais para E0.SALES:

promessa mal compreendida;
benefício pouco claro;
objeção recorrente de capacidade;
condição comercial inadequada;
USP pouco sustentada;
USF1/USF2 pouco relevante;
gap de evidência;
configuração que exige revisão.

Isso pode gerar OfferChangeProposal, nunca alterar a Offer Version retroativamente.

91. Feedback para E4

E5 pode devolver:

narrativa confusa;
apresentação inadequada ao Decision Communication Profile;
informação excessiva;
falta de clareza de investimento;
detalhe insuficiente;
Decision Ask inadequado;
Knowledge Disclosure Boundary mal aplicado.

E4 pode evoluir por learning, preservando histórico.

92. Feedback para E2

E5 pode revelar:

necessidade mal isolada;
impacto não reconhecido;
Desired Future diferente;
prioridade alterada;
novo stakeholder relevante.

Quando material, retornar E2.

93. Feedback para E3

E5 pode revelar:

fit parcial não percebido;
prerequisite ausente;
capability incompatível;
novo risco;
nova condição;
nova solução necessária.

Quando material, retornar E3.

94. Handoff para E6

E5 termina quando existe ao menos um dos seguintes:

decisão explícita;
commitment explícito que transfere o caso para acompanhamento de momentum;
no-decision suficientemente caracterizado para acompanhamento;
rejeição explícita;
aceite explícito.

Pacote de handoff:

E6 Handoff
 
Current Decision State
Proposal Version
Decision Unit
Customer Statements
Confirmed Frictions
Open Gaps
Commitments
Negotiation Decisions
Material Change History
Last Human Contact
Next Expected Event
Learning Candidates

95. Minimum Viable E5 Slice

Para o MVP, o E5 precisa no mínimo permitir:

registrar Presentation Debrief;
separar Customer Statement, Observation, Hypothesis e Gap;
registrar Surface Objection;
sugerir/registrar Decision Friction como hipótese;
consumir USF1 + USF2 + USP já governados;
gerar Relevant Value Stack;
preparar CRR + perguntas abertas;
consultar Negotiation Boundary Package;
registrar requested concession;
rotear material change;
registrar commitment;
gerar Decision Feedback Brief;
encerrar/rotear ciclo para E2/E3/E4/E6;
preservar auditoria, RLS e versionamento.

96. Incrementos sugeridos

Incremento 1 — Debrief & epistemologia

Presentation Debrief;
statements;
observations;
hypotheses;
gaps;
decision state.

Incremento 2 — Friction Intelligence

Surface Objection;
Decision Friction;
open questions;
Human Review.

Incremento 3 — Value & CRR

Organization/Offer Value Architecture;
Relevant Value Stack;
CRR preparation;
Knowledge Disclosure guardrail.

Incremento 4 — Negotiation & Routing

boundaries;
concessions;
material change;
routes.

Incremento 5 — Feedback Cycle & E6 handoff

Decision Feedback Brief;
cycles;
commitments;
handoff.

97. Critérios de aceite arquiteturais

98. Critérios de aceite técnicos candidatos

99. Fora do Minimum Viable E5 Slice

Não exigir automaticamente no MVP:

gravação de reunião;
emotion recognition;
análise facial;
voice sentiment;
live copilot;
live whisper;
recommendation engine de fechamento;
next-best-action probabilístico;
automated discount optimization;
competitor intelligence em tempo real;
buyer intent scoring proprietário;
persuasion scoring;
buyer confidence numérico;
automação de mensagens em massa;
cadência CRM completa.

100. Glossário

Termo	Definição
Presentation Debrief	registro estruturado pós-apresentação
Surface Objection	manifestação explícita do cliente
Decision Friction	hipótese/evidência sobre o que dificulta a decisão
CRR	Concorda → Reforça → Reitera
Open Question	pergunta aberta obrigatória após CRR
USF1	dimensão tangível de valor
USF2	valor intangível da forma de entrega sem revelar HOW protegido
USP	síntese diferencial sustentada
Relevant Value Stack	seleção relevante de Need, Promise, USF1, USF2, USP e Evidence
Position	pedido ou posição declarada
Interest	motivo subjacente confirmado/evidenciado
Negotiation Boundary	limite autorizado de negociação
Material Change	mudança que exige retorno a E2/E3/E4 ou revisão
Decision Feedback Brief	One-Page de preparação para próximo contato humano
Decision Feedback Cycle	ciclo de interação humana → debrief → inteligência → nova interação

101. Invariantes finais

Apresentação presencial pertence ao E4.
Orquestro é alimentado depois da apresentação.
Se fechou na apresentação, E5 pode ser bypassado.
Se não fechou, o debrief inicia E5.
Objeção é informação antes de negociação.
Toda preparação de resposta usa Concorda → Reforça → Reitera → Pergunta Aberta.
Perguntas abertas são o padrão investigativo do E5.
USF1 + USF2 + USP vêm de arquitetura de valor conhecida e governada.
Relevant Value Stack é contextual; não existe empilhamento indiscriminado.
USF2 comunica valor do HOW sem entregar Protected Know-How.
Interesse vem antes de concessão.
E5 negocia somente dentro dos boundaries autorizados.
Material change reabre a etapa correta.
Comportamento observado vence inferência anterior.
Silêncio não é resposta.
NO é decisão válida.
O sistema prepara; a pessoa conversa.
Cada contato humano deve poder produzir conhecimento novo.
Um caso não vira regra universal.
A próxima conversa deve ser melhor porque o sistema aprendeu com a anterior.

102. Arquitetura consolidada do E5

E4 — DECISION & COMMUNICATION
           ↓
Proposal Ready
           ↓
PRESENTAÇÃO PRESENCIAL / HUMANA
           ↓
Listen / Discuss / Observe
           ↓
Decision?
     ↙             ↘
  ACCEPTED          NOT YET
     ↓                 ↓
Proposal Sent      Proposal Sent
     ↓                 ↓
    E6        PRESENTATION DEBRIEF
                       ↓
          E5.1 — DEBRIEF INTELLIGENCE
                       ↓
          E5.2 — FRICTION INTELLIGENCE
                       ↓
    Customer Need Truth + Responsible Promise
                       +
             USF1 + USF2 + USP
                       ↓
             RELEVANT VALUE STACK
                       ↓
          E5.3 — CRR + OPEN QUESTIONS
                       ↓
             NEGOTIATION BOUNDARIES
                       ↓
              DECISION FEEDBACK BRIEF
                       ↓
                HUMAN FOLLOW-UP
                       ↓
                    LISTEN
                       ↓
                    DEBRIEF
                       ↓
           MATERIAL CHANGE CLASSIFIER
                 ↙     ↓      ↘
               E2     E3      E4
                       │
                 no material change
                       ↓
                  CONTINUE E5
                       ↺
                       ↓
              DECISION / COMMITMENT
                       ↓
            E6 — MOMENTUM, OUTCOME
                 & LEARNING

103. Resultado esperado

O E5 deve permitir que uma organização passe de:

“Apresentamos a proposta e agora vamos tentar convencer o cliente.”

para:

“Apresentamos presencialmente, ouvimos, estruturamos o que aprendemos, entendemos o que ainda impede a decisão, preparamos a próxima conversa com base em verdade, valor e limites autorizados, voltamos a ouvir e registramos a decisão ou o aprendizado.”

Esse é o papel do E5 dentro do Orquestro™.

E6 — Decision Outcome, Handoff & Commercial Learning v0.1

Fonte incorporada integralmente: Orquestro_E6_Decision_Outcome_Handoff_Commercial_Learning_v0.1_2026-08-22.md

Orquestro E6 — Decision Outcome, Handoff & Commercial Learning

Definição funcional: Resolve, Handoff, Observe, Learn & Reuse
Versão: 0.1
Data: 22/08/2026
Status: baseline arquitetural aprovada para especificação e desenvolvimento incremental
Classificação: etapa especializada do Orquestro™
Escopo do documento: arquitetura funcional, conhecimento, experiência, dados, governança, handoff e Minimum Viable E6 Slice
Fundação obrigatória: E0.CORE + E0.SALES + E1 + E2 + E3 Responsible Solution Fit + E4 Decision & Communication + E5 Decision Conversation & Feedback Intelligence
Fonte metodológica aplicada: Product Markdown Rail
Próximo marco: consolidação do Orquestro™ v0.3

Aviso de maturidade: este documento define a arquitetura pretendida do E6. Não comprova que os fluxos, objetos, IA, integrações de delivery, métricas de valor, learning loops ou automações estejam implementados, validados ou prontos para produção.

1. Finalidade do documento

Este documento especifica o E6 — Decision Outcome, Handoff & Commercial Learning, etapa responsável por registrar a resolução comercial, impedir que oportunidades encerradas permaneçam artificialmente abertas, preservar a verdade contratada, transferir conhecimento relevante para delivery, observar sinais mínimos de valor e transformar evidências de ganhos, perdas, adiamentos e entregas em learning governado.

O E6 deve orientar:

produto;
arquitetura de conhecimento;
encerramento comercial;
handoff Sales-to-Delivery;
Offer Reality Loop;
Value Reality Chain;
Commercial Learning;
reativação futura;
Human Review;
modelagem de dados;
auditoria e versionamento;
desenvolvimento assistido por IA;
testes e pilotos;
consolidação da jornada E0–E6.

Este é um documento de arquitetura e especificação modular. Funcionalidades técnicas menores deverão gerar PRDs próprios conforme o Product Markdown Rail.

2. Decisão arquitetural aprovada

Decisão:

O momentum ativo de decisão pertence ao E5. O E6 começa quando existe uma decisão comercial, um encerramento explícito ou um estado estacionado governado.

Logo, o E6 não duplica follow-up, não mantém oportunidades indefinidamente abertas e não executa negociação ativa.

E5 — Decision Conversation
        ↓
Existe compromisso ativo e legítimo?
   ↙                    ↘
 YES                     NO / DECISION
  ↓                           ↓
permanece E5          E6 — Decision Outcome,
                     Handoff & Commercial Learning

3. Tese central

Fechar uma venda produz receita. Entender por que ela foi ganha ou perdida produz conhecimento. Comparar o que foi prometido com o que foi entregue e valorizado produz inteligência.

Princípio adicional do Sales Intelligence:

Quem aprende com cada decisão vende melhor a próxima.

O E6 fecha o ciclo:

KNOW → DECIDE → TRANSFORM → SUSTAIN → LEARN → KNOW

4. O que o E6 é

O E6 é:

resolução governada do estado comercial;
memória de ganho, perda, adiamento, no-decision ou retirada;
separação entre motivo declarado, observação, hipótese e gap;
mecanismo de prevenção de oportunidade zumbi;
ponte de verdade entre Sales e Delivery;
preservação do que foi efetivamente contratado;
mecanismo mínimo de Outcome & Value Intelligence;
Offer Reality Loop;
sistema de Commercial Learning;
mecanismo de reativação baseada em revalidação;
fonte de propostas de mudança para ofertas, metodologia e Engine;
etapa final do Sales Intelligence antes da consolidação do learning no Core.

5. O que o E6 não é

Não é:

CRM completo;
cadência infinita de follow-up;
automação de cobrança de resposta;
customer success completo;
project management de delivery;
ERP de contratos;
faturamento;
contabilidade;
medição causal automática;
motor de renovação automática;
sistema de atribuição perfeita de resultado;
mecanismo que transforma WON em prova de valor;
mecanismo que transforma LOST em prova de ausência de valor;
learning automático sem revisão humana;
autorização para alterar silenciosamente oferta, metodologia ou Engine;
substituto de Customer & Value Intelligence em profundidade futura.

6. Fronteira E5 → E6

6.1 Permanece em E5 quando

Existe um próximo compromisso comercial real, por exemplo:

nova reunião marcada;
decisão com data combinada;
documento específico a ser analisado;
decisor adicional a ser envolvido;
informação objetiva pendente;
contraproposta autorizada em elaboração;
condição comercial ativa dentro do ciclo decisório.

6.2 Vai para E6 quando

Existe:

aceite;
rejeição;
adiamento com condição clara;
no-decision sem próximo compromisso legítimo;
retirada pelo seller;
fechamento sem oportunidade;
no-fit;
encerramento explícito de ciclo.

6.3 Regra

Decision Pending só é estado ativo enquanto existir um próximo compromisso legítimo e rastreável.

7. Estados comerciais governados

Estados conceituais do encerramento:

WON;
LOST;
POSTPONED;
NO_DECISION;
WITHDRAWN_BY_SELLER;
CLOSED_NO_OPPORTUNITY;
NO_FIT;
UNKNOWN somente como estado transitório de dado incompleto, nunca como encerramento desejado.

ADVANCING, DECISION_PENDING e ciclos de feedback permanecem em E5.

8. Princípio anti-zombie opportunity

Uma oportunidade não pode permanecer aberta apenas porque o seller não quer registrar perda ou ausência de decisão.

Sem decisão
+
sem compromisso ativo
+
sem trigger governado
=
NO_DECISION / closure

O produto deve favorecer verdade comercial sobre aparência de pipeline.

9. Arquitetura do E6 em quatro movimentos

E6.1 — Decision Resolution
           ↓
E6.2 — Commercial-to-Delivery Handoff
           ↓
E6.3 — Outcome & Value Intelligence
           ↓
E6.4 — Commercial Learning
           ↓
Feedback Loops

Nem todo caso percorre todos os movimentos.

10. Rotas por outcome

WON

Decision Resolution
→ Contracted Promise Snapshot
→ Delivery Handoff
→ Outcome & Value Signals
→ Commercial Learning

LOST

Decision Resolution
→ Win/Loss Intelligence
→ Commercial Learning

POSTPONED

Decision Resolution
→ Reactivation Trigger
→ Closure
→ Commercial Learning, quando houver evidência útil

NO_DECISION

Decision Resolution
→ No-Decision Intelligence
→ Closure
→ Commercial Learning

WITHDRAWN / NO_FIT / CLOSED_NO_OPPORTUNITY

Decision Resolution
→ Closure Reason
→ Commercial Learning

11. E6.1 — Decision Resolution

Objetivo:

registrar o que realmente foi decidido, quando, por quem, com qual proposta/configuração e com qual base de evidência.

O E6 não deve reconstruir retrospectivamente a história para justificar o outcome.

12. Decision Outcome Record

Conteúdo conceitual:

DecisionOutcome
- opportunity_id
- outcome_state
- decided_at
- proposal_version_id
- commercial_configuration_snapshot_id
- decision_unit_snapshot
- customer_stated_reason
- structured_reason_category
- seller_observations
- engine_hypotheses
- gaps
- evidence_refs
- conditions
- commitments
- reactivation_trigger
- human_review_refs
- created_by
- created_at

A representação física final depende do Domain Model aprovado.

O sistema pode oferecer categorias estruturadas, mas deve preservar a fonte.

Exemplo:

Customer Statement:
"Não vamos avançar agora porque a equipe está focada no ERP."
 
Structured Category:
TIMING / IMPLEMENTATION_CAPACITY
 
Seller Observation:
O tema financeiro não apareceu na conversa.
 
Engine Hypothesis:
Capacidade interna pode ser o principal bloqueio.
 
Status:
HYPOTHESIS

14. Tipos conceituais de Outcome Reason

Candidatos, não lista exaustiva:

VALUE_CLARITY;
ECONOMIC;
BUDGET;
CASH_FLOW;
TIMING;
PRIORITY;
IMPLEMENTATION_CAPACITY;
AUTHORITY;
CONSENSUS;
SCOPE;
TECHNICAL;
RISK;
TRUST;
COMPETITOR;
INTERNAL_ALTERNATIVE;
NO_NEED;
NO_FIT;
NO_DECISION;
UNKNOWN.

A categoria nunca substitui o Customer Statement original.

15. Epistemologia obrigatória no outcome

Preservar:

CUSTOMER STATEMENT / FACT;
SELLER OBSERVATION;
ENGINE HYPOTHESIS;
GAP;
EVIDENCE.

Regra:

Nenhum motivo de ganho ou perda inferido pode ser apresentado como motivo declarado pelo cliente.

16. WON

WON significa que existe aceite comercial suficiente para avançar à contratação ou execução conforme a governança da organização.

WON não significa automaticamente:

contrato assinado, salvo se essa for a regra da empresa;
pagamento recebido;
revenue recognized;
delivery iniciado;
valor entregue;
resultado realizado;
renovação futura.

Esses eventos devem permanecer distintos.

17. Price Proposed ≠ Price Accepted ≠ Price Paid

O sistema deve distinguir, quando aplicável:

Price Proposed
Price Presented
Price Negotiated
Price Accepted
Price Contracted
Price Paid

A profundidade financeira do MVP pode ser limitada, mas não deve colapsar conceitos diferentes em um único campo quando a distinção for material.

18. LOST

LOST significa decisão comercial negativa suficientemente clara.

O sistema deve registrar:

razão declarada, se houver;
Decision Unit envolvida;
Proposal Version;
Commercial Configuration;
principais Decision Frictions conhecidas;
competing alternative, somente se conhecida;
gaps;
possibilidade de reativação, se explicitamente sustentada;
learnings candidatos.

19. LOST não significa No Value

Regra estrutural:

Uma decisão comercial negativa não prova ausência de valor.

Uma empresa pode:

reconhecer valor anterior e não renovar;
reconhecer qualidade e escolher timing diferente;
ter necessidade e não possuir capacidade;
perceber valor e preferir alternativa interna;
não comprar por condição financeira.

Logo, Commercial Outcome e Value Outcome permanecem separados.

20. POSTPONED

POSTPONED exige condição de retomada minimamente concreta.

Conteúdo mínimo:

razão;
reactivation trigger;
janela estimada, se declarada;
owner;
evidence;
condição de revalidação.

Exemplo válido:

“Retomar após conclusão da implantação do ERP, prevista para fevereiro.”

21. POSTPONED sem trigger não é POSTPONED

Se não existe condição, janela, trigger ou compromisso minimamente identificável:

"Vamos pensar e qualquer coisa falamos."

não deve permanecer como POSTPONED indefinidamente.

Após o encerramento dos ciclos legítimos de E5, deve ser tratado como NO_DECISION.

22. NO_DECISION

NO_DECISION representa encerramento sem decisão positiva ou negativa e sem próximo compromisso comercial legítimo.

Pode coexistir com:

interesse anterior;
proposta apresentada;
fit aparente;
relacionamento positivo;
ausência de prioridade;
silêncio;
decisão interna não concluída.

O sistema não deve inventar a causa.

23. WITHDRAWN_BY_SELLER

O seller pode retirar a oportunidade por razões legítimas:

risco;
falta de capacidade;
desalinhamento ético;
condições comerciais inadequadas;
no-fit detectado depois;
mudança de estratégia;
informação material nova.

Retirada responsável é uma decisão comercial válida.

24. CLOSED_NO_OPPORTUNITY

Usado quando o ciclo conclui que não deveria existir oportunidade comercial naquele momento.

Pode originar-se de:

Opportunity Gate DO NOT CREATE;
reavaliação posterior;
need rejeitada;
inexistência de fit legítimo.

Não deve ser tratado como venda perdida equivalente a LOST.

25. NO_FIT

NO_FIT registra que houve necessidade/oportunidade potencial, mas nenhuma oferta responsável deve ser realizada ou mantida.

Esse outcome é importante para:

Anti-Fit Patterns;
Offer Reality Loop;
ICP/Anti-ICP;
gaps de capacidade;
proteção de qualidade;
Responsible No-Sell.

26. UNKNOWN

UNKNOWN pode ser usado apenas quando o dado ainda não foi processado ou migrado.

Não deve ser estado final desejado para oportunidades encerradas.

Se o motivo é desconhecido, registrar:

outcome_state = LOST / NO_DECISION / etc.
reason = UNKNOWN

sem inventar motivo.

27. Decision Unit Snapshot

A resolução deve preservar quem participou da decisão naquele momento:

Decision Owner;
Economic Approver;
Technical Evaluator;
Sponsor;
Influencer;
Blocker, se evidenciado;
Resource Owner;
Implementation Owner;
outros papéis contextuais.

Papéis são contextuais à decisão e versionados.

28. Decision Evidence Package

O outcome deve poder retornar a:

apresentação realizada;
Proposal Version;
Customer Statements;
mensagens;
reuniões/debriefs;
aprovações;
documentos;
Decision Ask;
commitments;
Human Reviews.

Sem evidência disponível, declarar limitação.

29. E6.2 — Commercial-to-Delivery Handoff

Aplicável principalmente a WON.

Objetivo:

preservar a verdade comercial que precisa chegar a quem executará a entrega, sem depender da memória do seller ou apenas do PDF da proposta.

30. Risco central — Sales-to-Delivery Drift

O drift ocorre quando:

Sales vende A
Delivery entende B
Cliente espera C

O Orquestro deve reduzir esse risco preservando a cadeia:

Need Truth
→ Promise
→ Proposal
→ Contracted Truth
→ Delivery Handoff

31. Contracted Promise Snapshot

Novo artefato governado aprovado conceitualmente:

snapshot imutável da verdade comercial contratada para aquela decisão.

Ele não substitui o contrato jurídico.

Ele preserva a referência operacional do que foi efetivamente acordado.

32. Conteúdo do Contracted Promise Snapshot

Contracted Promise Snapshot
 
Customer Need Truth Snapshot
Need Version
Responsible Commercial Promise
Offer
Offer Version
Proposal Version
Final Scope
Included Components
Excluded Components
Customer Prerequisites
Seller Responsibilities
Fit Conditions
Commercial Conditions
Price Accepted / Contracted
Payment Terms
Timeline Basis
Relevant Claims
Relevant Boundaries
Risks
Dependencies
Success / Outcome Hypotheses
Decision Unit / Approvers
Decision Date
Evidence References
Version / Timestamp

33. Contracted Promise Snapshot é imutável

Uma vez formalizado para aquela contratação:

não deve ser sobrescrito;
mudanças posteriores geram nova versão, change record ou novo acordo conforme governança;
o snapshot original permanece consultável;
o sistema não pode reescrever o passado para parecer aderente ao que acabou sendo entregue.

34. Proposal ≠ Contracted Promise

A proposta representa a configuração oferecida/apresentada.

O Contracted Promise Snapshot representa o que foi efetivamente acordado após eventuais alterações autorizadas.

Se não houve alteração:

Proposal Version
≈
Contracted Promise Snapshot

Ainda assim são papéis conceituais diferentes.

35. Contracted Promise ≠ Contract

O Orquestro não substitui:

contrato;
assinatura eletrônica;
instrumento jurídico;
faturamento;
ordem de compra.

Pode guardar referências a esses artefatos, quando disponíveis e autorizadas.

36. Delivery Handoff Package

Saída governada para execução:

Delivery Handoff Package
 
Why the customer bought
Customer Need Truth
Responsible Commercial Promise
Contracted Promise Snapshot
Included Scope
Excluded Scope
Customer Prerequisites
Seller / Delivery Responsibilities
Known Risks
Known Dependencies
Decision Unit / Stakeholders
Relevant Communication Context
Expected Outcome Hypotheses
What was NOT promised
Evidence References

One-Page First + Evidence on Demand.

37. Why the customer bought

Essa informação deve distinguir:

razão declarada pelo cliente;
interpretação do seller;
hipótese da Engine.

Não criar narrativa motivacional retrospectiva sem evidência.

38. What was NOT promised

Campo explícito aprovado.

Objetivo:

proteger escopo;
reduzir expectation drift;
preservar boundaries;
apoiar implementação;
reduzir claims indevidos;
melhorar eventual análise de valor.

39. Handoff não transfere todo o conhecimento sensível

O Delivery Handoff deve respeitar:

tenant;
função;
need-to-know;
finalidade;
minimização de dados;
Knowledge Disclosure Boundary;
informações pessoais/sensíveis.

Nem todo detalhe comercial ou comportamental precisa ser repassado à execução.

40. Human Review do handoff

Quando houver alto risco, customização, condição excepcional ou conflito entre proposta e contratado:

HANDOFF REVIEW REQUIRED

O review deve confirmar:

scope;
promise;
pricing/config, quando aplicável;
prerequisites;
exclusions;
claims;
riscos;
responsáveis.

41. Delivery Acceptance of Handoff

Conceito candidato:

A equipe/responsável de delivery pode confirmar que recebeu e compreendeu o pacote.

Status conceituais:

RECEIVED;
REVIEW_REQUIRED;
ACCEPTED_FOR_DELIVERY;
CONFLICT_FOUND.

Não exige workflow complexo no MVP inicial.

42. Conflito detectado no handoff

Se delivery identifica:

scope impossível;
promise não suportada;
dependência ausente;
preço/configuração incompatível;
expectativa divergente;

não deve corrigir silenciosamente.

Criar:

Delivery Handoff Conflict
→ Human Review
→ Commercial / Delivery Resolution
→ versioned correction if applicable

O snapshot original permanece preservado.

43. E6.3 — Outcome & Value Intelligence

Objetivo:

distinguir o resultado comercial do valor efetivamente percebido ou realizado, preservando causalidade e limitações de evidência.

44. Value Reality Chain

Arquitetura conceitual aprovada:

PROMISED
    ↓
CONTRACTED
    ↓
DELIVERED
    ↓
PERCEIVED
    ↓
REALIZED
    ↓
ATTRIBUTION / CONTRIBUTION

Cada camada responde a pergunta diferente.

45. PROMISED

Pergunta:

o que responsavelmente dissemos que pretendíamos produzir?

Fonte principal:

Responsible Commercial Promise;
Claims autorizados;
E3/E4.

46. CONTRACTED

Pergunta:

o que foi efetivamente acordado?

Fonte principal:

Contracted Promise Snapshot;
contrato/instrumento referenciado, quando aplicável.

47. DELIVERED

Pergunta:

o que foi efetivamente entregue?

Pode incluir:

entregáveis concluídos;
atividades realizadas;
componentes implantados;
marcos;
evidências de execução.

Sales não precisa possuir o delivery, apenas receber sinais mínimos governados para aprender.

48. PERCEIVED

Pergunta:

que valor o cliente declara ter percebido?

Exemplos:

Customer Statement;
feedback;
depoimento;
renovação acompanhada de razão declarada;
uso percebido.

Perceived Value não é automaticamente Realized Outcome.

49. REALIZED

Pergunta:

que mudança observável ocorreu?

Pode incluir:

indicador;
tempo;
custo;
redução de erro;
aumento de aderência;
mudança operacional;
evidência qualitativa suficientemente estruturada.

Realized Outcome não implica causalidade exclusiva.

50. ATTRIBUTION / CONTRIBUTION

Pergunta:

quanto podemos responsavelmente atribuir ou associar a mudança à solução?

Estados conceituais candidatos:

UNKNOWN;
PLAUSIBLE_CONTRIBUTION;
PARTIALLY_SUPPORTED;
SUPPORTED.

Não usar score numérico arbitrário.

51. Causalidade protegida

Exemplo:

Observed:
Receita aumentou 30%.

Não autoriza:

Claim:
Nossa solução aumentou a receita em 30%.

sem desenho/evidência suficiente.

O sistema deve preferir linguagem de contribuição quando causalidade não estiver demonstrada.

52. Commercial Outcome ≠ Value Outcome

Dois eixos independentes:

Commercial Outcome:
WON / LOST / POSTPONED / NO_DECISION / etc.
 
Value Outcome:
UNKNOWN / PERCEIVED / OBSERVED / etc.

Possibilidades legítimas:

WON + UNKNOWN VALUE;
WON + LOW/WEAK VALUE EVIDENCE;
WON + STRONGER VALUE EVIDENCE;
LOST + POSITIVE PREVIOUS VALUE EVIDENCE;
LOST + UNKNOWN VALUE.

Evitar enums finais de intensidade antes de decisão técnica/metodológica.

53. Value Delivered ≠ Renewal Won

Learning já sustentado por evidência limitada de um caso e elevado a princípio de cautela:

Valor entregue e decisão de renovação são fenômenos relacionados, mas não equivalentes.

Logo:

renewal WON não prova valor realizado;
renewal LOST não prova ausência de valor;
valor percebido deve ser registrado separadamente;
razões de renovação precisam ser investigadas como qualquer outra decisão.

54. Offer Reality Loop

O E6 operacionaliza o loop iniciado em E0.SALES:

OFFER SAID
    ↓
SELLER PROMISED
    ↓
CUSTOMER CONTRACTED
    ↓
DELIVERY EXECUTED
    ↓
CUSTOMER PERCEIVED
    ↓
OUTCOME OBSERVED

O objetivo é detectar diferença, não punir automaticamente.

55. Tipos conceituais de drift

Candidatos:

OFFER_DRIFT;
PROMISE_DRIFT;
CONTRACT_DRIFT;
DELIVERY_DRIFT;
EXPECTATION_DRIFT;
VALUE_GAP.

Todo drift exige contexto e evidência.

56. OFFER_DRIFT

A oferta oficial diz uma coisa, mas as configurações comercializadas repetidamente passam a ser outra.

Pode indicar:

OfferVersion desatualizada;
boundary inadequado;
novo need pattern;
customização recorrente;
necessidade de Offer Change Proposal.

57. PROMISE_DRIFT

O seller prometeu algo diferente ou mais amplo que o autorizado.

Pode gerar:

risk;
Human Review;
learning;
ajuste de treinamento;
mudança de guardrail.

Não reescrever o histórico.

58. DELIVERY_DRIFT

O delivery executou algo materialmente diferente do contratado.

Pode ocorrer por:

necessidade legítima de mudança;
erro de handoff;
mudança não versionada;
capacidade;
escopo;
pedido do cliente.

Exige distinguir mudança autorizada de drift indevido.

59. VALUE_GAP

Existe distância relevante entre:

promessa;
percepção;
resultado observado.

Um Value Gap não prova automaticamente falha da oferta. Pode envolver:

implementação incompleta;
prerequisite ausente;
expectativa incorreta;
contexto externo;
medição insuficiente;
outcome de longo prazo;
promise exagerada.

60. Outcome Evidence

Tipos de evidência possíveis:

Customer Statement;
contrato / pedido / aceite;
evidência de entrega;
indicador;
feedback;
documento;
e-mail/mensagem;
reunião;
avaliação humana;
output de sistema externo, quando autorizado.

O E6 deve preservar origem, período e limitações.

61. Outcome timing

Nem todo outcome pode ser medido imediatamente.

Registrar:

expected observation window;
actual observation date;
data source;
limitation;
status.

Não inventar resultado porque o projeto terminou.

62. Outcome Status conceitual

Candidatos:

NOT_EXPECTED_YET;
NOT_MEASURED;
EVIDENCE_INCOMPLETE;
OBSERVED;
NOT_OBSERVED;
UNKNOWN.

Não confundir NOT_MEASURED com NO_VALUE.

63. E6.4 — Commercial Learning

Objetivo:

transformar evidência de um caso em learning candidate governado e somente promover mudança quando houver revisão, suporte e decisão explícita.

64. Evidence → Learning → Proposed Change → Decision → Version

Fluxo obrigatório:

EVIDENCE
   ↓
LEARNING CANDIDATE
   ↓
HUMAN REVIEW
   ↓
STRENGTHEN / WEAKEN / REJECT
   ↓
PROPOSED CHANGE
   ↓
DECISION
   ↓
VERSION

Nenhum case altera silenciosamente a metodologia.

65. Learning Candidate

Conteúdo conceitual:

LearningCandidate
- statement
- source_case
- evidence_refs
- scope
- confidence / maturity status
- contradiction_refs
- affected_stage
- possible_implication
- reviewer
- status
- created_at

66. Estados de learning

Alinhados à governança vigente:

NOT_TESTED;
IN_TEST;
STRENGTHENED;
WEAKENED;
REJECTED;
PROVISIONALLY_VALIDATED.

Quando relevante, registrar também contagem/contexto de casos sem transformar contagem isolada em validade estatística.

67. Um caso não vira regra universal

Exemplo:

Evidence:
Decision Ask avançar/encerrar gerou resposta clara em CTM.
 
Learning Candidate:
Em oportunidades maduras e estagnadas, uma escolha explícita entre avançar ou encerrar pode reduzir inércia.
 
Status:
STRENGTHENED BY ONE CASE

Não:

GLOBAL RULE:
sempre use decisão binária.

68. Learnings de WON

O sistema deve aprender também com vendas ganhas.

Perguntas:

o cliente declarou por que escolheu?
que necessidade foi decisiva?
que evidência trouxe segurança?
que fator de valor foi reconhecido?
qual Decision Communication Profile funcionou no contexto?
que objeção foi resolvida?
houve concessão?
houve surprise / unexpected driver?

Razão de ganho inferida permanece hipótese.

69. Learnings de LOST

Perguntas:

qual razão foi declarada?
que fricção permaneceu?
existia fit real?
preço foi causa declarada ou suposição?
havia capacidade?
havia autoridade?
outro decisor apareceu tarde?
houve promessa inadequada?
houve problema de comunicação?
havia alternativa legítima melhor?

Não usar learning para culpar seller ou cliente automaticamente.

70. Learnings de NO_DECISION

No-decision pode revelar:

baixa prioridade;
baixa clareza de valor;
Decision Unit incompleta;
ausência de urgency legítima;
complexidade decisória;
gap de evidência;
timing;
processo interno desconhecido.

Tudo isso permanece hipótese até evidência suficiente.

71. Learnings de NO_FIT

Podem fortalecer:

Anti-Fit Pattern;
Customer Prerequisite;
Seller Constraint;
Offer Gap;
Capability Gap;
Need Pattern;
ICP / Anti-ICP;
Responsible No-Sell.

No-fit bem registrado é conhecimento útil.

72. Destinos possíveis do learning

Learning	Pode alimentar
ICP / Anti-ICP	E1
Need Pattern	E2
Discovery Question Pattern	E2
Fit Pattern	E3
Anti-Fit	E0.SALES / E3
Offer / Capability	E0.SALES
USF1 / USF2 / USP	E0.SALES
Pricing hypothesis	E0.SALES / Finance
Customer Prerequisite	E0.SALES
Seller Constraint	E0.SALES
Proposal architecture	E4
Decision Communication pattern	E4
Objection / Friction pattern	E5
Negotiation boundary	E0.SALES / E5
Promise integrity	E3
Value evidence	E0.SALES
Delivery handoff	E6 / Delivery
Decision pattern	Commercial Decision Engine™

Learning propõe mudança; não efetiva mudança sozinho.

73. Proposed Change

Quando um learning justificar mudança:

Learning Candidate
→ Proposed Change
→ Impact Assessment
→ Human Decision
→ New Version

O Proposed Change deve indicar:

objeto afetado;
motivo;
evidência;
risco;
impacto esperado;
responsável;
decisão.

74. Mudança de Offer

Learning que sugere alteração de:

promise;
claim;
capability;
component;
condition;
exclusion;
anti-fit;
pricing boundary;
configuration boundary;

retorna a E0.SALES como OfferChangeProposal ou mecanismo equivalente governado.

75. Mudança de metodologia

Learning que sugere alteração de:

gates;
etapas;
critérios;
perguntas padrão;
CRR;
handoff;
Decision Ask;
learning rule;

não pode ser incorporado automaticamente.

Exige decisão metodológica/versionamento.

76. Mudança da Engine

Nenhum pattern derivado de E6 altera automaticamente pesos, prompts, regras ou taxonomias proprietárias da Commercial Decision Engine™.

Exige:

evidência;
avaliação;
decisão;
versão;
teste.

77. Reativação

O E6 pode criar Reactivation Trigger para POSTPONED, LOST ou NO_DECISION quando houver base legítima.

Conteúdo:

trigger;
earliest/expected window, se conhecida;
reason;
evidence;
owner;
revalidation requirement.

78. Historical Commercial Evidence ≠ Current Commercial Truth

Na reativação:

Historical Need Truth
Historical Decision
Historical Objections
Historical Proposal
        ↓
REVALIDATE
        ↓
STILL VALID
CHANGED
RESOLVED
UNKNOWN
NEW

Não reabrir a oportunidade antiga como se nada tivesse mudado.

79. Nova necessidade em cliente existente

Se após WON surgir nova necessidade material:

Existing Client
    ↓
New Need Instance
    ↓
Need Isolation
    ↓
New Commercial Opportunity

Não alterar retroativamente a oportunidade original.

80. Tipos de relacionamento comercial futuro

Candidatos:

NEW_BUSINESS;
RENEWAL;
EXPANSION;
CROSS_SELL;
REACTIVATION.

Esses tipos ajudam análise sem destruir o histórico das oportunidades anteriores.

81. Renovação

Renovação é nova decisão comercial.

Não presumir:

valor entregue → renovação automática

Uma renovação pode exigir:

nova Need Truth;
continuidade de need existente revalidada;
novo Responsible Solution Fit;
nova Promise;
nova Commercial Configuration;
nova Decision Unit.

Profundidade depende da mudança material do contexto.

82. Cross-Domain boundary

O E6 pode receber sinais de:

delivery;
operações;
customer/value;
financeiro;
compliance;
people;
outros domains futuros.

Mas Sales não deve duplicar esses módulos.

Princípio:

Sales precisa de sinais suficientes para aprender se a promessa comercial encontrou realidade, não de possuir toda a execução.

83. Customer & Value Intelligence futuro

E6 mantém apenas o mínimo necessário para:

perceber valor declarado;
observar outcome relevante;
comparar promise vs reality;
aprender sobre oferta e venda.

Customer & Value Intelligence poderá aprofundar futuramente:

experiência;
satisfação;
adoção;
retenção;
percepção;
valor;
advocacy.

Não tratar essa visão como implementação atual.

84. One-Page — Commercial Outcome

One-Page principal para casos encerrados:

COMMERCIAL OUTCOME
 
Outcome State
Decision Date
Customer-Stated Reason
What We Know
What We Don't Know
Offer / Proposal Version
Price / Commercial Configuration
Decision Unit
Critical Decision Frictions
Material Changes
Value Signals
Learning Candidates
Reactivation Trigger

Evidence on Demand.

85. One-Page — Value Reality

Para casos WON com sinais pós-venda:

VALUE REALITY
 
Need
Promise
Contracted
Delivered
Perceived
Realized
Attribution / Contribution
Gaps
Drifts
Learning Candidates

One-Page First + drill-down de evidência.

86. UX — caminho feliz LOST

seller registra/seleciona LOST;
sistema pede razão declarada, se conhecida;
seller registra observations/gaps;
sistema associa Proposal Version e Decision Unit;
IA pode sugerir categorias e learning candidates;
humano revisa;
caso fecha;
learning segue para registry;
reactivation trigger pode ser criado se evidenciado.

87. UX — caminho feliz WON

seller registra aceite;
sistema associa Proposal Version e configuração final;
seller confirma alterações autorizadas;
sistema gera Contracted Promise Snapshot;
Human Review ocorre quando requerido;
sistema gera Delivery Handoff Package;
opportunity fecha como WON;
sinais posteriores de delivery/value podem ser adicionados;
learning candidates são produzidos quando houver evidência.

88. UX — caminho feliz POSTPONED

seller registra adiamento;
sistema exige trigger ou condição;
sem trigger suficiente, orienta NO_DECISION ou Human Review;
trigger é salvo com evidence e owner;
ciclo é encerrado;
reativação futura exige revalidação.

89. UX — caminho feliz NO_DECISION

E5 termina sem compromisso ativo;
seller registra NO_DECISION;
sistema captura known/unknown reasons;
oportunidade fecha;
learning candidate pode ser criado;
eventual reativação futura começa por revalidação.

90. Empty State — outcome sem razão

Se há outcome, mas nenhuma razão declarada:

Mostrar:

“Decisão registrada. Motivo ainda não conhecido.”

Permitir:

salvar outcome;
marcar reason UNKNOWN;
adicionar Observation/Hypothesis separadamente;
nunca exigir invenção de motivo para fechar.

91. Empty State — WON sem contrato/documento

Se existe aceite legítimo, mas contrato ainda não está disponível:

WON pode seguir conforme regra da organização;
Contracted Promise Snapshot deve declarar base do aceite;
contrato pode ser referenciado depois;
não inventar documento inexistente.

92. Empty State — valor ainda não observável

Mostrar:

“Resultado ainda não esperado ou não medido.”

Nunca converter ausência de medição em ausência de valor.

93. Error State — inconsistência Proposal vs Contracted

Se o sistema detecta diferença material não governada:

CONTRACTED PROMISE CONFLICT
→ block automatic handoff
→ Human Review Required

Preservar ambos os registros.

94. Error State — cross-tenant evidence

Qualquer tentativa de vincular evidence, contract, delivery signal ou outcome de outro tenant deve falhar por regra de autorização/RLS.

Nunca corrigir silenciosamente associação cross-tenant.

95. Loading State

Ao gerar:

Contracted Promise Snapshot;
Delivery Handoff Package;
Outcome One-Page;
Value Reality One-Page;
Learning Candidates;

mostrar processamento não bloqueante quando possível e preservar draft humano existente.

Falha de IA não pode impedir registro manual do outcome.

96. Idempotência

Reprocessar IA ou regenerar One-Page não deve:

duplicar outcome;
duplicar snapshot;
duplicar learning;
reescrever fonte;
alterar Decision State silenciosamente.

Usar identificadores/versioning adequados.

97. Permissões

Acesso deve respeitar:

tenant;
membership;
role;
field-level sensitivity quando aplicável;
necessidade operacional.

Exemplos:

preço/margem pode exigir acesso restrito;
delivery pode receber apenas subset necessário;
learning agregado pode ter visibilidade diferente do caso individual;
informações pessoais podem ser redigidas/minimizadas.

98. Field-level access

Candidatos a proteção adicional:

preço;
desconto;
margem, se futura;
motivo sensível de perda;
notas internas;
Decision Communication Profile;
dados pessoais;
contrato;
informações de risco.

A regra técnica final permanece decisão aberta.

99. Auditoria

Eventos candidatos:

decision_outcome_recorded;
outcome_reason_updated;
opportunity_closed;
contracted_promise_created;
delivery_handoff_generated;
handoff_conflict_recorded;
value_signal_recorded;
outcome_observed;
drift_detected;
learning_candidate_created;
learning_reviewed;
proposed_change_created;
reactivation_trigger_created.

Schema definitivo depende da arquitetura de eventos.

100. Versionamento

Devem permanecer identificáveis:

Need Version;
Offer Version;
Proposal Version;
Commercial Configuration Snapshot;
Contracted Promise Snapshot Version;
Delivery Handoff Version;
Outcome Record Version, quando alterável;
Learning Version/Status;
Proposed Change Version.

101. Imutabilidade

Regras:

Decision history não é apagado;
Contracted Promise Snapshot não é sobrescrito;
Customer Statements não são reescritos para encaixar learning;
Evidence source permanece rastreável;
learning rejeitado permanece no histórico;
change aprovado gera nova versão, não mutação silenciosa do passado.

102. Exclusão e correção

Preferir:

soft delete quando necessário;
supersede;
correction record;
versioning;
audit trail.

Hard delete de registros materiais de decisão, contract truth ou learning deve ser excepcional e governado.

103. IA — responsabilidades permitidas

A IA pode:

estruturar Decision Outcome;
sugerir razão categórica com base em statements;
apontar inconsistências;
gerar resumo de outcome;
comparar proposal vs contracted;
comparar promised vs delivered;
sugerir drift;
sugerir learning candidate;
sugerir destinos do learning;
gerar One-Pages;
redigir handoff;
apontar gaps.

Sempre preservando evidência e status de hipótese.

104. IA — proibições

A IA não pode autonomamente:

declarar motivo de perda como fato sem evidência;
declarar causalidade;
declarar cliente como inadequado sem base;
fechar oportunidade sem regra/ação autorizada;
marcar WON por inferência;
alterar price/contract;
alterar Offer Version;
alterar methodology;
promover learning a regra universal;
reativar oportunidade como verdade atual;
inventar outcome;
inventar value evidence;
sobrescrever Contracted Promise Snapshot.

105. Human Review

Requerer ou recomendar Human Review para:

outcome ambíguo material;
conflito Proposal vs Contracted;
promise drift;
handoff conflict;
causalidade relevante;
claim de valor externo;
proposed change material;
alteração de Offer;
alteração de metodologia;
mudança de boundary;
learning com impacto sistêmico.

106. Segurança e privacidade

Aplicar:

RLS;
minimização;
purpose limitation;
retenção;
acesso proporcional;
trilha de auditoria;
segregação de tenant;
proteção de dados pessoais;
redaction quando necessário;
controle de exportação/compartilhamento.

107. Retenção

Prazos de retenção devem considerar:

natureza comercial;
contrato;
obrigações legais;
finalidade;
learning agregado;
política do tenant.

Learning agregado não autoriza manter indefinidamente dados pessoais desnecessários.

108. Agregação para learning

Sempre que possível:

preservar pattern sem carregar dado pessoal desnecessário;
separar case evidence de generalized learning;
manter links governados para drill-down autorizado;
aplicar thresholds de anonimização/agrupamento quando futuros analytics forem implementados.

109. Entidades/objetos candidatos

Sem impor tabela física automática:

DecisionOutcome;
OutcomeReason;
DecisionUnitSnapshot;
ContractedPromiseSnapshot;
DeliveryHandoffPackage;
DeliveryHandoffConflict;
ValueSignal;
OutcomeObservation;
AttributionAssessment;
RealityDrift;
LearningCandidate;
LearningReview;
ProposedChange;
ReactivationTrigger.

Reutilizar objetos Core quando semanticamente suficientes.

110. Objetos Core reutilizados

Preferir reutilizar:

Evidence Item;
Knowledge Item;
Observation;
Hypothesis;
Gap;
Human Review;
Decision;
Action;
Outcome;
Learning;
Source;
Project/Engagement;
Domain Case;
Audit Event.

Evitar duplicação sem necessidade.

111. Relação com E0.SALES

E6 devolve:

Offer Reality Observations;
Value Evidence;
Anti-Fit evidence;
Capability/Delivery gaps;
pricing signals;
prerequisite evidence;
promise integrity evidence;
USF1/USF2/USP evidence;
OfferChangeProposal candidates.

E0.SALES continua governando Offer Truth.

112. Relação com E1

E6 pode devolver:

ICP/Anti-ICP signals;
relationship history;
reactivation evidence;
account context;
decision patterns.

Esses sinais não viram verdade universal automaticamente.

113. Relação com E2

E6 pode fortalecer ou enfraquecer:

Need Patterns;
Discovery priorities;
gaps recorrentes;
Customer Recognition patterns;
evidence requirements.

Não reescrever Need Truth histórica.

114. Relação com E3

E6 permite avaliar retrospectivamente:

fit previsto;
fit conditions;
anti-fit;
prerequisites;
Responsible Commercial Promise;
capability match.

Um outcome ruim não prova automaticamente fit incorreto; analisar condições e evidência.

115. Relação com E4

E6 pode produzir learning sobre:

Proposal Architecture;
Decision One-Page;
Decision Communication Profile;
Decision Ask;
Knowledge Disclosure Boundary;
apresentação;
clarity gaps.

Sem transformar correlação em causalidade.

116. Relação com E5

E6 pode produzir learning sobre:

Surface Objections;
Decision Frictions;
CRR;
perguntas abertas;
Relevant Value Stack;
negotiation boundaries;
commitments;
no-decision patterns.

Não transformar uma resposta que funcionou em script universal.

117. Relação com E0.CORE / Knowledge & Decision Core

E6 é uma das principais fontes de:

Outcome;
Learning;
Proposed Change;
Decision;
Evidence;
versioned knowledge.

A aprendizagem comercial deve reutilizar governança transversal.

118. Minimum Viable E6 Slice

Para o MVP, E6 precisa no mínimo permitir:

encerrar oportunidade com estado governado;
registrar razão declarada ou UNKNOWN;
preservar Statement / Observation / Hypothesis / Gap;
associar Proposal Version e Commercial Configuration;
registrar Decision Unit Snapshot;
para WON, criar Contracted Promise Snapshot;
gerar Delivery Handoff Package mínimo;
registrar Reactivation Trigger em POSTPONED quando aplicável;
registrar Value Signal simples, quando existir;
criar Learning Candidate;
revisar/promover/rejeitar learning manualmente;
rotear Proposed Change;
preservar auditoria, versionamento, tenant e RLS.

119. Minimum Viable Value Intelligence

No MVP, não exigir suite avançada de Customer Success.

Mínimo:

registrar Customer Perceived Value;
registrar Outcome Observation;
registrar NOT_MEASURED / OBSERVED / UNKNOWN;
vincular Evidence;
preservar causalidade como unknown/plausible quando aplicável.

120. Minimum Viable Handoff

Mínimo:

Contracted Promise Snapshot;
Need;
Promise;
Scope;
Exclusions;
Prerequisites;
Responsibilities;
Risks;
Stakeholders;
What Was Not Promised.

Não exigir gestão completa de projetos.

121. Incrementos sugeridos

Incremento 1 — Decision Resolution

outcome states;
reasons;
epistemology;
closure;
reactivation trigger.

Incremento 2 — Contracted Truth & Handoff

Contracted Promise Snapshot;
Delivery Handoff Package;
conflicts;
review.

Incremento 3 — Value Reality

value signals;
outcome observation;
promised vs contracted vs delivered;
basic drift.

Incremento 4 — Commercial Learning

Learning Candidate;
Review;
Proposed Change;
destinations.

Incremento 5 — One-Pages & Consolidation

Commercial Outcome One-Page;
Value Reality One-Page;
cross-stage feedback;
Sales v0.3 integration.

122. Critérios de aceite arquiteturais

123. Critérios de aceite técnicos candidatos

124. Edge case — aceite verbal e contrato posterior

Se a regra comercial permitir WON com aceite verbal:

registrar evidência do aceite;
criar Contracted Promise Snapshot com base disponível;
marcar contrato formal como pendente, se aplicável;
não inventar assinatura;
atualizar referência documental posteriormente.

125. Edge case — cliente pede mudança após WON e antes do kickoff

Classificar materialidade:

mudança comercial dentro de boundary → versão/autorização aplicável;
mudança de scope/promise/solution → retorno governado E3/E4;
novo need → E2/E3;
alteração contratual → processo jurídico/comercial aplicável.

Não editar silenciosamente o snapshot original.

126. Edge case — delivery entrega mais do que contratado

Registrar:

Delivered delta;
razão;
autorização, se houver;
impacto;
possível Value Signal;
possível Offer/Scope learning.

Não assumir que overdelivery é positivo ou escalável.

127. Edge case — cliente percebe valor sem outcome quantitativo

Registrar como PERCEIVED VALUE com Customer Statement e contexto.

Não inventar indicador.

Pode ser evidência qualitativa legítima.

128. Edge case — outcome positivo por fatores externos

Registrar outcome e fatores conhecidos.

Attribution deve permanecer:

UNKNOWN;
PLAUSIBLE_CONTRIBUTION;
ou equivalente sustentado.

Não transformar correlação em claim.

129. Edge case — seller discorda do motivo declarado pelo cliente

Preservar ambos:

Customer Statement: X
Seller Observation/Hypothesis: Y

Não sobrescrever X com Y.

130. Edge case — múltiplos decisores dão razões diferentes

Registrar razões por ator/contexto quando relevante.

O sistema pode resumir divergência, mas não escolher uma “verdadeira” sem evidência.

131. Edge case — oportunidade perdida volta espontaneamente

Não reabrir como verdade atual automática.

Criar reactivation/revalidation:

Historical Case
→ Current Context Check
→ Need Revalidation
→ new/renewed opportunity

132. Edge case — WON sem capacidade de delivery

Se capacidade necessária não existe no momento do handoff:

DELIVERY CAPACITY CONFLICT
→ Human Review
→ mitigation / schedule / change

Isso deve retroalimentar E0.SALES Capacity Signals.

133. Edge case — Promise válida, prerequisite do cliente não cumprida

Distinguir:

promise inadequada;
prerequisite não cumprida;
delivery issue;
external constraint.

Evitar concluir “solução não funciona” sem análise.

134. Edge case — contrato jurídico diverge do snapshot

O contrato/instrumento jurídico prevalece conforme governança legal da organização.

O sistema deve:

sinalizar conflito;
bloquear handoff automático quando material;
exigir revisão;
gerar snapshot corrigido/versionado;
preservar snapshot anterior e evidência.

135. Edge case — learning contraditório

Se novos casos contradizem learning anterior:

não apagar learning;
adicionar contradictory evidence;
reduzir maturidade/strength quando aplicável;
enviar para review;
manter histórico de decisão.

136. Edge case — learning sem ação

Learning pode permanecer registrado sem Proposed Change.

Nem todo insight exige alteração de produto/metodologia.

137. Edge case — ausência total de feedback após entrega

Registrar:

PERCEIVED VALUE = UNKNOWN
REALIZED OUTCOME = NOT_MEASURED / UNKNOWN

Não inferir satisfação ou insatisfação.

138. Métricas candidatas do E6

Somente após dados suficientes, considerar:

% outcomes com reason declarado;
% no-decision;
% postponed com trigger válido;
tempo entre decisão e handoff;
% WON com Contracted Promise Snapshot completo;
% handoffs com conflict;
% outcomes com value signal posterior;
drift rate por tipo;
learning candidates por caso;
% learning revisado;
% proposed changes aprovados/rejeitados;
reactivation conversion, quando houver volume suficiente.

Essas métricas são candidatas, não benchmarks aprovados.

139. O que não medir prematuramente

Evitar no MVP:

causal lift de metodologias com amostra insuficiente;
win rate por buyer profile como verdade;
seller ranking simplista;
persuasion score;
learning confidence numérico arbitrário;
attribution score sem modelo;
PMF proxy baseada apenas em WON;
“AI accuracy” sem ground truth definido.

140. Fora do Minimum Viable E6 Slice

Não exigir automaticamente:

full CRM analytics;
customer success suite;
NPS automation;
churn prediction;
renewal prediction;
ML win/loss classifier;
automated causal inference;
revenue recognition;
billing;
contract lifecycle management completo;
project management completo;
real-time delivery integrations;
advanced data warehouse;
predictive next-best-offer;
automatic methodology optimization.

141. Open technical decisions

Permanecem abertas:

representação física de DecisionOutcome;
representação física de ContractedPromiseSnapshot;
se Delivery Handoff é entity ou governed projection;
state machine final de outcomes;
regra organizacional exata para marcar WON;
modelagem de price proposed/accepted/paid;
mecanismo de conflict resolution Proposal vs Contract;
formato do Value Signal;
estados finais de Attribution/Contribution;
estados finais de Outcome Observation;
materiality threshold para drift;
canonical Learning Registry;
deduplicação de Learning Candidates;
event schemas;
retention específica de outcomes/learning;
field-level access de dados comerciais sensíveis;
integração futura com delivery domains;
integração futura com contratos/assinatura;
política de reactivation triggers;
thresholds para promover learning a Proposed Change.

Nenhuma dessas lacunas impede a arquitetura modular, mas devem ser resolvidas antes dos PRDs técnicos correspondentes.

142. Cross-document impacts

E5

Atualizar o handoff final de:

E6 — Momentum, Outcome & Learning

para:

E6 — Decision Outcome, Handoff & Commercial Learning

E5 mantém momentum ativo.

E0.SALES

Reforçar:

Offer Reality Loop;
Value Evidence;
Offer Change Proposal;
USF1/USF2/USP evidence;
Commercial Capacity Signals;
pricing/economics learning.

Sales Intelligence Consolidado

Atualizar E6 e seus estados/loops.

E0.CORE

Confirmar reutilização de Outcome, Learning, Decision, Human Review, Evidence e Proposed Change equivalente.

Delivery / Future Domains

Definir apenas interfaces mínimas; não expandir automaticamente o MVP.

143. Truthmode e fronteira de evidência

Aprovado como arquitetura

E6 começa após resolução/estacionamento governado;
momentum ativo pertence ao E5;
outcomes governados;
anti-zombie opportunity;
Contracted Promise Snapshot;
Delivery Handoff Package;
Value Reality Chain;
Offer Reality Loop;
Commercial Learning governado;
reativação com revalidação;
learning não altera sistema automaticamente.

Evidência limitada / learning existente

Decision Ask do caso CTM;
Value Delivered ≠ Renewal Won;
Negative Decision as Value Evidence.

Não generalizar além do suporte disponível.

Ainda não comprovado

implementação funcional;
adoção por sellers;
qualidade dos handoffs;
capacidade de medir value reality;
impacto em win rate;
redução de churn;
validade de patterns;
escalabilidade operacional;
automação do learning loop.

144. Princípios finais

Momentum ativo pertence ao E5.
E6 começa na resolução comercial ou estado estacionado governado.
Sem próximo compromisso legítimo, Decision Pending não permanece aberto.
Oportunidade zumbi é erro de conhecimento.
Motivo declarado e motivo inferido são coisas diferentes.
WON não prova valor.
LOST não prova ausência de valor.
POSTPONED exige trigger governado.
Historical Commercial Evidence não é Current Commercial Truth.
Promise, Contracted, Delivered, Perceived e Realized são camadas diferentes.
Outcome observado não implica causalidade.
Contracted Promise Snapshot preserva a verdade comercial acordada.
O que foi vendido precisa chegar ao delivery com rastreabilidade.
What Was Not Promised deve permanecer explícito.
Drift é detectado e governado, não apagado.
Um caso gera Learning Candidate, não regra universal.
Learning propõe; Human Decision muda; Version preserva.
Reativação exige revalidação.
Nova necessidade gera novo ciclo quando material.
Quem aprende com cada decisão vende melhor a próxima.

145. Arquitetura consolidada do E6

E4 / E5 / GATES
      ↓
DECISION / GOVERNED CLOSURE
      ↓
┌─────────────┬─────────────┬─────────────────┐
↓             ↓             ↓                 ↓
WON          LOST       POSTPONED        NO_DECISION
│             │             │                 │
│             │             └── Reactivation ┘
│             │                 Trigger / Closure
│             │
│             └──────────────┐
│                            │
↓                            ↓
CONTRACTED PROMISE      COMMERCIAL OUTCOME
      ↓                       ↓
DELIVERY HANDOFF         Reason / Evidence
      ↓                       ↓
DELIVERED                    │
      ↓                       │
PERCEIVED                    │
      ↓                       │
REALIZED                     │
      ↓                       │
ATTRIBUTION                  │
      └─────────────┬─────────┘
                    ↓
             COMMERCIAL LEARNING
                    ↓
             Learning Candidate
                    ↓
               Human Review
                    ↓
             Proposed Change
                    ↓
                 Decision
                    ↓
                 Version
                    ↓
      ┌─────────────┼─────────────┐
      ↓             ↓             ↓
   E0.SALES       E1–E3         E4–E5
 Offer Truth     Need/Fit      Communication
      └─────────────┴─────────────┘
                    ↓
                FUTURE CASES

146. Resultado esperado

O E6 deve permitir que uma organização passe de:

“Fechamos ou perdemos a venda e seguimos para a próxima.”

para:

“Registramos o que realmente foi decidido, preservamos o que foi prometido e contratado, transferimos essa verdade para quem vai entregar, observamos o que de fato aconteceu, distinguimos percepção de resultado e transformamos evidência em aprendizado governado para vender e entregar melhor no próximo ciclo.”

Esse é o papel do E6 dentro do Orquestro™.

PARTE III — CONTROLE DA CONSOLIDAÇÃO

31. Mudanças principais da v0.2 para a v0.3

Sales reposicionado de “único produto do MVP” para primeiro produto/wedge/primeira fatia ponta a ponta dentro da Minimum Viable Platform modular;
E0 decomposto explicitamente em E0.CORE + E0.SALES;
E0.SALES atualizado para v0.2 com Value Architecture, USF1/USF2/USP, Commercial Configuration Policy e disclosure na origem;
E2 atualizado para v0.2 com Customer Need Truth governado, Need Boundary e What Is Not The Need;
E3 substituído pela arquitetura standalone de Responsible Solution Fit;
E4 substituído pela arquitetura standalone de Decision & Communication, proposta protegida e apresentação human-first;
E5 redefinido como etapa condicional pós-apresentação, com Presentation Debrief, Decision Friction, CRR + Open Question e feedback cycles;
E6 redefinido para Outcome, Handoff & Learning, removendo duplicidade de momentum;
Contracted Promise e Value Reality Chain incorporados;
Offer Reality Loop e Learning Governance fechados ponta a ponta;
conflitos históricos explicitamente resolvidos em vez de mantidos por compatibilidade silenciosa.

32. Questões que permanecem para ADR/PRD, não para reabrir a arquitetura

A v0.3 está suficientemente definida como arquitetura. Permanecem decisões de implementação, entre elas:

representação física/materialização de algumas projeções e One-Pages;
granularidade final de Gate Records;
field-level access técnico para economics;
definição técnica de material change classifiers;
eventos finais e payloads;
persistência própria ou derivada de Decision Unit;
estratégia final de exportação/version pinning;
critérios quantitativos de readiness por incremento;
quais elementos entram em cada onda de implementação;
métricas de utilidade e qualidade nos pilotos;
pricing e disposição de pagamento do próprio Orquestro.

Essas questões devem gerar ADRs ou PRDs próprios. Não autorizam alteração silenciosa da jornada E0–E6.

33. Próximo uso recomendado

A partir desta v0.3, o trabalho deve mudar de “expandir arquitetura” para:

Fonte v0.3
→ mapa de incrementos
→ ADRs necessários
→ PRDs por funcionalidade
→ implementação
→ teste ponta a ponta
→ pilotos assistidos
→ Evidence
→ Learning
→ Proposed Change
→ Decision
→ v0.4, somente quando houver mudança material aprovada

34. Regra de encerramento

A v0.3 consolida a arquitetura atual do Orquestro™. Novas ideias não devem criar novas etapas ou profundidade automaticamente. Devem entrar pelo mecanismo de classificação de escopo, evidência e governança do MVP.

Orquestro — Documentação

Explorador

V360 Sales Intelligence — Consolidado v0.3 (2026-08-22)

Orquestro™ — Fonte Arquitetural Consolidada

1. Finalidade da v0.3

2. Decisões de consolidação que resolvem conflitos anteriores

2.1 Sales é wedge, não o único domínio permitido no MVP

2.2 E5 possui o momentum ativo; E6 não duplica follow-up

2.3 A apresentação é humana; o sistema trabalha antes e depois

2.4 Objeções seguem CRR + Open Question

2.5 USF1 + USF2 + USP pertencem à verdade comercial de E0.SALES

2.6 Customer Need Truth e Offer Passport são projeções, não verdades concorrentes

3. Definição executiva do Orquestro™

4. Tese comercial consolidada

5. Jornada funcional consolidada E0–E6

6. Arquitetura em três loops

6.1 Opportunity Intelligence Loop

6.2 Decision Intelligence Loop

6.3 Reality & Learning Loop

7. Regra epistemológica transversal

8. Need Lifecycle e gates

8.1 Need Lifecycle

8.2 Need Isolation Gate

8.3 Opportunity Gate

9. Duas verdades antes do fit

10. Offer Truth, Value Architecture e Commercial Configuration

10.1 Pricing truth

10.2 Disclosure truth

11. E1 — Lead Intelligence consolidado

12. E2 — Human Discovery & Customer Need Truth consolidado

13. E3 — Responsible Solution Fit consolidado

14. E4 — Decision & Communication consolidado

15. E5 — Decision Conversation & Feedback Intelligence consolidado

15.1 Decision Friction

15.2 CRR + Open Question

15.3 Relevant Value Stack

15.4 Negotiation Boundary

16. E6 — Decision Outcome, Handoff & Commercial Learning consolidado

16.1 Decision Resolution

16.2 Contracted Promise & Delivery Handoff

16.3 Value Reality Chain

16.4 Learning governance

17. Decision Unit transversal

18. Objetos canônicos e projeções governadas

18.1 Core transversal

18.2 Sales — contexto e relacionamento

18.3 Sales — Discovery e oportunidade

18.4 Sales — oferta, fit e decisão

18.5 Sales — outcome e learning

18.6 Projeções / One-Pages

19. Contratos entre etapas

20. Human Review e autoridade

21. Segurança, privacidade e segregação

22. One-Page First + Evidence on Demand

23. Estados comerciais consolidados

23.1 Need

23.2 Offer readiness/lifecycle

23.3 Solution Fit

23.4 Proposal

23.5 Decision / Closure

24. Invariantes sistêmicos v0.3

25. Minimum Viable Sales Domain Slice — visão consolidada

26. Classificação de novas ideias no Sales

27. Estratégia de validação

28. Critérios de aceite arquiteturais da consolidação

29. Hierarquia documental a partir da v0.3

30. Mapa das fontes incorporadas

PARTE II — ESPECIFICAÇÕES DETALHADAS INCORPORADAS

E0.CORE — Organizational Context & Implementation Intelligence v0.1

Orquestro E0.CORE — Organizational Context & Implementation Intelligence

1. Finalidade do documento

2. Decisão arquitetural aprovada

3. Truthmode e fronteira de evidência

3.1 Fatos e decisões vigentes

3.2 Ainda não comprovado

3.3 Regra de comunicação

4. Tese central

5. Problema que a E0.CORE resolve

6. Definição funcional

7. Posição na arquitetura do Orquestro