Releases

Page 3 of 5, from the most recent release to the oldest.

C21humanproof-verify0.3.02026-09-24

The verifier reads the access receipt and the checkpoint of both chains

Third release with binaries for Linux, macOS and Windows, each with a checksum.

A batch may carry act receipts and evidence access receipts; the verifier groups them by format and by client and checks the chain of each group. The report says who opened, by role and opaque id, the outcome of each opening and when. Never the reason, only its hash, which whoever holds the text checks with a subcommand.

Version 2 of the checkpoint states both chains, acts and accesses, and each is checked against what the checkpoint says about it. A version 1 checkpoint on a batch with accesses does not approve by omission.

The report also comes out as a self-contained page, no script and no network, for whoever audits to keep next to the batch and print to PDF. It says what the text says, in the same sentences.

See Receipt
C22gateway0.17.02026-09-24

Every evidence opening produces a signed receipt, and a contract can be closed with a window

Four additive migrations in a single window; nothing changes in what the client already calls.

Opening the encrypted content of an act already required a person and a reason, and left a record. Now every opening produces a signed receipt, on a chain of its own per client, verifiable outside Hummand with the same public key as the act receipts. Refusal and failure become receipts too. Only hashes and opaque ids: the reason never leaves in the clear.

Closing a contract opens a read-only window of thirty days, enforced on the credential: the client reads and exports, writes answer with the reason and the date, and an erasure request is still served on the spot. At the end of the window, deletion is automatic and recorded.

Each step now records when it started, and the dashboard shows latency per source as a measurement, without judgement. Mandate revocation, which had no receipt, now has one. The act detail serves consents per layer. The client certificate per contract enters the code, switched off until the edge authenticates the origin.

See Security
C23humanproof-core0.3.02026-09-24

The receipt library gains the access format and the checkpoint of both chains

humanproof-acesso/1 and humanproof-ponto/2, with the same rules in Rust on the server, on the command line and in the browser.

The access receipt is a sibling format of the act receipt, signed with the same key, on a separate chain per client with its own genesis: an access is not an act. It says who opened, by role and opaque id, what was touched and the outcome; the reason enters only as a hash.

Batch verification now accepts mixed batches, grouped by format and client, and version 2 of the checkpoint states both chains. The humanproof/1 format remains humanproof/1.

Distributed by release, with checksums and a component inventory.

See Receipt
C24gateway0.16.02026-09-21

Production signs and checks its own receipt with library 0.2.0, and the contract names what it returns

No migration: the deploy is an image swap.

The gateway now signs and checks its own receipt with the same library that the command-line verifier, the SDK and the page on labs. apply: mandate coherence, revocation as a result of its own and the recipe for the context hash.

Twenty-six routes now declare in the contract what they return. The shape of the response does not change; what changes is the contract saying so, and the generated clients stop narrowing the type by hand.

See Docs
C25humanproof-verify0.2.02026-09-20

The verifier reads the mandate and checks the tail of the chain

Second release with binaries for Linux, macOS and Windows, each with a checksum.

A positive receipt whose grant does not authorise the action is now refused, and the report tells the mandate in words: the grant, the use, the fall and the reason. Before, a positive delegated act read like any other positive, and it is precisely the mandate that holds it up.

With a checkpoint kept beforehand by whoever audits, the verifier checks the batch against it and flags the removal of the last receipts, which the chain alone does not flag. Always two counts, the batch and the checkpoint, because whoever audits needs the difference and not only the verdict. The chain report now says continuous since genesis, because intact promised a completeness that only the checkpoint sustains.

See Receipt
C26humanproof-core0.2.02026-09-20

The receipt library gets a version, distribution and the checkpoint

Revocation as a result of its own, mandate coherence and the context hash recipe in the format.

Revoking a mandate is now a result of its own in the receipt, and coherence enforces what the schema did not: grant and use never in the same receipt, scope and grantee together, a result sustained by the claims of the mandate. The context hash recipe entered the format, so whoever sent the context can check it alone. The humanproof/1 format stays humanproof/1.

The checkpoint is a sibling format, signed with the same key: how many receipts existed and which was the last, for whoever audits to keep and compare later.

First tag of the repository: the library is now distributed by release, with checksums and a software bill of materials, and the browser verifier at labs. uses the same version.

Open the verifier
C27gateway0.15.02026-09-18

Erasure by the id the client holds, and three act types labelled available

No migration: the deploy is an image swap.

Erasure at the request of the data subject now reaches the standalone document validation by the verdict identifier, which is what the client receives since the route exists. The previous target asked for an id that never left the server; this one also reaches validations already made. Consent, verdict and trail die together, and the request records what died.

Agent mandate, delegated act and the presence step of the reviewer become available in the catalogue the dashboard reads, closing a divergence between what this site said and what the client saw on the policy screen. The label is a statement, not behaviour: no route started accepting what it refused.

A network dependency moved to the fixed version, and the command that creates the first reviewer of the queue now ships in the image.

See LGPD
C28gateway0.14.02026-09-17

The human review queue, with its own credential and a versioned protocol

Whoever reviews one act does not get a view of every client for free.

An act that needs a human decision goes to a queue with its own surface: sign in, see the queue, open the case, open the evidence and record the verdict, and nothing else. There is no client, key, billing or configuration there, and not because the screen hides it: the route does not exist.

Whoever reviews has their own credential, which does not open the operations console, and the console session does not open the queue. Deciding requires presence proven on the spot, by the reviewer, in the same journey anyone else walks.

The verdict follows a versioned protocol served by the server that applies it, with a closed justification vocabulary that cannot contradict the verdict: "approved because the source did not answer" stops being writable. The third verdict returns the act for a new attempt instead of concluding it.

See Policy
C29gateway0.13.02026-09-17

Opening evidence is a person action, and the client reads who opened it

Plus the internal console telemetry.

Opening the encrypted content of an act now requires a person, a declared reason, and leaves a chained record. The client reads on their own dashboard who opened it, when and why, including when the one who opened it was Hummand, and the list loads before any opening: it is the reason the block exists.

Absence is declared in three distinct states, open, erased and never existed, because merging the last two would erase the difference between an erasure that happened and a field never filled in.

See LGPD
C30gateway0.11.02026-09-16

Per-step timestamps, the access trail and the browser headers

The receipt now says when each step happened, measured.

The format did not change: it already provided for a timestamp per step, and what changed is that the value is now measured instead of omitted. Three absences were declared instead of filled in: an act older than the change, a step resolved in the same instant the act is born, and sandbox, which executes no step.

Every view of client data through the internal console now leaves an attributable record, not just changes: it is the control mechanism of a console that, by decision, has no levels. The client queries the access trail to what is theirs.

Browser security headers on all five hosts, with strict transport and subdomains included, and no-store API responses by default.

See Security
1.0

Verify a receipt

Paste the JSON and the public key. No account, nothing sent: it runs in your browser.

Open the verifier
2.0

Talk to us

A technical conversation, straight with the people who build it, no sales script.

Contact