Releases

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.