What is built, and what is not

Available today

• Levels 1 and 2, Gated and Signed. Every world-affecting action is held for a human approval, and each approval produces an Ed25519 signed receipt bound to the approver and the exact action. This runs in FLOCORE, the reference implementation.
• Offline signature checks. Anyone can check a receipt's signature in their own browser on the verifier.
• A published trust root. The key is published at did:web:humanseal.world and the standard is an open v0.1 public review draft.

Not built, or weaker than it may sound

• Level 3, Assured, is not built. It is specified and in design. No system holds it, and the present-human step-up is not shipped.
• Conformance is checked by us, not independently. Today we check a system against the published test vectors. Independent certification is planned. HumanGate International, the intended steward, is in formation and not yet incorporated. The registry lists one system, FLOCORE, which is the reference implementation and also wrote the standard.
• The free injection screen is a pattern screen. It recognises known injection and exfiltration phrasing. It misses paraphrases and is not a guarantee. An anonymous call stores nothing; if you pass an agent name, we record that name and the score.
• A receipt's own key proves only consistency. A signature that verifies against the key inside the receipt shows the receipt was not altered after signing. It does not show the key is ours. To confirm that, compare it with the key we publish at did:web:humanseal.world. You are then relying on our key publication, not on our word about any receipt.
• One issuer key signs every Seal. We have not built a separate issuing key for each organisation. If that key were compromised, the remedy is to revoke it and publish the revocation, not to isolate the damage.
• An agent's own key is checked in observe-only mode. An agent can register its own public key, and its thumbprint is recorded and shown. Proof that the agent holds that key is checked but nothing is refused yet: a missing or bad signature is counted and logged. Until that is enforced, a stolen access token still works.
• Owner identity is weak. The owner's email address is the one given at application. It is not domain-verified.
• No outside organisation has completed onboarding yet. Every figure on our public proof page, such as sign-up requests, approvals and Seals issued, comes from FLOCORE's own testing.
• Early Seals carry more than they should. A small number of Seals issued before the opaque approver reference was introduced, all test or internal, carry an email address or a service name. The developers page says so too.

What a receipt does and does not prove

It proves origin, integrity and time: that a particular credentialed approver, through a particular issuer, approved a particular action at a particular time, and that the record has not changed since it was signed.

• It does not prove the person understood the action or looked at it carefully. The receipt can record what the approver was shown and how long they took, so a rubber stamp shows in the data, but that is evidence, not a guarantee.
• It does not prove the action was lawful, or that the approver was allowed to approve it, beyond the sign-in strength the issuer used.
• It does not by itself make a system compliant with any law. A self-issued signature probably does not carry the special legal presumption some laws give to accredited electronic signatures. Take legal advice for your jurisdiction.