Security · Audit trail
How the audit trail works. Asserted in marketing, demonstrated here.
Every operational event in HCBS.AI gets a cryptographic seal at the moment it happens. The seals chain together. The chain is verifiable by any third party with the public key. This page describes the mechanism in plain operator language. The full specification is available under Business Associate Agreement.
What it guarantees
Three properties an auditor can rely on.
-
1
Sealed at creation.
Every SOP generated, every audit-defense citation issued, every regulatory update absorbed, every operator approval recorded gets a cryptographic seal the moment it is created. The seal binds the content to the timestamp and the actor. Nothing is sealed after-the-fact.
-
2
Tamper-evident.
The seal carries a hash of the prior seal. Modifying any earlier record breaks the chain, and the break is detectable by any verifier. The chain reveals tampering; it does not silently accept it.
-
3
Forward-verifiable.
The seals use post-quantum signatures. The dossier you build today remains verifiable decades from now, even as cryptographic capabilities evolve. The 2030 auditor and the 2040 auditor both get the same answer: valid, or tampered.
The cryptographic stack
Standards an auditor recognizes. Standards a cryptographer trusts.
Every primitive is a published IETF standard. Nothing proprietary. Nothing rolled in-house. The same algorithms protect classified government data and the global financial system.
- SHA3-256
- Content hashing. Identifies every record by its content. Replaces the older SHA-1 and MD5 families that are no longer considered safe for new systems.
- Ed25519
- Classical signatures. Fast and well-understood; the same algorithm that signs commits on GitHub and packages in modern Linux distributions.
- ML-DSA-65
- Post-quantum signatures (NIST FIPS 204). Adds quantum-resistant verification alongside Ed25519, so the dossier remains verifiable even as quantum computing matures.
- AES-256-GCM
- Authenticated encryption for record contents at rest and in transit. The same primitive protects bank transactions and government-classified communications.
What this list does not include is as deliberate as what it does. RSA, ECDSA P-256, MD5, SHA-1, DES, 3DES, and RC4 appear nowhere in HCBS.AI. The cryptographic substrate is post-quantum by default, not by retrofit.
How verification works
Anyone with the public key can verify any record.
- 01
Export the record.
From your dashboard, export any sealed artifact as a portable verification packet. The packet includes the record contents, the cryptographic seal, the timestamp, and references to the prior and next chain links.
- 02
Fetch the public key.
The HCBS.AI signing key is published at a stable URL with a cryptographic fingerprint that you can pin. The auditor never has to trust a third party to verify; the public key is the anchor.
- 03
Verify the seal.
Standard cryptographic tooling (OpenSSL, libsodium, or any modern signature library) verifies the seal against the public key. The output is binary: valid or tampered. There is no third interpretation.
- 04
Walk the chain (optional).
For deeper assurance, the verifier walks backward from the record to confirm that every prior link is intact. Breaking the chain anywhere between this record and the start of the dossier shows up as a verification failure.
For your information-security team
The complete verification specification covers wire format, chain commitment scheme, key rotation procedure, revocation protocol, and third-party auditor onboarding. We send it under Business Associate Agreement to your security team or your auditing firm.
Request the specificationThe contract
You take care of the people. We take care of the rest.
Tell us about your agency. Nine short questions, four minutes. You walk away with your agency snapshot, your income projection, your state-specific regulatory primer, and tomorrow's brief at 6 AM.
Direct: hello@hcbs.ai wecare@hcbs.ai