Glossário

O que o cliente pede a uma pessoa, com tipo e nível.

Um tipo do catálogo, um nível mínimo de garantia e um contexto opaco. A política resolve as etapas; cada etapa consulta uma fonte; ao terminar, o ato deixa um recibo. Positivo, negativo, inconclusivo, expirado, cancelado ou falhou.

O tipo diz que pergunta o ato responde; o nível, quanta garantia.

Doze tipos no catálogo, de presença recorrente a assinatura. Quatro níveis: 0, sem humano novo; 1, posse forte; 2, presença viva e mesma pessoa; 3, presença e identidade civil. O recibo carrega o nível atingido, não o pedido.

Um passo da jornada, com id fixo, resultado e instante.

Transparência do contexto, consentimento geral, consentimento biométrico, presença viva com match e resultado são as cinco em produção. Cada etapa consulta uma fonte e entra no recibo.

Traduz tipo e nível em etapas; a versão vai no recibo.

Global e versionada; o cliente endurece por tipo no painel, com regras por contexto e reaproveitamento de prova recente.

O que uma etapa consulta, pela mesma interface, com rótulo no recibo.

Presença viva e match são nativas. Identidade civil, conta federada, posse, assinatura, documento e estado vital são plugadas: adapter com contrato real e mock; a real entra com o credenciamento ou o cliente.

Há um humano vivo agora, e é a mesma pessoa da referência?

Desafio ativo por um componente certificado de terceiro, e comparação com a imagem de referência do cliente, guardada cifrada só enquanto o ato está aberto. Imagem e template são descartados; ficam o resultado e o hash da referência.

Geral antes de tudo; biométrico antes de qualquer captura.

Textos versionados; cada aceite grava instante, hash do texto e versão, e o recibo os carrega. O geral nunca desbloqueia biometria.

O que o ato deixa: assinado, encadeado, só hashes.

Um objeto JSON com o que aconteceu (tipo, nível, resultado, etapas, fontes, garantias, consentimentos, política) e tudo o que diz respeito à pessoa em hash. Assinado com ES256 sobre o canônico RFC 8785; verificável sem a Hummand.

Cada recibo aponta para o anterior do mesmo cliente por hash.

O primeiro aponta para um gênesis derivado do id do cliente. Um lote reconstrói a ordem pelos hashes, em qualquer ordem de entrada, e acusa buraco no meio, inserção, reordenação e bifurcação. O corte do fim a cadeia sozinha não acusa, porque o que sobra continua contínuo desde o gênesis: quem resolve isso é o ponto de conferência.

A chave que verifica o recibo, publicada; o kid diz qual.

A chave privada fica num módulo de chaves gerenciado, de onde nunca sai. A pública é publicada como JWKS em gateway.hummand.com.br/.well-known/humanproof/keys.json; o kid dentro do recibo seleciona a chave, e a rotação é por kid.

Confere assinatura, formato, coerência e cadeia, sem a Hummand.

A mesma implementação em Rust roda no servidor, na linha de comando (humanproof-verify) e no navegador, em WebAssembly, sem enviar nada.

Uma presença nova no meio de um processo, por causa de uma ação sensível.

De transação, cadastral ou de operador. A política pode aceitar um ato positivo recente e encurtar para o nível 1 com passkey; a presença recorrente nunca reutiliza.

Dois humanos distintos aprovaram, cada um com presença.

Dois step-ups de operador encadeados num grupo, com a exigência de humanos distintos; recibo composto, um por operador, ligados pelo grupo.

Um humano com presença provada autoriza uma pessoa ou um agente, com escopo e prazo.

O mandato deixa recibo com o escopo (ações, limites, validade, revogável). Um ato delegado é uma ação sob mandato: verifica que ele existe, vale, não foi revogado e cobre a ação; sem presença nova, nível 0.

Um ato aberto por um gatilho externo, com política de escalada.

A origem é o cliente ou uma fonte de estado vital, a pedido; a referência do gatilho entra em hash, nunca o motivo. O default escala ao nível 3. A fonte só dispara; a prova continua sendo a presença.

Cada registro tem a sua chave; apagar é destruir a chave.

A chave de dados de cada registro é embrulhada pela chave-mestra no módulo de chaves. Destruí-la torna o texto cifrado irrecuperável: é o apagamento a pedido e por prazo de retenção.

Disponível, em credenciamento, arquitetura-alvo.

Toda capacidade leva um dos três, em toda superfície: código, docs, site. Disponível está em produção; em credenciamento existe no código e depende de um terceiro; arquitetura-alvo existe no catálogo, no motor ou no plano, sem tela, sem provider ou sem fase iniciada.

O que a cadeia sozinha não prova: que não falta ninguém no fim da série.

Uma cadeia isolada acusa o buraco no meio, e não o corte do fim: o que sobra continua contínuo desde o gênesis, e numerar não resolve, já que uma sequência de 1 a N não revela que existia N+1.

O ponto de conferência é um objeto assinado, com a mesma chave dos recibos, que afirma quantos recibos existiam e qual era o último hash. Quem audita pede o ponto, guarda fora da Hummand e compara depois. A Hummand não guarda cópia, porque a única cópia que vale é a de quem audita.

Desde 2026-09-24 existe a versão 2 do ponto, que afirma as duas cadeias de um cliente, a de atos e a de acessos à evidência, e o verificador confere cada uma contra o que o ponto diz dela. A versão 1 continua válida para a cadeia de atos.

Tenant é o cliente; sandbox é o modo de teste que não gera recibo na cadeia.

Cada cliente é um tenant, isolado por linha no banco, com chaves de API por escopo e um segredo próprio para os hashes de referência. Em sandbox o resultado é simulado e nada consome presença nem entra na cadeia de recibos.

Produto da Hummand e primeira iniciativa da sua divisão de IA.

Supervisão de ações de sistemas de IA: autoridade vinculada a uma pessoa real, intervenção em camadas e evidência verificável. Usa o recibo humanproof/1; não o produz. Documento de início, em descoberta, ainda sem capacidade no catálogo.

Não confundir com Alertas, que são sinais do registro de atos.

Cada abertura da evidência de um ato deixa um recibo assinado, verificável fora da Hummand.

Abrir o conteúdo cifrado de um ato exige uma pessoa e um motivo declarado. Desde 2026-09-24, cada abertura gera um recibo assinado com a mesma chave dos recibos de ato, numa cadeia separada por cliente, com gênesis próprio, porque acesso não é ato. Recusa e falha também viram recibo.

O recibo diz quem abriu, por papel e id opaco, o que foi tocado, o desfecho e quando. O motivo entra só como hash: quem tem o texto confere; quem não tem, não lê. O verificador lê o formato desde a 0.3.0, na linha de comando e no navegador.