Changelog

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.

The periodic proof now opens by itself, and the mandate between people starts to run.

A reverification cycle opens each round as an ordinary campaign, in each person's birthday month, every month or on a day of the year, with reminder and report. Each person comes in with the reference, the client's own fields for grouping and the associated value; at the deadline, the round closes with how many proved it and the value covered and at risk, summed from the value the client reports, not an estimate.

The person mandate runs at level 2: the grantor's presence, consented scope and the document that backs the mandate, of which only the hash reaches Hummand. The presence of whoever receives the mandate comes in as a second presence, when the client asks for it, and the mandate only holds with both. It rises to level 3 when civil identity is accredited.

In the dashboard, each person can sign in with a passkey, with no password or code, and the support centre takes tickets with text and an image, answered by the Hummand team; the answer arrives as a notification.

The dashboard follows the client's structure, and the team's access gets continuous control.

Units in a tree: whoever is in a unit sees only the acts of that unit and the ones below it, with the campaigns and receipts of those acts. My queue answers what needs action today: acts with no answer, waiting for the enrolment photo, under review and with the link about to expire.

Retention per type: the encrypted part of the act can stay longer than the default, up to 20 years, only with a declared legal basis, and an act or a campaign under dispute stays preserved until the client releases it.

The Auditor profile reads what the supervisor reads and writes nothing, and the scheduled access review asks the administrator to keep or remove each person. A webhook event that runs out of its six attempts is kept and can be redelivered with the same event_id. Passkey becomes available in the source catalogue.

It carries 0.25.0, which was never published on its own.

A single search finds acts by id or by the client's reference, mandates by grantee, receipts by id or by hash and campaigns by name. Nothing is decrypted to search.

The test act gets a demonstration link that shows the journey in the policy's order, with no camera, no passkey and nothing recorded. The dashboard charts, the alerts and the latency per step now leave test acts out, as usage and billing already did. No migration and no new variable.

The client builds the orchestration of each act type, and each act gets a document that gathers what proves it.

Per act type, the client requires the enrolment photo, writes context rules that only harden and sets up to 3 attempts in the same act, with the detour when they run out, to negative or human review.

Passkey starts to run: registered only after an approved presence, it proves possession of the device with user verification on it, and nothing biometric reaches Hummand. With it, the policy can reuse a recent proof from the same person, for up to 15 minutes, in the step-ups the catalogue allows; without the passkey at hand, the person goes back to live presence.

The dossier gathers the act, the timeline with the source of each event, the consents, the signed receipt and the receipt of each access to the evidence, and states what is not recorded, so no one draws conclusions from silence.

The dashboard now carries a campaign from start to finish, and each client's access gets optional controls.

The campaign gets a name, an owner and a size with no practical ceiling, in parts of up to 500 that carry on as one, a report to account for it, with the continuous stretch of the receipt chain, and a reminder of who is missing, with a reissued link. The enrolment photo can be attached after creation and stays encrypted in the act itself only while it is open, up to 30 days.

The administrator can limit where the dashboard and the API accept access from, through an IP list, and turn on SSO with Google, which only lets in people already on the team. The policy is now hardened per client: turning types on or off, raising the minimum level and shortening the deadline, each edit in a new version the receipt carries.

0.23.1 fixes saving on those three screens from the browser.

A new read route, and the dashboard gains the screen that stays on the control room's TV.

What is happening and what needs attention, in a moving window of the last 24 hours and the last hour: acts created, completed and by result, what is open and what is about to expire, the hourly series against the same hour of the previous week, the latency of each source, the alerts in the window, open campaigns and mandates.

Aggregates only, nothing that identifies anyone: the screen sits in a shared room. The account logged in on the TV can be the lowest level that still sees the screen, the analyst. No migration and no new variable.

Ten changes in one release: the dashboard creates, follows and exports, through the same door as the API.

The dashboard creates acts through the same door as the API, with the type catalogue and the resolved policy. Batch campaigns get a list with progress; mandates get a list with who received the authority, status and validity.

The act list filters by result, reference and period, counts the total and exports as CSV, with no data about the data subject. The audit trail becomes usable, with period, actor, outcome and pagination, and every evidence opening can be checked line by line. Analytics accepts a free period, comparison with the previous period and conversion per step.

Open sessions of the account, with a button to end the others, and password change without signing out. The dashboard write routes now have a floor per level, and an administrator cannot change or remove another.

Only the origin edge changes: no migration and no new variable.

Six calendar months reach 184 days, and keeping 180 would erase records before the legal minimum. The period becomes 190 days, for the API and the pages.

The logical source port, which Decree 12.975/2026 requires when needed for unequivocal identification, enters the record: on the pages since 2026-09-26, 17:15 UTC, and on the API with this release. The gateway still does not persist IP or port.

The human decision lives in one place only: the reviewer's queue.

A read-only list answers, for any act, whether there was a review, by whom, when, with which verdict and under which protocol item. The old console decision routes leave the contract: decisions are made in the review queue, with its own credential and presence proven on the spot.

No migration and no new variable.

One change, and outside the application: the record is born at the origin, separate from everything else.

Date, time and IP address of each access to the API, for six months, in a restricted record outside the database, the backups and the telemetry. The gateway still does not persist IP; receipt and telemetry remain without IP.

No migration and no new variable. With it, the art. 15 record exists for the API as it already did, since the same day, for the pages.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

The oldest debt of the dashboard: no endpoint checked the caller.

Three levels, from narrowest to widest: analyst, supervisor and administrator. Authorization is by floor, every session route declares the minimum level that opens it, and a suite reads the router to prove none was left without a floor. Whoever signs the contract became a separate mark, not an access level.

Whoever was a viewer became an analyst and gained write access, and that is written in the migration itself: migrating access silently would be deciding for whoever operates. The minimum of two administrators is a lock on the way out and a warning on the way in.

Alongside, the operational metrics in the dashboard: acts about to expire, distribution by type and by policy version. The screen declares, next to the column, that latency per source does not exist, because the act recorded only creation and conclusion.

The chain does not expose a cut at the end. The checkpoint does.

An isolated chain exposes a gap in the middle, insertion, reordering and forking, and does not expose the removal of the last receipts, because what is left stays continuous from the genesis. Numbering does not solve it: 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 existed and what the last hash was. Whoever audits keeps it outside Hummand and compares later. With no table of ours listing issued checkpoints: the only copy that counts is the auditor own.

Creating the same act twice stops creating two acts.

Act creation accepts an idempotency key: the same key with the same body returns the same act, and a different body is refused. Retrying after a network drop duplicates nothing.

A cheap lookup for the state of a mandate, and bulk revocation by mandate holder or by client, with one receipt per mandate brought down. Act events now carry the domain vocabulary.

The context hash recipe now uses the format own canonicalisation, and it is published: whoever holds the original context recomputes the hash alone, with nothing from Hummand.

The ceiling started applying to the whole client, not per process.

Shared counting in the database, with ceilings per API key, per client and per address on public routes. Before, each process counted its own, and the real ceiling was the number of processes.

The API now answers behind an edge that terminates the encrypted connection, with a limit at the edge too and the interactive documentation closed behind access control.

Three things nobody using it can see, and that change what we can promise.

Tracing and structured logs in the service and the workers, with alerts configured and notification delivery proven rather than assumed.

Production secrets left the file on disk and are now read from a managed vault, in memory. No secret persists on the server.

Automatic backups with an encrypted external copy, off the server, and the first restore rehearsal done in production. A backup never restored is a promise, not a guarantee.

Four defects found in adversarial review, fixed before going up.

Retention did not reach the context of acts created by the new API; irreversible erasure now requires a scope of its own that no integration receives by default; the public proof no longer exposes the act position in the chain; mandate revocation inherits sandbox mode.

Documented the erasure limit: in that version, standalone document validations were not reached on request, only by the period. Closed later, in 0.13.0.

Three phases of the plan in one release, replaced by 0.5.1 before going live.

Dual operator with composite receipt; agent mandate with scope and revocation; delegated act; exception proof triggered by the client or a source; alerts computed on read, with the expiry event; deciding the review queue requires the reviewer's fresh presence.

Two test tenants and four scenarios as the acceptance suite, every act with its receipt verified outside the gateway. Read-only policy, data subject privacy, receipt by link token and revocation from the dashboard.

Dashboard, journey and console speak of acts, receipts, mandates and policy.

Dashboard: screens for acts, receipts with batch export, mandates with revocation, alerts, read-only policy and privacy on the real routes. Journey: mandate scope step, proof at the end, accessibility for elderly users, initial bundle from 1.39 MB to 209 kB. Console: queue decision only with the reviewer's fresh presence.

Types generated from the OpenAPI contract in all three; ninety hand-written types removed.

Product decision: API and receipt now say the same thing.

Live presence with a failed match is a negative act, no longer positive with a separate match verdict. A match requested and not computed is a technical failure, with the reason in the receipt.

Fix after the 0.3.0 deploy.

The app did not start because the key policy denied the receipt service the right to read the public key. Now the error goes to the log, the JWKS comes out empty without cache and is retried on every request; the key policy was fixed and documented.

Issuance on every terminal transition, endpoints, webhook, public key and expiry by deadline.

Receipt per act and batch in chain order; recibo.emitido event with ids and hashes, never content; public JWKS; expiry sweep every minute moving overdue acts to expired, with a receipt.

First release, with binaries for Linux, macOS and Windows and checksums.

Verify a receipt or a batch against a JWKS from a file, report in text or JSON, exit codes 0, 1 and 2; hash, genesis and canonicalization. Offline by construction.

One implementation in Rust for the server, the command line and the browser.

RFC 8785 canonicalization restricted to safe integers, hashing, ES256 signature, JWKS, per-client chain with genesis, coherence and the embedded format schema. Python binding with two-step issuance to sign in the key module; WebAssembly target for verification only.

The verifier in the browser and the first note.

Verification page entirely in the browser, with the JWKS pasted or fetched from the gateway; the note "The humanproof/1 format". Published by Cloudflare Pages from the main branch.

Checks become acts; the policy resolves the steps; the contract comes first.

Catalogue of the twelve types with defaults, global policy v1 and pure, deterministic resolution; act routes with the journey link; batch with a common deadline; versioned OpenAPI contract and a TypeScript client generated from it, checked in CI. The check routes remain as an alias.

What was in production after June to August 2026.

Verifications with live presence and transient match, consent per step, policy-driven journey by link, dashboard authentication with MFA, operations console, signed webhooks, notifications, envelope per record, decryption trail, row-level isolation and crypto-shred.