Skip to main content
A ontologia é o schema do grafo de entidades do Memory: quais tipos de coisa existem no seu negócio (nós), como elas se relacionam (arestas) e de qual tabela clean/ cada tipo é populado.

​
Como funciona

A ontologia mora em um único arquivo YAML, o graph_mapping.yaml, versionado no seu Workspace Git. Ele descreve três coisas:
  • Nós — os tipos de entidade (Cliente, Contrato, Produto, Associado)
  • Arestas — os relacionamentos entre eles (Cliente TEM_CONTRATO Contrato)
  • Origem — de qual tabela da camada clean/ do Data Catalog cada tipo vem, e qual coluna é a chave de identidade
Quando a ontologia é ativada, a plataforma cria os labels de nó no grafo (FalkorDB) e o Memory Worker passa a ler as tabelas clean/ indicadas para popular nós e arestas. A partir daí, cada entidade consolidada aparece no Console em Memory → Entities. Para começar, o Console oferece perfis-base por tipo de operação (SaaS B2B, Fintech, Cooperativa de Crédito) em Memory → Configuration. Você parte de um desses e ajusta.

​
E se eu precisar atualizar

Atualizar a ontologia é o caso comum: o negócio ganha um tipo de entidade novo, um atributo passa a importar, um relacionamento muda. O fluxo de ativação tem três etapas, com histórico de versão:
1

Salvar o rascunho

Edite o graph_mapping.yaml (via Console ou direto no Git) e salve. O rascunho não entra em produção sozinho — fica com is_current: false.
2

Validar

A plataforma valida o YAML antes de aplicar. Se um nó aponta para uma tabela que não existe ou um campo está errado, a validação reprova e aponta onde.
3

Ativar

Ao ativar, a nova versão vira a corrente. A plataforma registra quem ativou e quando. Se precisar voltar, cada versão anterior fica guardada e é possível reativar.
A ativação inicializa os novos labels no grafo de forma idempotente, então reaplicar a mesma ontologia não duplica nada.
Mudanças de atributo e novos tipos de entidade não exigem reprocessar o histórico. Adicionar um relacionamento novo entre tipos já existentes faz o Memory Worker preencher as arestas no próximo ciclo.

​
Qual o nível de dependência de vocês

Depende do tipo de mudança. Você faz sozinho:
  • Adicionar ou remover um atributo de uma entidade
  • Trocar o confidence threshold de aprovação automática
  • Ajustar quais tabelas clean/ alimentam um tipo já modelado
  • Escolher e ajustar um perfil-base no Console
Isso é self-service pelo Console (Memory → Configuration) ou por Pull Request no Workspace Git. A revisão via PR dá o mesmo controle que você já tem sobre código: histórico, rollback e aprovação antes de aplicar. O time da Strattum entra quando:
  • Você está modelando o grafo pela primeira vez e quer desenhar a ontologia junto (nosso Forward Deployed Engineer faz esse mapeamento inicial)
  • A mudança envolve entity resolution complexo (a mesma pessoa aparecendo com identidades diferentes em vários sistemas)
  • Você quer revisar se um novo tipo de entidade encaixa bem no grafo existente antes de aplicar
O objetivo do modelo é que a operação do dia a dia não dependa da gente. O mapeamento inicial e as decisões de modelagem mais pesadas são onde ajudamos.

​
Próximos passos

Configurar ontologia

Passo a passo de configuração no Console, com os perfis-base por operação.

Ontology API

Endpoints para salvar, validar e ativar versões da ontologia programaticamente.