Glossary

What the client asks of a person, with a type and a level.

A catalogue type, a minimum guarantee level and an opaque context. The policy resolves the steps; each step queries a source; when it finishes, the act leaves a receipt. Positive, negative, expired, cancelled, failed or revoked.

The type says which question the act answers; the level, how much guarantee.

Twelve types in the catalogue, from recurring presence to signature. Four levels: 0, no new human; 1, strong possession; 2, live presence and same person; 3, presence and civil identity. The receipt carries the level required and the level reached (only the level reached in revision 1).

One stage of the journey, with a fixed id, a result and a timestamp.

Context transparency, general consent, biometric consent, live presence with match and result are the five in production. Each step queries a source and enters the receipt.

Turns type and level into steps; the version and hash go in the receipt.

Global and versioned; the client hardens it per type in the dashboard, with context rules and reuse of a recent proof.

What a step queries, through the same interface, with a label in the receipt.

Live presence and match are native. Civil identity, federated account, possession, signature, document and vital status are plugged: adapter with real contract and mock; the real one enters with accreditation or with the client.

Is there a living human right now, and is it the same person as the reference?

Active challenge by a certified third-party component, and comparison with the client's reference image, kept encrypted only while the act is open. Image and template are discarded; the result and the hash of the reference remain.

General before everything; biometric before any capture.

Versioned texts, published at /consentimentos; every acceptance records the timestamp and the version, and the receipt carries them with the hash of the text shown. In revision 1 receipts, the hash was that of the consent identifier. The general one never unlocks biometrics.

What the act leaves: signed, chained, hashes only.

A JSON object with what happened (type, level, result, steps, sources, guarantees, consents, policy) and everything about the person hashed. Signed with ES256 over the RFC 8785 canonical form; verifiable without Hummand. Since 2026-10-30, in revision 2: every guarantee says who backs it, and signatures come by role.

Every receipt points to the same client's previous one by hash.

The first one points to a genesis derived from the client id. A batch rebuilds the order from the hashes, in any input order, and exposes a gap in the middle, insertion, reordering and forking. The chain alone does not expose a cut at the end, because what is left stays continuous from the genesis: what solves that is the checkpoint.

The key that verifies the receipt, published; the kid says which one.

The private key lives in a managed key module and never leaves it. The public key is published as a JWKS at gateway.hummand.com.br/.well-known/humanproof/keys.json; each signature in the receipt carries the kid of the key, and rotation is by kid. The JWKS also publishes retired keys, so older receipts keep verifying; the format allows a validity per key, and the current key has no declared expiry.

Checks signature, format, coherence and chain, without Hummand.

The same Rust implementation runs on the server, on the command line (humanproof-verify) and in the browser, in WebAssembly, sending nothing.

A new presence in the middle of a process, because of a sensitive action.

Transaction, registration or operator. The policy may accept a recent positive act and shorten to level 1 with a passkey; recurring presence never reuses.

Two distinct humans approved, each with presence.

Two operator step-ups chained in a group, with the requirement of distinct humans; one receipt per operator; in revision 2, the one that closes the pair lists both, with commitments of distinct people, and points by hash to the presence of the first.

A human with proven presence authorizes a person or an agent, with scope and deadline.

The mandate leaves a receipt with the scope (actions, limits, validity, revocable). A delegated act is an action under mandate: it checks that the mandate exists, is valid, was not revoked and covers the action; no new presence, level 0.

An act opened by an external trigger, with an escalation policy.

The origin is the client or a vital-status source, on request; the trigger reference enters hashed, never the reason. The default escalates to level 3. The source only triggers; the proof is still the presence.

Every record has its own key; erasing is destroying the key.

The data key of every record is wrapped by the master key in the key module. Destroying it makes the ciphertext unrecoverable: that is erasure on request and by retention period.

Available, in accreditation, target architecture.

Every capability carries one of the three, on every surface: code, docs, site. Available is in production; in accreditation exists in the code and depends on a third party; target architecture exists in the catalogue, the engine or the plan, with no screen, no provider or no phase started.

What the chain alone cannot prove: that nobody is missing from the end of the series.

An isolated chain exposes a gap in the middle, and not a cut at the end: what is left stays continuous from the genesis, and numbering does not solve it, since a sequence from 1 to N does not reveal that N+1 existed.

The checkpoint is a signed object, with the same key as the receipts, stating how many receipts existed and what the last hash was. Whoever audits asks for the checkpoint, keeps it outside Hummand and compares later. Hummand keeps no copy, because the only copy that counts is the auditor’s.

Since 2026-09-24 there is version 2 of the checkpoint, which states both chains of a client, acts and evidence accesses, and the verifier checks each against what the checkpoint says about it. Version 1 remains valid for the chain of acts.

In revision 2, each checkpoint points by hash to the previous one of the same client: a checkpoint removed from the middle shows to whoever kept its neighbours.

A tenant is a client; sandbox is the test mode that puts no receipt in the chain.

Every client is a tenant, isolated by row in the database, with scoped API keys and its own reference key, which the Administrator sees in the dashboard. In sandbox the result is simulated and nothing consumes presence or enters the receipt chain.

Hummand's product and the first initiative of its AI division.

Supervision of the actions of AI systems: authority bound to a real person, layered intervention and verifiable evidence. It uses the humanproof/1 receipt; it does not produce it. A start document, in discovery, with no capability in the catalogue yet.

Not to be confused with Alerts, which are signals from the register of acts.

Every opening of the evidence of an act leaves a signed receipt, verifiable outside Hummand.

Opening the encrypted content of an act requires a person and a declared reason. Since 2026-09-24, every opening produces a receipt signed with the same key as the act receipts, on a separate chain per client with its own genesis, because an access is not an act. Refusal and failure become receipts too.

The receipt says who opened, by role and opaque id, what was touched, the outcome and when. The reason enters only as a hash: whoever holds the text checks it; whoever does not, cannot read it. The verifier reads the format since 0.3.0, on the command line and in the browser.

The current form of the humanproof/1 receipt, since 2026-10-30T05:21:39Z.

Marked by revisao: 2 in the receipt. It is not a new format: the format is still humanproof/1. Receipts completed before the cutoff follow revision 1 and verify as before; after the cutoff, a receipt without revisao is rejected.

The reference of the person in the receipt, without revealing it.

HMAC of the reference the client gave the person, under the client reference key and a fresh salt per receipt. Without the key, the commitment neither reveals the reference nor links two receipts of the same person; when there was a comparison, the hash of the reference image is the same in the receipts that used the same image.

With the key, which the Administrator sees in the dashboard, the client recomputes the commitment and checks on its own that the receipt is about that person.

Every guarantee in the receipt says where it comes from.

In revision 2, every guarantee carries who backs it: the source component, human review, the client declaration, the official base or the mandate. Human review decides the act, never the presence: no biometric guarantee is backed by it.

The date of the receipts attested by a third party that is not Hummand.

Once a day, the checkpoints and the receipts of the day go into a tree whose root receives a time stamp from an ICP-Brasil Time Stamp Authority, and each anchoring chains to the previous one.

In accreditation: switched off until the contract with the authority, and the public list of heads stays empty until then.