Reveno Trust Score Protocol v1.0
Especificação aberta para declarar o quanto um componente de IA foi verificado de verdade. O protocolo separa origem, evidência e resultado para impedir que indexação, ausência de sinal ou uma nota heurística sejam confundidas com certificação.
Estados de evidência
not-tested significa evidência insuficiente; não é zero, aprovação ou reprovação. Community Tested exige evidência comunitária registrada e não equivale a auditoria. Reveno Verified é reservado a verificação real documentada pela Reveno. Estados not-tested são excluídos da nota, nunca tratados como zero.
Dimensões
- Utility: clareza e utilidade operacional.
- Security: sinais de execução, shell, rede e ações destrutivas.
- Transparency: origem, licença, permissões e documentação.
- Maintenance: atualização, versão e atividade observada.
- Governance: responsável, aprovação humana, auditabilidade e limites.
Resultados
Pass, warning, fail e insufficient-evidence descrevem o que foi observado em uma dimensão. Medium ou high risk significam necessidade de contexto e revisão, não uma ordem automática para evitar o componente. aprovação humana é proteção operacional, não defeito.
Metodologia
A análise automatizada é estática e não executa código externo. Cada score precisa mostrar denominador e evidência. Nenhum 100/100 pode aparecer se dimensões relevantes estiverem not-tested. Mudanças de versão podem alterar a postura e devem disparar nova análise.
Como usar
Use Trust como apoio à decisão: verifique origem, compatibilidade, permissões, credenciais, dependências, autonomia e pontos de aprovação humana; depois teste em ambiente controlado. Para stacks, observe a exposição combinada, não apenas a média individual.
Limitações
O protocolo não certifica segurança, não substitui auditoria e não prevê comportamento de execução real que não esteja visível no registro coletado. A especificação JSON está em trust-score-protocol.json, os dados públicos em Risk Observatory e a análise em Analyze anything.
Governança
Quando um componente entra em produção, toca dados reais ou executa ações externas, Governança de IA define dono, limites, logs e resposta.
Do catálogo para uma operação útil
O fluxo recomendado começa por uma necessidade concreta, não pelo volume de ferramentas. Defina o tarefa, a entrada, a entrega esperada e quem responde pelo resultado. Em seguida, descubra componentes, revise a origem, compare alternativas e escolha a menor capacidade suficiente. Quando houver mais de um componente, use o Stack Builder para documentar ordem, compatibilidade, permissões, conflitos e pontos de aprovação.
Checklist antes de instalar
- Confirme autor, repositório, licença, versão e última atualização.
- Revise rede, shell, arquivos, credenciais, dependências e ações externas.
- Entenda autonomia e onde uma pessoa precisa aprovar.
- Leia mudanças desde a versão anterior e preserve retorno à versão anterior.
- Teste com dados não sensíveis e acesso mínimo.
- Registre o resultado e acompanhe novas versões.
Como a confiança é comunicada
Not-tested significa que ainda não existe evidência suficiente; não é seguro, inseguro, aprovado ou reprovado. Community Tested exige evidência comunitária registrada, mas não é auditoria. Reveno Verified só pode aparecer depois de verificação real documentada. Estados sem teste são excluídos da nota e jamais transformados em zero. Risk medium ou high descreve necessidade de contexto e controle, não uma proibição automática.
Ativação, não pageview
O objetivo desta página é levar a uma ação operacional útil: copiar um comando, adicionar um componente à stack, gerar relatório, baixar arquivo de versões ou CLAUDE.md, compartilhar, fazer copiar e adaptar, iniciar acompanhamento ou avaliar a ponte enterprise. Essas ações formam a métrica Weekly Activated Operators.
Dados e limites
O Commons publica conjuntos de dados, JSONs canônicos, sitemaps segmentados e metodologia para permitir verificação e citação. Análise estática não executa código e não prevê todo comportamento de execução real. Compatibilidade declarada não é garantia. Popularidade sem janela e amostra não vira ranking.
Por que separar dimensões
Um componente pode ser útil e ainda ter manutenção desconhecida; pode ter origem clara e exigir rede; pode ter aprovação humana e continuar exposto a credenciais. Uma nota única esconde esses diferenças práticas. Por isso o protocolo preserva dimensões, evidência e limitações, permitindo decisão contextual e comparação histórica.
Como interpretar mudanças
O histórico importa tanto quanto a fotografia atual. Uma nova dependência, permissão de escrita, chamada externa ou troca de mantenedor pode alterar o contexto mesmo sem mudar o nome do componente. O protocolo registra evidência observável, data e método para que a revisão seja repetível. Ausência de sinal continua sendo desconhecida, nunca prova de segurança.
aprovação humana é proteção operacional, não defeito. Ele explicita o ponto em que uma pessoa confirma contexto, impacto ou ação externa. Em cenários de maior risco, esse gate pode aumentar controlabilidade sem reduzir a utilidade da capacidade.