Changelog

The API client and offline verification follow the receipt of today, and still read the earlier one.

With core 0.9.2, offline verification reads both receipt revisions: signatures by role, key validity when the JWKS declares it and the reference commitment. Revision 1 receipts follow the earlier rules.

Mandate status by the hash of the grant receipt, and the reference executor revokes by the hash mandato.revogado now carries. On PyPI, under Apache-2.0.

The same tool, offline, now with the rules of revision 2.

With core 0.9.2, it reads revision 2 of the act receipt, the access receipt, the checkpoint and the anchoring proof: signatures by role, key validity in the JWKS and the reference commitment. A revision 1 receipt completed after the cutoff is rejected; earlier ones follow the usual rules.

Each receipt line states the revision when the receipt carries it. Binaries for Linux, macOS and Windows, with checksums.

In revision 2, use and revocation point to the mandate by hash; the API and the webhook now speak the same language.

GET /v1/mandatos/por-recibo/{recibo_hash} returns the mandate status by the hash of the grant receipt, with the same body as the lookup by id. The mandato.revogado event now carries mandato_recibo_hash, null until the grant receipt is issued.

The receipt that closes a dual approval now states who the two operators were.

Core 0.9.2. The receipt that closes a dual approval lists both operators, with commitments that show distinct people, and points by hash to the presence of the first. A revision 1 receipt completed after the cutoff is not issued. The operador.dupla type remains target architecture. No migration and no new variable.

Revision 1 is verified as before, with every vector intact.

The core verifies and issues revision 2 of the act receipt, the access receipt, the checkpoint and the anchoring proof: signatures by role, key validity in the JWKS, salted reference commitment, consent by the hash of the text and guarantees with who backs them. Revision 2 vectors in the public index.

0.9.1 fixes the cutoff, 2026-10-30T05:21:39Z: an act receipt without revisao completed after it is rejected. 0.9.2 fixes the dual-approval rule. On PyPI, and the public specification of the formats moves to version 2.0.

Since 2026-10-30T05:21:39Z, every guarantee in the receipt says who backs it.

The receipt is issued with revisao: 2: level required and reached, policy hash, guarantees with who backs them, human review that decides the act and never the presence, signatures by role and consent by the hash of the text shown itself, published at /consentimentos. Receipts completed before follow revision 1 and verify as before.

The reference of the person enters as a commitment under the client reference key with a salt per receipt; the Administrator sees the key in the dashboard, after the passkey or the password, and every display goes to the audit trail.

The checkpoint now points to the previous one, and anchorings chain; the public list of heads stays empty while anchoring is switched off, until the contract with the authority.

Human review does not approve what presence denied.

Review, through the API or the Hummand queue, does not approve an act whose presence the component denied or whose attempts ran out. humano_vivo is always the verdict of the component, and a review made through the API enters the receipt with the key that decided it.

The JWKS also publishes retired keys, so older receipts keep verifying after a rotation.

An agent that speaks MCP requests the mandate and checks the action with a receipt, using a key that reaches nothing else.

An API key can be restricted to act types: it creates only the ones it names, and anything else is refused before any effect, as are the other write operations. The dashboard has a shortcut that issues the mandate MCP server key this way.

The Python SDK, hummand 0.4.0, and the receipt core, humanproof-core 0.8.1, are on PyPI under Apache-2.0. With hummand[mcp], the mandate MCP server gives the agent three tools: request the mandate, check whether the action fits it, with the signed receipt even on refusal, and look it up. None of them revokes.

The server informs the agent; the guarantee comes from the system that executes the action, checking the receipt before acting. Tested end to end in production, with a real journey on a phone.

The date of each receipt can now be attested by a third party that is not Hummand. Release of 2026-10-20, live since 2026-10-24; anchoring stays switched off until the contract with the authority.

Once a day, each client's checkpoint and every receipt issued, by hash, go into a tree whose root receives a time stamp from a Time Stamp Authority. Each leaf has its own proof, checked before it is stored; the authority receives only the root, with no personal data.

The dossier carries the proof for the act's receipt, and whoever receives a shared dossier checks the anchoring with that receipt alone. The verifier in labs checks the proof with the ICP-Brasil roots built in, and the public specification moves to version 1.3.

In accreditation: anchoring stays switched off until the contract with an authority accredited in ICP-Brasil, and no proof has been issued yet.

Whoever needs to believe the proof opens the act's dossier without an account, and each opening becomes a receipt.

In the dossier of a finished act, the client generates a link with a deadline for a declared recipient and purpose; the link appears only once, and Hummand keeps only its hash. The list shows how many times each link was opened, and the link can be revoked.

The recipient first sees only the header, which creates no receipt, because messenger previews also open links. On opening the dossier, without the client's internal reference, the opening is signed as a third-party access receipt and shows on the act's timeline. A revoked or expired link leaves the attempt recorded as denied.

On the same day, the verifier in labs began checking the whole package exported from the dashboard, and the specification of the formats became public, with test vectors.