How true must GTM data be before the system can act?

GTM data is true enough when a team can use it for one named commercial decision without guessing what the field means, where the claim came from, whether it is still current, who owns correction, or what happens when sources disagree.

That standard is smaller than a perfect database and stronger than a completed field.

The failure mode is field confidence. A CRM value looks factual because it is structured. A dashboard repeats it. An automation routes from it. An AI agent summarizes it. Yet nobody can inspect the event behind the value or explain when it stops being reliable. The system gains confidence as the evidence gets farther away.

Definition

Definition: Truth in GTM is decision scoped commercial evidence with explicit meaning, an inspectable source, a freshness condition, an accountable owner, and a path for resolving conflict.

Truth is the first layer of the Lorde stack because every downstream layer inherits its quality. A Playbook turns evidence into a normal decision. Architecture records and moves that decision. An Operator maintains the loop and resolves exceptions.

If the evidence is weak, the rest of the system can still run. It simply runs the wrong commercial state with greater consistency.

Truth is not the same as a clean database

A founder does not need every record completed before the business can act. The useful question is narrower: which claims must be reliable for this decision?

Consider a proposal decision. The team may need to know whether the buyer has confirmed the problem, who participates in the economic decision, which constraint shapes scope, and which next step was accepted. An unrelated firmographic field can be missing without blocking the proposal. A polished record with stale buyer intent can be far more dangerous.

The UK Government Data Quality Framework treats quality as fitness for purpose. It describes dimensions such as completeness, consistency, timeliness, validity, and accuracy. The framework is not a sales method, but the lens is useful. Presence alone does not make a claim fit for use.

A commercial record can be complete but stale. It can be current but ambiguous. It can be accurate to the last conversation but unsupported by a source anyone else can inspect. The Truth layer should expose those differences instead of compressing them into a green required field.

This also protects commercial capacity. Teams lose capacity when people repeatedly reopen the same facts, search private messages, ask the founder to remember context, or repair actions triggered by bad evidence. Better Truth reduces reconstruction work before it increases automation.

Build a five part evidence contract

Apply this contract only to claims that can change a consequential action. Start with one claim, not the whole CRM.

1. Meaning

Write what the claim means in observable terms.

“Decision maker identified” is weak if one seller means a job title and another means a person who confirmed authority. A usable definition states the evidence required and what the field does not establish.

Meaning belongs in Truth. The action triggered by that meaning belongs in the Playbook. Keeping those separate prevents a field label from silently becoming a decision rule.

2. Source

Name the event or record that supports the claim.

A source may be a buyer statement, signed document, call note, verified system event, or approved calculation. “The seller knows” may be legitimate context, but it should not become invisible evidence after the opportunity moves to another owner.

Inspectability matters more than centralization. The evidence can live in several systems if the commercial path preserves where it came from and how to retrieve it.

3. Freshness condition

State what event can make the claim unreliable.

Do not invent a universal age limit. Buyer intent may change after a budget review, stakeholder change, delayed implementation, new objection, or long silence. Company facts may remain useful for much longer.

A freshness condition ties review to the decision. It answers, “What would require us to confirm this again?”

4. Owner

Assign the role responsible for keeping the definition usable and correcting normal defects.

Ownership is not permission to rewrite buyer reality. It is responsibility for resolving missing evidence, maintaining the field contract, and ensuring the next user can understand the state.

When every user can edit a consequential claim but nobody owns its quality, Architecture stores change without accountability.

5. Conflict path

Define what happens when valid sources disagree.

The latest note may conflict with a signed scope. A buyer message may conflict with a CRM stage. Two stakeholders may describe authority differently. The system should not choose silently.

The conflict path can prefer one source, request confirmation, hold the action, or escalate judgment. This is where Truth meets Playbook and Operator ownership.

Worked example: economic buyer involved

Suppose the proposal workflow advances whenever the CRM field “economic buyer involved” is marked yes.

The field is complete across the active pipeline, but its contract is missing.

One seller marks yes after seeing a senior title. Another waits for direct participation. A third copies the value from an old opportunity. The proposal automation works exactly as configured, yet the team cannot explain why the buyer is ready for that step.

Repair the claim before repairing the automation:

• Meaning: The person who can authorize the commercial commitment has been identified, and their role in the decision has been confirmed through an inspectable interaction.
• Source: Link the buyer event or note that supports the claim.
• Freshness: Reconfirm after a stakeholder change, a material scope change, or evidence that the decision process has shifted.
• Owner: The opportunity owner maintains the normal claim. A named revenue role audits recurring defects.
• Conflict: If title, buyer statement, and account history disagree, hold the proposal trigger and route the exception for judgment.

Now the Architecture can route from a defined state. The Playbook can specify the normal next action. The Operator can inspect exceptions and improve the contract when real cases expose a missing condition.

Decision rule

Use this rule before a commercial claim drives a workflow, dashboard interpretation, or AI action:

If the team cannot state the claim's meaning, source, freshness condition, owner, and conflict path, treat it as context, not as an execution trigger.

Classify the claim in one of three operating states:

• Trigger: All five properties are explicit. The claim may drive the approved normal action.
• Context: The source is inspectable, but one property is incomplete. A person may use it with judgment, but the system must not present it as a settled trigger.
• Unknown: The source is absent, invalid, or in unresolved conflict. Stop the dependent action and collect or resolve evidence.

The failed property still points to the repair. Meaning and source begin in Truth. Divergent action belongs in the Playbook. A defined state that cannot travel belongs in Architecture. Recurring decay and unresolved exceptions need Operator ownership. Automation is earned when the claim survives a handoff without private explanation.

NIST AI RMF Map guidance starts with establishing context, including intended purpose, users, expectations, assumptions, limitations, and deployment conditions. It does not define sales truth. It supports the sequence principle: context should be understood before a system is trusted to act inside it.

Checklist

Run this audit on one consequential claim this week:

• Name the commercial decision the claim can change.
• Write the claim in observable language.
• Identify the evidence required and its inspectable source.
• State the event that makes the claim require confirmation.
• Assign one role to maintain the normal contract.
• Define what happens when sources disagree.
• Sample current records and mark each failed property.
• Repair the first property before adding another field or automation.
• Test whether a new owner can use the claim without private explanation.
• Record exceptions so the contract can improve from real decisions.

The output is not a data quality program. It is one commercial claim that the system can use honestly.

What this is not

This is not a demand for perfect data. Missing evidence can be an honest state, provided the system does not present absence as certainty.

It is not a universal freshness schedule. The relevant review condition depends on the claim and the decision.

It is not an argument against AI or automation. Both can expand commercial capacity when they inherit defined evidence and bounded authority. The sequence is evidence, decision, architecture, then scale.

FAQ

Does every CRM field need an evidence contract?

No. Start with fields that can qualify, disqualify, route, price, commit, forecast, or trigger external action. Low consequence context can use lighter governance.

How current must commercial evidence be?

Current enough for the decision it governs. Define the event that invalidates or weakens the claim instead of copying a universal time limit.

Can AI decide which source is true?

AI can compare sources, identify conflict, and apply an approved precedence rule. When the conflict requires commercial judgment or changes buyer impact, the system should escalate rather than invent certainty.

If consequential fields keep producing disputes or bad actions, a Lorde GTM diagnosis can trace whether the restriction sits in Truth, Playbook, Architecture, or Operator ownership.

Quão confiável o dado de GTM precisa ser antes de o sistema agir?

Um dado de GTM está confiável o bastante quando a equipe consegue usar esse dado em uma decisão comercial nomeada sem adivinhar o significado do campo, a origem da afirmação, se ela ainda vale, quem corrige o registro ou o que fazer quando as fontes entram em conflito.

Esse padrão é menor que um banco perfeito e mais exigente que um campo preenchido.

A falha é a confiança no campo. O valor no CRM parece fato porque está estruturado. O dashboard repete. A automação roteia. O agente de IA resume. Só que ninguém consegue encontrar o evento que sustenta aquele valor nem dizer quando ele deixou de ser confiável. A confiança do sistema cresce enquanto a evidência se afasta.

Definição

Definição: Verdade em GTM é evidência comercial vinculada a uma decisão, com significado explícito, fonte verificável, condição de validade, dono responsável e caminho para resolver conflito.

Verdade abre a pilha da Lorde porque toda camada seguinte herda sua qualidade. O Playbook transforma evidência em decisão normal. A Arquitetura registra e movimenta essa decisão. O Operador mantém o circuito e resolve exceções.

Quando a evidência é fraca, o restante ainda pode funcionar. Funciona com consistência sobre um estado comercial errado.

Verdade não é sinônimo de banco limpo

O fundador não precisa esperar todos os registros ficarem completos para agir. A pergunta útil é menor: quais afirmações precisam ser confiáveis para esta decisão?

Pense na decisão de avançar uma proposta. A equipe pode precisar confirmar o problema do comprador, quem participa da decisão econômica, qual restrição molda o escopo e qual próximo passo foi aceito. Um campo cadastral sem relação com isso pode continuar vazio. Já uma intenção antiga, apresentada como atual, pode comprometer toda a conversa.

O Government Data Quality Framework do Reino Unido trata qualidade como adequação ao propósito. O documento descreve dimensões como completude, consistência, atualidade, validade e precisão. Não é uma metodologia de vendas. Serve como lente para lembrar que presença não significa utilidade.

Um registro comercial pode estar completo e vencido. Pode ser atual e ambíguo. Pode refletir a última conversa, mas não apontar uma fonte que outro membro da equipe consiga verificar. A camada de Verdade precisa manter essas diferenças visíveis em vez de converter tudo em um campo obrigatório verde.

Isso também protege a capacidade comercial. A equipe perde capacidade quando precisa rediscutir os mesmos fatos, procurar mensagens privadas, pedir ao fundador que reconstrua contexto ou corrigir ações disparadas por evidência ruim. Verdade melhor reduz o trabalho de reconstrução antes mesmo de aumentar automação.

Monte um contrato de evidência em cinco partes

Aplique o contrato apenas às afirmações capazes de mudar uma ação relevante. Comece por uma, não pelo CRM inteiro.

1. Significado

Escreva o que a afirmação quer dizer em termos observáveis.

“Decisor identificado” é fraco se um vendedor entende como cargo sênior e outro exige confirmação direta de autoridade. Uma definição útil mostra qual evidência sustenta o campo e também o que ele não prova.

O significado pertence à Verdade. A ação produzida por esse significado pertence ao Playbook. Separar as duas coisas impede que o nome de um campo vire regra de decisão sem discussão.

2. Fonte

Nomeie o evento ou registro que sustenta a afirmação.

A fonte pode ser uma fala do comprador, um documento assinado, uma nota de reunião, um evento verificado no sistema ou um cálculo aprovado. “O vendedor sabe” pode ser contexto legítimo, mas não deveria virar evidência invisível depois que a oportunidade muda de dono.

Poder verificar importa mais que centralizar. A evidência pode morar em sistemas diferentes, desde que o fluxo comercial preserve sua origem e mostre onde a equipe pode encontrar essa evidência.

3. Condição de validade

Defina qual evento exige nova confirmação.

Não invente um prazo universal. A intenção do comprador pode mudar após revisão de orçamento, troca de interlocutor, atraso de implantação, nova objeção ou silêncio prolongado. Outros fatos empresariais podem continuar úteis por mais tempo.

A condição de validade conecta a revisão à decisão. Ela responde: “O que faria a equipe confirmar isso novamente?”

4. Dono

Atribua o papel responsável por manter a definição utilizável e corrigir defeitos do caminho normal.

Ter dono não dá licença para reescrever a realidade do comprador. Significa responder pela correção da evidência ausente, pela manutenção do contrato e pela compreensão do estado por quem vier depois.

Quando todos podem editar uma afirmação relevante e ninguém responde por sua qualidade, a Arquitetura registra mudança sem responsabilidade.

5. Caminho de conflito

Defina o que acontece quando fontes válidas discordam.

A nota mais recente pode contradizer um escopo assinado. A mensagem do comprador pode contrariar o estágio do CRM. Dois interlocutores podem descrever a autoridade de maneiras diferentes. O sistema não deve escolher em silêncio.

O caminho pode priorizar uma fonte, pedir confirmação, segurar a ação ou escalar julgamento. É nesse ponto que Verdade encontra Playbook e responsabilidade do Operador.

Exemplo prático: decisor econômico envolvido

Imagine que o fluxo de proposta avance sempre que o campo “decisor econômico envolvido” estiver marcado como sim.

O campo está preenchido nas oportunidades ativas, mas não tem contrato.

Um vendedor marca sim ao ver um cargo sênior. Outro espera participação direta. Um terceiro reaproveita o valor de uma oportunidade antiga. A automação funciona como foi configurada, mas a equipe não consegue explicar por que aquele comprador está pronto para a proposta.

Repare a afirmação antes de reparar a automação:

• Significado: A pessoa capaz de autorizar o compromisso comercial foi identificada, e seu papel na decisão apareceu em uma interação verificável.
• Fonte: Vincule o evento ou a nota que sustenta a afirmação.
• Validade: Confirme novamente após mudança de interlocutor, alteração relevante de escopo ou evidência de que o processo decisório mudou.
• Dono: O responsável pela oportunidade mantém o caminho normal. Um papel de receita nomeado audita defeitos recorrentes.
• Conflito: Se cargo, fala do comprador e histórico da conta discordarem, segure o gatilho da proposta e roteie a exceção para julgamento.

Agora a Arquitetura pode rotear com base em um estado definido. O Playbook especifica a ação normal. O Operador inspeciona exceções e melhora o contrato quando casos reais revelam uma condição ausente.

Regra de decisão

Use esta regra antes de uma afirmação comercial orientar fluxo, leitura de dashboard ou ação de IA:

Se a equipe não consegue declarar significado, fonte, condição de validade, dono e caminho de conflito, trate a afirmação como contexto, não como gatilho de execução.

Classifique a afirmação em um de três estados operacionais:

• Gatilho: As cinco propriedades estão explícitas. A afirmação pode acionar o caminho normal aprovado.
• Contexto: A fonte é verificável, mas uma propriedade está incompleta. Uma pessoa pode usar a informação com julgamento, porém o sistema não deve tratar esse contexto como gatilho resolvido.
• Desconhecido: A fonte está ausente, inválida ou em conflito sem resolução. Segure a ação dependente e colete ou resolva a evidência.

A propriedade que falhou ainda aponta o reparo. Significado e fonte começam na Verdade. Ação divergente pertence ao Playbook. Estado definido que não consegue viajar pertence à Arquitetura. Degradação recorrente e exceções sem resolução exigem responsabilidade do Operador. A automação é conquistada quando a afirmação sobrevive à troca de responsável sem explicação privada.

O Map do NIST AI RMF começa pelo entendimento do contexto, incluindo propósito, usuários, expectativas, premissas, limitações e condições de uso. Ele não define verdade comercial. Reforça uma regra de sequência: o contexto precisa estar compreendido antes que um sistema receba confiança para agir dentro dele.

Checklist

Audite uma afirmação relevante nesta semana:

• Nomeie a decisão comercial que ela pode mudar.
• Escreva a afirmação em linguagem observável.
• Identifique a evidência exigida e sua fonte verificável.
• Declare o evento que exige nova confirmação.
• Atribua um papel para manter o contrato normal.
• Defina o que acontece quando as fontes discordam.
• Examine registros atuais e marque a primeira propriedade que falha.
• Repare essa propriedade antes de adicionar campo ou automação.
• Teste se um novo responsável usa a afirmação sem explicação privada.
• Registre exceções para melhorar o contrato a partir de decisões reais.

O resultado não é um programa de qualidade de dados. É uma afirmação comercial que o sistema consegue usar com honestidade.

O que isto não é

Não é uma exigência de dado perfeito. Evidência ausente pode ser um estado honesto, desde que o sistema não transforme ausência em certeza.

Não é uma tabela universal de validade. A condição de revisão depende da afirmação e da decisão.

Também não é um argumento contra IA ou automação. As duas podem ampliar capacidade comercial quando herdam evidência definida e autoridade limitada. A sequência é evidência, decisão, arquitetura e escala.

Perguntas frequentes

Todo campo do CRM precisa de contrato de evidência?

Não. Comece pelos campos que podem qualificar, desqualificar, rotear, precificar, comprometer, prever ou disparar ação externa. Contexto de baixo impacto aceita governança mais leve.

Quão atual uma evidência comercial precisa ser?

Atual o bastante para a decisão que governa. Defina o evento que enfraquece ou invalida a afirmação em vez de copiar um prazo universal.

A IA pode decidir qual fonte é verdadeira?

A IA pode comparar fontes, identificar conflito e aplicar uma regra de precedência aprovada. Quando o conflito exige julgamento comercial ou muda o impacto sobre o comprador, o sistema deve escalar em vez de inventar certeza.

Se campos relevantes continuam produzindo disputa ou ação errada, um diagnóstico de GTM da Lorde pode localizar a restrição em Verdade, Playbook, Arquitetura ou responsabilidade do Operador.