Saltar para o conteúdo
megapromotingVamos falar
Produtos Cronberry

Informação e coordenação Desenvolvimento e demonstrações

De informação dispersa, contexto de trabalho.

Cronberry reúne fontes autorizadas, conversas e relações num espaço de investigação e coordenação. A pesquisa semântica e os agentes ajudam a equipa a encontrar o que importa e a preparar o passo seguinte.

DocumenteConversațiiSurseSintezăAcțiuneEchipăContexteazăSurse autorizate. Acțiuni revizuite.
Cum funcționează Cronberry

Cronberry

Da informação ao trabalho feito.

01

Surse

Selecionamos as fontes e o acesso permitido: documentos, canais e conversas relevantes.

02

Context

Organizamos a informação por temas, relações e projetos, com a possibilidade de voltar à fonte.

03

Coordonare

Preparamos sínteses e ações para revisão, ligadas ao fluxo de trabalho da equipa.

Onde se torna útil.

Investigação e radar temático

Acompanhamento dos temas de interesse e recuperação da informação relevante.

Relações e oportunidades

O contexto das interações autorizadas, num local acessível à equipa.

Ligação com FlowMind

Exploramos a ponte entre a informação textual, os temas acompanhados e o contexto geoespacial.

Apresentamos a direção e as funções desenvolvidas. A implementação, as fontes ligadas e a disponibilidade são definidas no âmbito de uma demonstração. O acesso aos dados é controlado.

Cronberry em detalhe

O que você pode fazer com este projeto.

Cronberry é um motor de inteligência sobre relações, não uma ferramenta de pesquisa em documentos. Parte de um arquivo de conversas do Telegram e constrói a partir dele um grafo de conhecimento em Neo4j: contactos, empresas, grupos, canais, oportunidades, campanhas, produtos, locais, eventos e temas — dez tipos de entidades — ligados por oito tipos de relações, entre os quais „conhece”, „trabalha em”, „prometeu” e „objetou a”.

Sobre o grafo assentam três coisas que fazem a diferença face a um CRM: os gémeos digitais, ou seja, perfis gerados a partir do histórico de mensagens de uma pessoa, com os quais pode falar para antecipar uma reação; um otimizador que testa duas variantes de mensagem nesses perfis antes de enviar algo a uma pessoa real; e um simulador Monte Carlo que executa um plano de trabalho centenas de vezes e devolve uma distribuição de resultados, não um único valor.

É preciso dizer claramente que tipo de números produz: previsões, não medições. Quando o motor devolve uma probabilidade de resposta ou um intervalo de confiança, esses são resultados da simulação. No código existe a estrutura que deveria comparar a previsão com o que aconteceu de facto — `AccuracyStats`, com taxa de precisão e calibração da confiança — mas não encontrei no repo nenhuma série de medições reais para a preencher. Até existir, os números lêem-se como hipóteses de trabalho.

01

Grafo de conhecimento baseado em relações reais

Neo4j 5, com uma ontologia fixa de dez tipos de entidades e oito tipos de arestas, mais um modo em que a ontologia pode ser gerada por um modelo para análises pontuais. O enriquecimento corre em quatro passagens: pontuações de influência do tipo PageRank, deteção de comunidades por propagação de etiquetas, pesos de aresta a partir da frequência das mensagens e arestas do tipo «mencionou» extraídas dos padrões `@utilizador` no texto das mensagens.

02

Gémeos digitais com memória em três níveis

Um perfil gerado a partir do histórico de um contacto, com memória curta, memória longa e memória de relação. Três modos de utilização: conversa livre, preparação de negociação e previsão de resposta.

03

Testar uma mensagem antes de a enviar

O otimizador reescreve uma mensagem para um objetivo declarado e pode comparar duas variantes. O teste de stress leva a ideia mais longe: executa parâmetros como aumento de preço ou pressão de prazo em várias intensidades e devolve as áreas onde o contacto reage bem e as a evitar.

04

Simulação Monte Carlo sobre um plano escrito

O plano entra como texto, juntamente com a lista de contactos, o número de iterações e o horizonte em dias. Saem uma probabilidade de sucesso com intervalo de confiança, os pontos onde o plano bloqueia e o motivo de cada bloqueio. As simulações têm checkpoint, por isso uma execução longa pode ser retomada.

05

Os direitos da pessoa, implementados como endpoints

O módulo GDPR não é uma página de política: tem exportação completa dos dados de um contacto (art. 15 e 20), eliminação que atua ao mesmo tempo em SQLite, em Neo4j, em previsões e no registo de consentimento, com registo de eliminação (art. 17), retificação (art. 16), estado e revogação de consentimento, registo das atividades de tratamento (art. 30) e um endpoint de explicação de uma previsão, para o requisito de transparência do regulamento europeu sobre IA.

06

O custo do modelo, contabilizado

O cliente de modelo mantém um contador de custo por chamada e uma cache em memória com expiração a 3600 segundos e no máximo 512 entradas, mais um limitador próprio de pedidos por minuto ao fornecedor. O modelo principal é Azure OpenAI, com Groq como variante rápida de reserva.

Dados e funcionamento

O que entra no sistema. O que deve ser verificado.

O corpus atual é privado e pessoal
O caminho na configuração de arranque mostra uma base SQLite com o histórico pessoal do Telegram. Isto é adequado para desenvolvimento e completamente inadequado para um serviço: uma implementação num cliente começa com as fontes dele, com a finalidade declarada e com a base legal para o tratamento, não com este corpus.
Dois repositórios, uma só eliminação
Os dados estão em SQLite (a fonte) e em Neo4j (o grafo), e as previsões num terceiro lugar. A eliminação a pedido atinge os três mais o registo de consentimento e escreve um registo — porque uma eliminação que deixa a cópia no grafo não é uma eliminação.
O que protege o serviço à entrada
Limitação de pedidos com balde de tokens: 100 pedidos a cada 60 segundos por endereço IP, global, mais limites mais apertados nos endpoints caros. Cabeçalhos de segurança estritos, com política de conteúdo que bloqueia scripts e frames, HSTS por um ano com subdomínios e política de permissões que fecha a câmara, o microfone, a localização e os pagamentos. As origens permitidas são configuradas por variável de ambiente.
O que falta na entrada, e conta
A autenticação. No seu próprio plano de segurança, o capítulo de autenticação e autorização está totalmente por preencher: sem validação de token nos endpoints do motor, sem funções, sem chaves API armazenadas como hash, sem bloqueio após tentativas repetidas. Até ser resolvido, o motor funciona atrás de uma rede controlada, não na internet.

Da exploração à implementação

Como preparamos um projeto com Cronberry.

01

Primeiro a fonte e a base, depois o código

O primeiro passo não é técnico: que dados a organização tem o direito de tratar, para que finalidade e durante quanto tempo. O corpus de desenvolvimento não é reutilizado.

02

Construímos o grafo com os dados do cliente

Importação no Neo4j, depois as quatro passagens de enriquecimento. A ontologia fixa cobre o padrão de CRM no Telegram; para outro tipo de material, pode ser gerada uma específica.

03

Fechamos o gate antes de qualquer exposição

Autenticação, funções e chaves armazenadas como hash são condição de lançamento, não melhoria posterior. A limitação de pedidos e os cabeçalhos de segurança já existem e permanecem ativos.

04

Calibramos as previsões com resultados reais

A estrutura de medição da exatidão existe no código. Um piloto útil significa registar o que o motor previu e o que aconteceu, até que os números tenham um historial por trás.

Perguntas que vale a pena esclarecer.

Posso entrar em cronberry.ai para ver?

Não, e não é um problema temporário de servidor. O domínio não resolve de todo: a consulta DNS devolve NXDOMAIN, e o registo .ai responde `Domain not found` — verificado em 6 de setembro de 2026. O servidor indicado na documentação do projeto, `74.248.16.185`, também não responde na porta do motor. O que existe e pode ser mostrado: o código, que corre localmente, e uma demonstração preparada num conjunto de dados acordado.

O site descreve-o como espaço de trabalho para documentos e pesquisa semântica. É assim?

Não, e isso é um erro que estamos a corrigir. O projeto não é um motor de pesquisa sobre documentos. É um motor de inteligência sobre relações, construído a partir de um arquivo de conversas: grafo Neo4j, perfis de contacto gerados a partir do histórico, teste de mensagens nesses perfis e simulação Monte Carlo sobre um plano. O texto do site descreve um produto diferente do código que existe.

O que significa «probabilidade de resposta 0,67»?

Significa uma saída de simulação, não uma medição. O motor executa o plano centenas de vezes em perfis gerados a partir do histórico e apresenta a distribuição. No código existe a estrutura que compararia a previsão com a realidade — taxa de exatidão e calibração da confiança — mas não encontramos nenhuma série de medições que a preencha. Portanto, o número é usado para ordenar opções entre si, não como promessa de resultado.

Pode correr com os dados dos nossos clientes, e não com um arquivo pessoal?

Sim, mas esse é o primeiro passo de qualquer implementação, não uma adaptação no fim. O corpus atual de desenvolvimento é um arquivo pessoal do Telegram, indicado diretamente na configuração de arranque, e não é reutilizado. A importação parte das fontes da organização, com finalidade e fundamento de tratamento definidos antes.

O que acontece quando uma pessoa pede a eliminação dos dados?

Existe um endpoint dedicado, e a eliminação não é parcial: afeta SQLite, Neo4j, as previsões geradas sobre essa pessoa e o registo de consentimento, e escreve um registo de eliminação. Também estão implementados a exportação completa, a retificação, o estado do consentimento, o registo dos tratamentos e a explicação de uma previsão.

Está pronto para ser exposto na internet?

Não, e a razão é precisa: a autenticação. O capítulo de autenticação e autorização do próprio plano de segurança está integralmente por assinalar — não existe validação de token nos endpoints do motor, funções, chaves API armazenadas como hash ou bloqueio após tentativas repetidas. O que já existe: limitação a 100 pedidos por 60 segundos por IP, limites mais apertados nos endpoints dispendiosos, cabeçalhos de segurança estritos e origens configuráveis. Com o gate de entrada fechado, a discussão sobre lançamento torna-se real.

A documentação interna assinala muitas coisas como feitas. É possível verificar?

Em parte, e vale a pena dizer. A lista de segurança remete para ficheiros que não existem no repositório (`swarm_api.py`, `security_middleware.py`, `gdpr_routes.py`). O código correspondente existe, no entanto, noutro sítio: `cronberry_swarm/security/rate_limiter.py`, `headers.py` e `gdpr.py`. Portanto, as marcações descrevem funcionalidade real, mas as referências estão erradas — segui-as no código, não na lista.

Exemplo ilustrativo

Um plano de trabalho passado por simulação antes de ser iniciado

Um cenário de utilização, sem dados de cliente nem resultados comerciais atribuídos.

Situação inicial

Uma equipa escreve um plano em texto — quem contacta, em que ordem, por que canal — e escolhe a lista de contactos, o número de iterações e o horizonte em dias.

Como funciona

O motor executa o plano centenas de vezes sobre os perfis gerados a partir do histórico de cada contacto, no modelo da plataforma Telegram. A execução tem checkpoint, por isso pode ser retomada se for interrompida.

Rezultatul

Uma probabilidade de sucesso com intervalo de confiança, a lista dos passos onde o plano fica bloqueado e a razão de cada bloqueio, além da ordem sugerida dos contactos. Tudo são saídas de simulação, para usar a fim de comparar variantes entre si.

Ce este necesar:Sursă de date proprie a organizației, cu scop și temei de prelucrare stabilite; Neo4j pornit și graful importat; cheie de model configurată. Nu există azi o instanță publică pe care să rulezi asta.

Possibilidades de colaboração

Cronberry, no contexto da sua organização.

Fluxos internos e informação

A ligação das fontes autorizadas, a organização da informação e a revisão das ações pela equipa, com acesso separado por funções.

Empresas privadas

Definimos um piloto em torno de um processo real: utilizadores, dados, integrações, custos e critérios de aceitação. A expansão segue após a avaliação do resultado.

Instituições e empresas públicas

Estabelecemos os requisitos de acessibilidade, alojamento, proteção de dados e interoperabilidade. Qualquer ligação a serviços AGE ou STISC requer a validação da elegibilidade, do acesso e das aprovações.

Estes são cenários de adaptação, não declarações sobre contratos ou parcerias existentes. As funções propostas confirmam-se no âmbito de trabalho do projeto.

Fale sobre um piloto

Parte de um ecossistema.

O que gostaria que funcionasse melhor?

Conte-nos o seu processo. Em conjunto decidimos o que vale a pena construir, o que podemos ligar e como verificamos o resultado.

Vamos falar