Capabilities
What is live, what is in accreditation and what is target architecture,
with the label each capability has in the code. Updated with every release.
This page states the condition of every capability with the label it has in the code. It changes when a release changes; it measures neither availability nor latency, and it promises nothing that is not written.
Available is in production today; in accreditation is ready in the code and waits for a third party’s clearance; target architecture is designed and not yet in production.
Versions and dates come from the repositories' release records.
Available
Description
In production, with version and date. Published from each repository's main branch, after review.
1.0Acts APIavailable
gateway.hummand.com.br, version 0.31.0, live since 2026-10-24: the act domain, global policy hardened per client, native sources, mandates, alerts, privacy, idempotent creation, the checkpoint of both chains, the human review queue, contract closure with a window and a signed receipt for every access to the evidence. Since 0.21.0, the dashboard creates acts through the same door as the API; since 0.22.0, the live state of each client; from 0.23.0 to 0.28.0, access control, orchestration per act type, the act dossier, search, units, retention by legal basis and reverification cycles; in 0.29.0, the dossier shared with a third party; in 0.30.0, anchoring in a time stamp, ready and switched off until the authority contract (in accreditation, below); in 0.31.0, the key restricted to one act type. Versioned OpenAPI contract and a TypeScript client generated from it.
See Docs2.0humanproof/1 receipts and public keyavailable
Signing in the key module since 2026-09-06, key hp-2026-09. Public key at gateway.hummand.com.br/.well-known/humanproof/keys.json. The chain of production receipts verified from genesis, outside Hummand.
See Receipt3.0Verifier in the browser and on the command lineavailable
labs.hummand.com.br/verificar live since 2026-09-06, in WebAssembly, nothing sent. humanproof-verify 0.3.0 with binaries for Linux, macOS and Windows and checksums, distributed to clients; it reads the mandate, the access receipt and the checkpoint of both chains, and also emits the report as a self-contained page, to print to PDF.
Since 2026-10-19, the page checks the whole package exported from the dashboard, with what it states beyond the receipts, and the receipt of whoever opened a shared dossier. Since 2026-10-24, it also checks the anchoring proof, with the ICP-Brasil roots built in.
Open the verifier4.0Journey, dashboard, console and review queueavailable
verificar.hummand.com.br: the policy-driven journey, by link. dash.hummand.com.br: the client dashboard, which since 2026-09-28 creates acts and batch campaigns, lists and revokes mandates, searches and exports acts as CSV, filters the audit trail, compares periods in analytics and shows open sessions; since 2026-10-06, Live, a wall screen for the client's control room, with aggregates only; since 2026-10-18 and 2026-10-19, orchestrations, the act dossier, search, my queue, units, reverification cycles, the campaign report and reminder, the test act demonstration, redelivery of an exhausted webhook and the support centre. Operations console and human review queue, each behind edge access and with its own credential: the console sees who reviewed, and does not decide. Published through Cloudflare Pages.
4.1Access levels inside the clientavailable
Three levels, from narrowest to widest: analyst, supervisor and administrator. Authorization is by floor: every session route declares the minimum level, and a test suite reads the router to prove none was left out.
The minimum of two administrators is a lock on the way out and a warning on the way in. Live since 2026-09-14. Since 2026-09-28, an administrator cannot change or remove another: there is no hierarchy between peers.
Since 2026-10-19, the Auditor profile, which reads what the supervisor reads and writes nothing, and the periodic access review.
See Security4.2Human review with a versioned protocolavailable
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. Whoever reviews has their own credential, which does not open the console, and deciding requires presence proven on the spot.
The verdict follows a versioned protocol served by the same server that applies it, with a closed justification vocabulary: the third verdict returns the act for a new attempt instead of concluding it. Live since 2026-09-17.
4.3Opening evidence is a person’s action, and the client reads who opened itavailable
Opening the encrypted content of an act requires a person, a declared reason, and leaves a record. The client reads on their own dashboard who opened it, when and why, including openings made by Hummand, and each entry carries its hash link in the trail. Since 2026-09-24, every opening also produces a signed receipt, on a chain of its own per client, verifiable outside Hummand.
Alongside it, every view of client data through the internal console leaves an attributable record: it is the control mechanism of a console that, by decision, has no levels. Live since 2026-09-17.
4.4Access control to the dashboard and the APIavailable
An IP list for the dashboard and the API, set by the administrator, with every save in a new version. SSO with Google, optional per client; Microsoft on request. Signing in to the dashboard with a passkey, with no password or code. Live since 2026-10-18 and 2026-10-19.
See Security4.5Retention per type, with legal basis and preservationavailable
The client can keep the encrypted part of an act type for longer than the default, up to 20 years, only with a declared legal basis, and preserve an act or a campaign under dispute. Live since 2026-10-19.
See LGPD4.6Reverification cyclesavailable
A cycle opens each round by itself, in each person's birthday month, every month or on a date, with the client's own fields for grouping. 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. Live since 2026-10-19.
See Public sector4.7Support in the dashboardavailable
Searchable help and tickets with text and an image, opened by anyone on the team and answered by the Hummand team; the answer arrives as a notification in the dashboard. Live since 2026-10-19.
4.8Dossier for a third partyavailable
The client generates a link with a deadline to the dossier of an act, with the recipient and the purpose declared, for whoever needs to believe the proof: auditor, audit court, health plan, judge. The recipient opens it without an account, each opening becomes a signed receipt the client sees in the dashboard, and the link can be revoked. Live since 2026-10-19.
4.9Python SDK and mandate MCP serveravailable
hummand 0.4.0 and humanproof-core 0.8.1 on PyPI since 2026-10-24, under Apache-2.0: the API client, offline verification of the receipt and, with hummand[mcp], the mandate MCP server, with three tools and none that revokes. Tested end to end in production with a real journey on a phone.
The server informs the agent; the guarantee comes from the system that executes, checking the receipt before acting. Its key only creates agent mandates and delegated acts, through the scope restricted to one act type in 0.31.0.
See Companies5.0Labsavailable
labs.hummand.com.br live since 2026-09-06, in two languages, with six published notes: the three on the format and on agents, the TheAlert manifesto and, since 2026-09-23, the two research notes with measurements: behavioural signal against competent replay, and what a homomorphic biometric vault costs today. Since 2026-10-19, the public specification of the formats, with test vectors, at labs.hummand.com.br/especificacao; version 1.3, of 2026-10-20, published on 2026-10-24.
Go to Labs6.0Discipline and securityavailable
Infrastructure as code with real state, distributed telemetry with alerts, secrets off the host, distributed request limiting and backups with a restore rehearsed in production. Dependency inventory by CI and a production threat model, written.
Browser security headers on every host, with strict transport, subdomains included and a browser preload request since 2026-09-26. Main-branch protection by an organization rule: nothing reaches production without review, in any repository.
See Security7.0First real actavailable
A flow validated in production: the journey walked on a phone, with a signed receipt verified through all three paths that exist (the command-line verifier, the SDK and the page on labs).
8.0Art. 15 access recordsavailable
A record of each access to the pages and to the API, kept for 190 days, beyond the six months the Brazilian Internet Civil Framework requires of application providers, in separate, restricted storage. Pages since 2026-09-25, 01:40 UTC; API since gateway 0.18.0, the same day. The logical source port enters the pages record since 2026-09-26 and the API record since 0.20.0. What goes in and what stays out is in Security.
See SecurityIn accreditation
Description
Exists in the code, with real and mock adapter, and depends on a third party to enter production.
1.0Serpro Datavalidin accreditation
Civil identity against the government database. Accreditation process in progress at Serpro since 2026-08-20, on their timeline. When it arrives, only the adapter changes; the step, the receipt and level 3 already exist.
See Sources2.0Serpro CPF lookupin accreditation
Registration status and death, under the same contract. Serves identity and the exception-proof trigger.
3.0Time stampin accreditation
Once a day, each client's receipts go into a tree whose root receives a time stamp from an ICP-Brasil Time Stamp Authority, a third party that is not Hummand. The dossier carries the proof for the act's receipt, which the recipient checks with that receipt alone. In the code since 0.30.0, of 2026-10-20, live since 2026-10-24 and switched off until the contract with the authority: no proof has been issued yet.
4.0Consent texts
The texts are versioned per layer: general v1-2026-08, biometric v1-2026-06 and mandate scope v1-2026-09. Processing record and impact report completed by the data protection officer on 2026-09-21; the texts await legal review.
See LGPDTarget architecture
Description
Exists in the catalogue, in the engine or in the plan, but with no screen, no provider or no phase started. None of it is simulated in production: what does not execute responds as unavailable.
1.0The seven act types still missingtarget architecture
Twelve types with defaults and policy in the engine; five available (recurring presence, agent mandate, person mandate, delegated act and operator step-up). Of the remaining seven, the civil identity (in accreditation), federated account and legal signature steps are missing. The person mandate is available at level 2 since 0.28.0 and rises to level 3 when civil identity is accredited.
See Act2.0Plugged sources without a providertarget architecture
gov.br, device attestation, ICP-Brasil, document OCR, CRC and SISOBI: adapter and mock with real contract; none enters before a client pulls it.
See Sources3.0Discipline and security: what is missingtarget architecture
Client mTLS, in layers: the origin only accepts the edge since 2026-09-24, and the binding between certificate and contract is in the code since 0.17.0, switched off until the edge authenticates the origin with a certificate of its own. mTLS between internal services comes later. The rest of this track is already in production and moved elsewhere on this page: access levels inside the client landed on 2026-09-14 and left this list.
See Security4.0Executable herotarget architecture
The site hero where the visitor performs an act on their own phone and sees the receipt. The first real act has happened and left this list.
Verify a receipt
Paste the JSON and the public key. No account, nothing sent: it runs in your browser.
Open the verifier