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, inconclusive, expired, cancelled or failed.

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 reached, not the one requested.

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 goes 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; every acceptance records the timestamp, the hash of the text and the version, and the receipt carries them. 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.

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; the kid inside the receipt selects the key, and rotation is by kid.

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; composite receipt, one per operator, linked by the group.

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.

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 secret for the reference hashes. 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.