Principles

Rules that hold on every surface: in the code, in the documentation and on this page.
When text and code diverge, the code wins and the text is corrected.

Category
CompanyPrinciples
HummandPrinciples

Hummand writes, publishes and promises under rules that are not wall values: each one becomes a test, a code review or a text correction. What does not exist yet is written, not hidden.

The rules come from a dated decision record and are never rewritten; they are superseded with an erratum. None of them carries a state label, because they are not capabilities: they hold in full, today.

Honest labels

Description

Every capability carries one of three labels, on every surface: in the catalog, in the dashboard, in the documentation and on this site. Overclaiming is a bug, and is fixed as one.

1.0Three labels, no fourth

Available is what runs in production, with version and date. In accreditation exists in the code and waits on a third party: a source, a contract, a homologation. Target architecture is decided and documented, but does not execute yet.

There is no fourth label. What does not exist yet is written, not hidden.

See Capabilities
2.0What does not execute says so

A step that does not execute yet answers "not implemented", by that name, documented in the API contract. Never a simulation. The journey shows the step as unavailable and the receipt does not invent it.

See Policy
3.0Vocabulary we do not use

No "anti-fraud", no "audit" as identity, no SLA before a contract defines one, no "guaranteed accuracy", no "post-quantum", no "age estimation". The live-presence component is certified by AWS; Hummand is not certified.

See what we don't do

Slogan boundary

Description

Hummand answers who it is, is present, authorized what. What falls outside those three questions does not get in through the text, nor through the code.

1.0Three questions, no fourth

Not anti-fraud, not audit, not login nor a KYC vendor. Anti-fraud, anti-money-laundering and audit consume the receipt and trigger acts by the client's rule; they never decide inside Hummand.

See the boundary
2.0No score, risk or age

Hummand never computes a risk score, a fraud probability or an age estimate. It is a system invariant: it becomes a test and a code review, not just a writing rule.

3.0AI never decides on the path of the proof

No model makes a verdict, level or policy decision. Where there is an AI component, as in live presence, it is a source declared and labeled in the receipt, not a decider.

See Sources

Written decisions

Description

Every architecture choice lives in a dated decision record. No critical decision lives only in someone's head, not even the founder's.

1.0Dated record, never rewritten

A decision is not edited: it is superseded with a header or a dated erratum, and the previous one stays readable. Whoever reads today sees what was decided, when, and what changed afterwards.

2.0Tests as specification

System invariants become tests and code review: nothing enters the core without a test, and the acceptance scenarios are the specification of the domain. Every change goes through review before the main branch, even with a single person.

3.0Contract first

An API change starts with the published contract; clients are generated from it, never written by hand. Dashboard, journey and documentation read the same source, and the receipt carries the policy version that held for the act.

See Docs
4.0Key-person risk, written down

One person builds and answers for the product today. That is recorded as a risk, by name, not hidden. The mitigation is the rest of this page, applied: every decision in a dated record; the state of every repository in an index; every deploy and every rollback with the exact command in an operations runbook; a backup before every change in production; keys in a managed module, not on a machine; and the receipt any auditor verifies without Hummand.

Whoever comes next finds the path written down, not a riddle. A rehearsed backup restore has not been recorded yet; it is in the plan's discipline phase, already open.

See Security

Public and retained

Description

Public is what proves competence without exposing operations. Retained is what an adversary would use tomorrow. The line between the two is written down.

1.0What we publish

The receipt format, the public key, the verifier and the command-line tool. The conceptual architecture: key envelope, isolation per client, cryptographic erasure, zero retention. Research results with method, and the dated changelog of what was delivered.

See Receipt
2.0What we retain

Calibrated parameters, rate limits, the production threat model, the internal pipeline, prices and any client or prospect name. Decision records are private; the research notes derived from them are public.

3.0No claim without a source

No figure, metric or commercial claim enters a surface without being in a research document or in the code. Every Labs note has date, author, finding, method and source; every claim states its origin and its uncertainty.

See Changelog

Slowly, on request

Description

Infrastructure is reached by accumulating acts, not by declaring the layer. What no client has asked for waits, with a name and a label.

1.0Nothing raw persists

No raw biometrics, image or template stays at Hummand after the act; the client's reference is transient and the receipt carries only hashes. It is a system invariant, not a setting: it becomes a test and holds for every client.

See LGPD
2.0A new source only with a client

A real source comes in when a client pulls it; until then there is the adapter with a real contract and the label in accreditation or target architecture. Policy per client and background monitoring follow the same rule: the structure exists, the screen waits for the request.

See Sources
3.0Data residency by agreement

Today everything runs abroad, and it is declared: server and database in the European Union; live presence, match and the key module on AWS, in the United States. By agreement in the contract, and if the client prefers it, what stays at rest can be entirely national: server, database, backups and keys.

The AWS live-presence component is not offered in a Brazilian region; while it is the one in use, the presence frames pass abroad in transit, with no retention. A national live-presence source is already in view, labeled target architecture until it enters the catalog; with it, all the material can be national.

See Security
4.0Few contracts, technical conversation

No sales script: the people who build it answer, with the honest label of what exists. We grow slowly and choose our contracts well; a request for a simplified version, without the guarantees, is not a request for Hummand.

Contact
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