Para empresas que querem crescer com controle

Um sistema para operar sua empresa com IA.

Vendas, marketing, atendimento, operação, financeiro e inteligência trabalhando sobre o mesmo contexto — para sua empresa ganhar escala sem perder controle.

Sua empresa inteira. Uma operação. IA trabalhando.

Ver a Centriu funcionando

Para empresas de qualquer setor que querem crescer com estrutura, controle e inteligência.

Representação ilustrativa do trabalho em execução

O problema

Sua empresa não deveria operar em pedaços

Não é falta de ferramenta. É que cada ferramenta resolve um pedaço, e ninguém é dono do todo. O custo disso não aparece numa fatura — aparece no mês seguinte.

Sistemas que não se falam
O mesmo dado é digitado de novo — e cada cópia conta uma história diferente.
Dados duplicados
Ninguém sabe qual versão é a verdadeira na hora de decidir.
Conversas perdidas
O cliente repete o contexto a cada canal e a cada pessoa.
Tarefas espalhadas
O trabalho vive em planilhas, mensagens e na memória de alguém.
Decisões sem contexto
A escolha é feita com o recorte que estava à mão, não com o que importava.
Automações desconectadas
Cada ferramenta automatiza um pedaço e ninguém enxerga o todo.

Nenhum desses problemas se resolve comprando mais um software. Eles se resolvem quando a operação inteira passa a trabalhar sobre o mesmo contexto.

A resposta

Tudo trabalha sobre o mesmo contexto.

A Centriu não é uma coleção de produtos. É uma plataforma em que clientes, áreas e agentes leem e escrevem no mesmo lugar.

Cliente 360

Um contexto, não vários cadastros

Cada conversa, tarefa, campanha, cobrança e decisão fica ligada ao cliente e à operação — não a um sistema isolado.

Clientes
Comercial
Atendimento
Operação
Financeiro
Marketing
Inteligência
Agentes
Consultoria

As áreas abaixo são partes da mesma operação, não produtos separados. Elas compartilham conta, permissões e histórico.

IA que trabalha — não um chatbot ao lado

A inteligência artificial da Centriu participa da operação: entende contexto, prepara trabalho, executa rotinas e pede aprovação quando importa.

Entende o contexto

Lê a operação, o cliente e o histórico antes de propor qualquer coisa.

Prepara o trabalho

Redige, organiza, calcula e deixa pronto para revisão humana.

Executa rotinas

Roda o que é repetitivo dentro dos limites definidos pela empresa.

Recomenda a próxima ação

Cruza áreas, identifica prioridade e mostra o motivo da recomendação.

Pede aprovação

O que é sensível passa por uma pessoa antes de valer. Sem exceção silenciosa.

Mantém histórico e aprende

Registra o que aconteceu e usa o resultado para melhorar a próxima decisão.

O que a Centriu faz

Uma plataforma, várias frentes de trabalho. Tudo no mesmo contexto, com a IA participando do que dá para acelerar.

Comercial

CRM, pipeline, oportunidades, propostas, follow-up e automações.

Atendimento

WhatsApp, Instagram, Messenger, chat do site e e-mail no mesmo contexto.

Operação

Tarefas, responsáveis, prazos, aprovações, agenda e capacidade.

Financeiro

Contas, cobranças, caixa, fiscal, margem, IR, orçamento e inteligência econômica.

Marketing

Planejar, produzir, aprovar, publicar e medir conteúdo e campanhas.

Inteligência

Painéis, alertas, previsões, recomendações e leitura executiva.

Agentes

Rotinas executadas continuamente pela IA com controle e aprovação.

Consultoria

Diagnóstico, estratégia, transformação, acompanhamento e especialistas.

Para quem é

Para empresas que querem crescer — e crescer certo.

A Centriu faz sentido quando o volume aumenta e a estrutura precisa acompanhar. Não é sobre setor nem tamanho: é sobre a operação conseguir sustentar o próximo estágio.

As vendas crescem, mas o processo não acompanha.

As áreas trabalham separadas e o cliente sente.

A operação depende de pessoas específicas.

O financeiro ficou complexo e o caixa perde visibilidade.

O atendimento cresce em volume e em canais.

A IA entra sem contexto, controle ou histórico.

Se a empresa ainda não começou a crescer, a Centriu também ajuda a preparar a estrutura para o primeiro salto.

Ver a Centriu funcionando

Consultoria

Tecnologia sozinha não resolve uma operação mal desenhada.

A Centriu combina tecnologia, inteligência, método e acompanhamento. A consultoria diagnostica, desenha, implanta e acompanha — com evidências, não com apresentação.

Diagnóstico e imersão na operação

Estratégia e prioridades

Roadmap de transformação

Desenho da arquitetura operacional

Implantação conduzida

Acompanhamento com evidências

Benchmarking e leitura de mercado

Especialistas, rede e inteligência coletiva

A participação de especialistas depende da solução e do contrato. Não é um item incluído automaticamente em toda contratação, e não prometemos acompanhamento humano ilimitado.

Veja a Centriu funcionando na sua operação

Uma conversa para entender onde a sua operação perde tempo, dinheiro ou capacidade — e o que a Centriu faria primeiro.

Ver a Centriu funcionando

problema

Cryptographic Tamper-Evident Action-Proof Chain Automation: From a Fake Hash Called "Proof" to a Real One

Centriu Axiom's internal enterprise AI has a "Verified Actions" feature. This feature captures before/after evidence for each action it takes. It uses a cryptographic hash to prove the record has not been tampered with. An internal audit found that every part of that promise was fake. The "hash" was a 32-bit, non-cryptographic algorithm. The code's own comment admitted it was a placeholder ("Simplified hash — in production use SHA-256"). The before/after screenshots pointed to a `mock://` path that never existed. The visual diff was a random number between 1 and 15. The "chain" only ever hashed a proof's own fields. It never hashed the previous proof. So, it could not detect a proof being deleted or reordered. This is the entire reason a chain exists. Worse, the feature had zero real callers anywhere in the product. The underlying table had 0 rows in production. The fix is a complete rewrite. It uses real SHA-256 hashing via the browser's own WebCrypto API. It has a genuine DOM capture uploaded to a real, private storage bucket. It uses an actual element-by-element diff matched by structural path. It has a real chain where each proof's link includes the previous proof's own link. It has a verification function that re-downloads every artifact to confirm nothing changed after capture. It is now truly connected to the product's real action-execution path.

Quero resolver isso

Why a feature that looks finished can be entirely fake underneath

A feature can display a hash in a monospace font next to the word "Proof." It can show a screenshot thumbnail. It can render a diff percentage. Every one of those visual signals can be completely disconnected from anything real underneath. Demo scaffolding is a normal, legitimate way to build a feature's UI before its real backend exists. The risk is entirely in what happens next. Scaffolding doesn't announce itself when it quietly becomes the permanent implementation. A feature whose entire job is to be shown to a skeptical person (a client disputing a bill, an auditor reviewing a decision) is exactly the worst place for that gap to go unnoticed.

A feature can display a hash in a monospace font next to the word "Proof." It can show a screenshot thumbnail. It can render a diff percentage. Every one of those visual signals can be completely disconnected from anything real underneath. Demo scaffolding is a normal, legitimate way to build a feature's UI before its real backend exists. The risk is entirely in what happens next. Scaffolding doesn't announce itself when it quietly becomes the permanent implementation. A feature whose entire job is to be shown to a skeptical person (a client disputing a bill, an auditor reviewing a decision) is exactly the worst place for that gap to go unnoticed.

Quero resolver isso

How Centriu Axiom rebuilt the proof mechanism to be genuinely verifiable

An internal audit of Axiom found the same failure pattern in nine different places across the module. A feature not yet ready returned a plausible-looking number instead of admitting it didn't know. The Proof-of-Action feature was the single largest of the nine. The audit's own account of it is specific. The hash was a 32-bit djb2 algorithm. This type of hash is designed for fast lookup tables, not tamper detection. The code's own prior comment openly admitted it was a stand-in ("Simplified hash — in production use SHA-256"). It was shown in a monospace font next to the word "Proof." The before/after screenshot and DOM-snapshot artifacts pointed to paths like `mock://proof/<id>/before-screen.png`. This is a protocol that does not exist. It referenced a file that was never created. The visual diff shown to a user was computed as `Math.floor(Math.random() * 15) + 1`. This was a random number, not a measurement. And the "hash chain," the mechanism meant to make tampering detectable, only ever hashed a single proof's own identifiers. It never referenced the previous proof at all. So a chain of any length behaved the same as a chain of one link. It could not detect a deleted or reordered proof. This is the one thing a chain exists to do. It was also confirmed during the rewrite that these capture functions had never actually been called from anywhere in the real product. The corresponding database table held zero rows in production.

The rewrite replaces every one of those pieces with something that can actually be checked. Hashing uses the browser's own WebCrypto SHA-256 implementation. If that is not available (WebCrypto needs a secure context), the code throws an error. It does not silently use a weaker algorithm. Silently using a worse hash is the exact failure this rewrite aims to fix. Capture reads the live DOM directly. It uploads the actual content to a real, private storage bucket. The returned artifact carries the SHA-256 of exactly what was uploaded. The diff checks both DOM snapshots element by element. It matches elements by their structural position in the tree. It compares tag, id, class, and direct text content. Additions, removals, and changes are counted from a real comparison. They are not generated at random. The chain link for each new proof includes the previous proof's own chain link. (Or a fixed starting value for an organization's first proof). So, changing, deleting, or reordering any proof breaks the chain link of everything that came after it. This is the entire point of a chain existing at all. And a new verification function actually uses all of this. It re-downloads every stored artifact. It recomputes its hash and compares it to what was recorded. It recomputes the expected chain link to confirm the sequence has not been disturbed. A proof nobody can independently verify was, in the audit's own words, decoration, not evidence.

The rewrite's real-world connection is directly confirmed in the product's current source. It is not just claimed in the historical commit. The action-execution flow calls the capture functions before and after every action Axiom takes for a person. The code's own comment on that call site records the same history this page describes. It states that until this fix, nothing in the app had ever called it.

Ver como funciona

What is actually built today

Real SHA-256 hashing via the browser's native WebCrypto API for every captured artifact. This replaces a 32-bit, non-cryptographic checksum.
A genuine DOM capture, uploaded to a real, access-controlled storage bucket. This is not a reference to a path that was never created.
An actual element-by-element DOM diff. It matches elements by structural position and compares their real content. This replaces a randomly generated number.
A genuine hash chain where each proof's link includes the immediately preceding proof's own link. Tampering with any proof in the sequence breaks the chain for everything after it.
A verification function that independently re-downloads and re-hashes every stored artifact. It also recomputes the expected chain link. It does not trust the stored record as is.
The mechanism is truly connected to the product's real action-execution path today. This is confirmed directly against the current source, not only the historical fix.

Conhecer os recursos

What changes operationally

A record labeled "Proof" now actually withstands the kind of scrutiny the word implies. It has a hash that cannot be easily faked. It has an artifact that truly exists and can be re-downloaded. It has a diff computed from a real comparison. It has a chain that truly breaks when tampered with, rather than silently accepting any edit. Anyone relying on this feature to settle a dispute about what Axiom actually did is now relying on something that can be independently re-checked. They are not relying on a plausible-looking number nobody could ever have verified in the first place.

A record labeled "Proof" now actually withstands the kind of scrutiny the word implies. It has a hash that cannot be easily faked. It has an artifact that truly exists and can be re-downloaded. It has a diff computed from a real comparison. It has a chain that truly breaks when tampered with, rather than silently accepting any edit. Anyone relying on this feature to settle a dispute about what Axiom actually did is now relying on something that can be independently re-checked. They are not relying on a plausible-looking number nobody could ever have verified in the first place.

Quero esses resultados

A proof that actually detects tampering (illustrative scenario, not a real client)

Someone with direct database access edits an old proof record's stored diff summary after the fact. They hope nobody checks. Before the rewrite, nothing would ever notice. The "chain" never referenced that record's neighbors. So an edited proof looked exactly like an untouched one. After the rewrite, running verification on any proof created after the edited one fails. The expected chain link no longer matches. This is because it was computed from the tampered proof's original, now-altered content.

Conversar sobre meu caso

How to get started

Começar agora

Frequently asked questions

What was actually fake about the original Proof-of-Action feature?

Everything visible was fake. The "hash" was a 32-bit, non-cryptographic checksum. The code's own comment admitted it was a placeholder. Screenshots pointed to a storage path that never existed. The diff was a random number. The "chain" never referenced the previous proof. So it could not detect tampering at all.

Did this feature ever actually run before the fix?

No. It was confirmed during the rewrite that the capture functions had zero real callers anywhere in the product. The underlying database table held zero rows in production.

How does the chain actually detect tampering now?

Each proof's chain link is computed from its own content. It also uses the immediately preceding proof's own link. Changing, deleting, or reordering any proof changes what the next proof's expected link should be. A special verification function checks this directly.

Can this mechanism be independently checked, or do I have to trust the stored record?

A verification function re-downloads every stored artifact. It recomputes its hash. It also recomputes the expected chain link. It does not trust the stored record as is.

Is this a pixel-level visual screenshot comparison?

No. It is a real, element-by-element DOM comparison. A visual-diff percentage was deliberately left out of the rewrite. It was not approximated. Guessing at that number is the exact failure being corrected.

What does Centriu Axiom cost?

It is sold by subscription with a published starting price. Exact current values are on the central pricing page.

Ainda tenho dúvida

See how Centriu Axiom proves what an AI action actually did

Quero resolver isso