Quanto mais eu usava a própria archē para construir a archē, mais uma palavra começava a aparecer em praticamente todas as conversas.

Entidade.

• Pessoa.
• Empresa.
• Projeto.
• Meta.
• Documento.
• Agente.
• Artigo.
• Setor.
• Decisão.
• Obra.
• Campanha.
• Produto.
• Serviço.
• Cidade.
• Referência.

Daqui a pouco parece que estou resolvendo tudo dizendo:

É entidade.

E isso começa a ficar perigosamente parecido com não explicar nada.

Então precisei voltar à pergunta: afinal, o que eu estou chamando de entidade?

01Não é simplesmente uma linha no banco de dados

Essa distinção é importante.

Tecnicamente, claro, alguma representação dela vai parar no banco. Tem ID. Tipo. Campos. Metadados.

Mas isso é implementação.

Não é o conceito.

Se eu cadastro nome: Empresa Alfa · tipo: cliente · status: ativo, tenho um registro.

Ainda conheço muito pouco sobre aquela empresa.

Agora começo a relacionar:

• EMPRESA ALFApertence_ao → SETOR
• EMPRESA ALFApossui → PESSOAS
• EMPRESA ALFAutiliza → SERVIÇOS
• EMPRESA ALFApossui → PROJETOS
• EMPRESA ALFArelacionada_a → CONTRATOS
• EMPRESA ALFAparticipou_de → REUNIÕES
• EMPRESA ALFAtomou → DECISÕES

A entidade começa a ganhar contexto.

02E eu percebi que havia algumas dimensões que se repetiam

Independentemente de ser uma pessoa, empresa, projeto, agente ou documento, eu acabava querendo saber algumas coisas.

03Identidade não é só nome

Uma entidade precisa conseguir ser reconhecida.

• Qual é seu tipo?
• Qual nome? Qual slug?
• Qual estado?
• Quem a criou?
• A qual contexto pertence?
• Existe uma identidade externa?
• É a mesma entidade que já existe em outro lugar?

Essa última pergunta é importantíssima.

Porque duplicação de realidade é um problema silencioso.

João Silva entra pelo CRM. Depois aparece em uma reunião. Depois numa proposta. Depois no financeiro. Depois em um formulário.

Se cada módulo cria seu próprio João Silva, voltamos ao problema que eu estava tentando resolver desde o começo.

Temos cinco registros.

Mas existe uma pessoa.

Então identidade também envolve reconciliação.

Isto aqui é a mesma coisa que aquilo?

Essa pergunta parece banal até você tentar integrar cinco sistemas.

Aí ela vira uma religião.

04Propriedade também não é simplesmente campo

Campo é representação.

Propriedade é algo que descreve a entidade.

Uma pessoa pode ter data de nascimento. Uma empresa, CNPJ. Uma tarefa, prazo. Uma reserva, check-in. Um artigo, título.

Mas uma propriedade possui semântica.

• Tipo.
• Formato.
• Origem.
• Validação.
• Talvez unidade.
• Talvez temporalidade.
• Talvez confidencialidade.
• Talvez regra.

Então aquele campo inocente valor: 100 é quase inútil.

Cem o quê? Reais? Dólares? Quilos? Pessoas? Percentual? Horas? Qual período? Quem informou? Quando?

Dados sem contexto parecem informação até precisarmos usá-los.

05Relação talvez seja a parte mais importante

Porque propriedade explica uma entidade.

Relação começa a explicar o mundo ao redor dela.

Empresa Alfa possui 50 funcionários.

É informação.

Mas EMPRESA ALFA → emprega → PESSOA abre possibilidades.

Quem? Em qual departamento? Qual função? Participa de quais projetos? É responsável por quais metas? Tomou quais decisões? Possui quais skills?

A relação transforma um número em estrutura navegável.

É por isso que o grafo continuava voltando.

Não porque eu queria uma tela bonita cheia de bolinhas.

Mas porque relações são dados.

06E uma relação também precisava ter identidade

Isso foi ficando mais interessante.

Imagine PESSOA → trabalha_em → EMPRESA. Parece suficiente.

Só que talvez eu queira saber: desde quando? Até quando? Qual cargo? Qual departamento? Qual regime? Está ativo? Quem informou?

Ou PESSOA → responsável_por → PROJETO. Desde quando? Com qual papel? Responsabilidade total? Compartilhada?

Então percebi que, em alguns casos, a própria relação começa a ter propriedades.

Isso muda bastante a modelagem.

Porque o mundo não é feito apenas de coisas.

Também é feito da natureza das conexões entre elas.

07E depois veio o tempo

Essa foi outra virada.

Uma empresa é cliente. Talvez. Hoje. Mas há dois anos não era.

Uma pessoa trabalha numa empresa. Até deixar de trabalhar.

Uma meta é prioritária. Até a estratégia mudar.

Um projeto está ativo. Até ser concluído.

Uma informação pode ser verdadeira hoje e falsa amanhã.

Então eu não queria simplesmente sobrescrever tudo. status: ativo vira status: encerrado e pronto — o estado anterior desapareceu.

Não.

Eu queria conseguir perguntar:

• Como isso era em março?
• Quando mudou?
• Por quê?
• Quem alterou?
• Qual decisão provocou a mudança?

Aí histórico deixa de ser log técnico.

Vira parte da entidade.

08Foi quando comecei a pensar em entidade como trajetória

Isso me agrada mais.

Uma entidade não é apenas aquilo que ela é agora.

Ela também possui aquilo que foi.

• ESTADO A
• →
• EVENTO
• →
• ESTADO B
• →
• DECISÃO
• →
• ESTADO C

Agora temos história.

E se temos história, ON consegue raciocinar sobre mudança. FLOW consegue reagir. ME consegue observar evolução. CORE consegue preservar.

Começa a ficar evidente por que essas camadas não poderiam existir isoladamente.

09Contexto também virou parte fundamental

Imagine uma entidade: Projeto Atlas.

Sem contexto, isso significa muito pouco.

• Por que existe?
• Qual problema resolve?
• Qual objetivo?
• Para qual empresa?
• Quem participa?
• Que produto está relacionado?
• Qual resultado esperamos?

Essa foi justamente a descoberta que eu estava fazendo enquanto usava a archē para gerenciar o próprio desenvolvimento.

Uma entidade importante não deveria simplesmente aparecer porque alguém clicou em + Novo Projeto.

Eu queria alguma resposta, mesmo que inicial, para:

Por que estamos criando isto?

E essa resposta pode mudar.

Tudo bem.

Preservamos a mudança.

10Isso começou a afetar até a criação das telas

Porque se esses núcleos são recorrentes, uma tela de entidade não deveria ser simplesmente um formulário gigante.

Ela poderia apresentar a entidade em camadas.

Primeiro: quem é.

Depois: o que importa agora.

Depois: com o que está conectada.

Depois: o que aconteceu.

Não necessariamente igual para todas.

Mas obedecendo ao mesmo princípio.

imagem pendente placa · tela-entidade captura de tela · largura total · proporção 16:10

11E aí o DNA ganhou uma função muito mais clara

O DNA não deveria guardar os dados daquela entidade.

Deveria descrever como aquele tipo de entidade funciona.

Então uma coisa é o DNA de Projeto.

Outra é Projeto archē.

O DNA descreve a espécie. A entidade é o indivíduo.

Essa metáfora resolveu muita coisa na minha cabeça.

12E o mais interessante é que o DNA pode ser extensível

Uma agência talvez precise acrescentar algumas propriedades a Projeto. Uma construtora, outras. Um projeto de pesquisa, outras.

Não quero destruir o conceito base.

Quero especializá-lo.

• PROJETOespecialização → PROJETO DE SOFTWARE
• PROJETOespecialização → PROJETO ARQUITETÔNICO
• PROJETOespecialização → CAMPANHA

Dependendo do domínio, talvez Campanha seja outra entidade relacionada, não uma especialização.

E justamente aí entra modelagem.

Não quero fingir que existe uma ontologia universal perfeita.

Quero um sistema capaz de fazer essa pergunta conscientemente.

13Isso trouxe um problema enorme e maravilhoso

Quem decide o que uma entidade é?

Eu? O desenvolvedor? O cliente? O agente? O setor?

A resposta começou a ser: depende.

• Existe uma base governada.
• Existem schemas.
• Existem entidades compartilhadas.
• Existem especializações setoriais.
• Existem extensões específicas de uma organização.
• E talvez estruturas temporárias para experimentação.

Foi aí que governança deixou de ser aquele capítulo chato que colocamos no final da documentação.

Ela passou a ser necessária para o sistema continuar crescendo sem virar bagunça.

14Porque flexibilidade sem governança é só caos sofisticado

Se qualquer agente puder decidir criar Cliente Premium Especial. E outro, Cliente VIP. E outro, Cliente Estratégico.

Daqui a seis meses ninguém sabe se são três conceitos ou três nomes para a mesma coisa.

Então a capacidade de criar precisava vir acompanhada da capacidade de perguntar.

Aquela última pergunta provavelmente deveria aparecer em letras enormes.

15E aí percebi uma coisa engraçada

Eu tinha começado querendo que a IA pudesse criar estruturas.

Mas, quanto mais avançava, mais importante ficava ensinar a IA a não criar.

• Não crie uma entidade se já existe uma adequada.
• Não crie campo sem entender a semântica.
• Não crie relação duplicada.
• Não crie skill se uma capacidade existente resolve.
• Não crie workflow sem verificar se há um reutilizável.
• Não crie documento só porque é possível.

Essa talvez seja uma das diferenças entre geração e arquitetura.

Gerar é fácil.

Manter coerência depois de milhares de gerações é o problema.

16E foi exatamente aí que a separação de camadas ficou séria

Eu precisava conseguir dizer: documentação é documentação, agente é agente, skill é skill, workflow é workflow, projeto é projeto, produto é produto.

Eles podem estar profundamente relacionados.

Mas uma coisa não deve fingir ser a outra.

Isso parece uma regra de organização de arquivos.

Na verdade é uma regra ontológica.

Se não sabemos o que uma coisa é, não sabemos quais regras deveriam governá-la.

17E comecei a enxergar a archē quase como uma gramática

Essa metáfora apareceu depois e eu gosto dela.

Entidades são como substantivos. Relações funcionam quase como verbos. Propriedades qualificam. Eventos introduzem tempo. Contexto altera significado.

E o grafo começa a formar frases.

Agora o sistema não possui apenas dados.

Ele começa a possuir afirmações estruturadas sobre a realidade.

E uma IA consegue trabalhar muito melhor quando existe algo assim por baixo.

18Talvez seja por isso que eu tenha insistido tanto em entidades

Não porque descobri alguma coisa nova.

Grafos existem há décadas. Ontologias existem. Knowledge graphs existem. Event sourcing existe. Modelagem de domínio existe. Metadados existem.

Nada disso nasceu aqui.

A parte que me interessa é outra.

Eu comecei a juntar essas ideias porque elas resolviam problemas que eu estava sentindo na prática.

E, quando comecei a juntá-las, percebi que serviam para muito mais do que organizar minha empresa.

• projetos;
• conhecimento;
• conteúdo;
• agentes;
• pessoas;
• setores;
• memória;
• e talvez parte daquela tentativa antiga de organizar a própria vida.

Tudo começava a usar uma linguagem parecida.

19E então surgiu uma pergunta inevitável

Se tudo importante pode ganhar identidade... se conseguimos preservar propriedades, relações, contexto, histórico e objetivo... e se conseguimos fazer isso tanto para uma empresa quanto para um projeto, um artigo, um agente ou uma pessoa...

então o que acontece quando começamos a conectar todos esses mundos?

• ARTIGO
• →
• CONCEITO
• →
• OBRA
• →
• PESSOA
• →
• PANTEON
• →
• AGENTE
• →
• WORKFLOW
• →
• PROJETO
• →
• META
• →
• EMPRESA
• →
• SETOR

E uma mudança em qualquer uma dessas coisas pode se tornar relevante para outra.

Foi quando eu olhei para aquele emaranhado e percebi: eu não estava mais construindo simplesmente um banco de dados.

Estava tentando construir um mapa.

Não um mapa estático.

Um mapa que muda. Que lembra. Que pode ser observado de lugares diferentes. Que começa a conseguir explicar por que duas coisas estão conectadas.

E foi aí que o grafo, finalmente, deixou de ser para mim uma tecnologia.

---

Esta série acompanha as perguntas, tecnologias, erros e ideias que foram transformando a archē de uma estrutura de organização em um sistema de contexto.