HALMAI™ Trust

HALMAI™ generates cryptographic signatures over Proof Packets containing decision metadata, execution outcomes, and configuration snapshots.

Each Proof Packet includes:

• Decision hash (SHA-256 of the policy decision)
• Execution hash (SHA-256 of the execution outcome)
• Config hash (deterministic hash of the active configuration)
• Merkle root (anchor proof for external verifiability)
• Generation timestamp (ISO 8601)
• Tenant and proposal identifiers

The Proof Packet is signed using Ed25519 (in production) or HMAC-SHA256 (in development environments). Signatures are non-repudiable and can be verified by any party with access to the public key.

Verification is a deterministic, reproducible process. Any party can independently verify a Proof Packet using the following steps:

• Fetch public keys from /.well-known/halm/keys
• Canonicalize the signable payload using RFC 8785 (JCS)
• Compute SHA-256 hash of the canonical payload
• Compare computed hash with signature.canonicalHash
• Verify Ed25519 signature against the public key matching signature.keyId

Verification passes if and only if (1) the canonical hash matches, and (2) the signature is valid under the identified public key. Both active and retired keys can verify historical packets.

HALMAI™ implements RFC 8785 JSON Canonicalization Scheme (JCS) to ensure deterministic JSON serialization. This guarantees:

• Lexicographic ordering of object keys (Unicode code points)
• No whitespace between tokens
• Normalized number representation (no leading zeros, no trailing decimal zeros)
• Escaped Unicode sequences for control characters

Canonicalization eliminates ambiguity in JSON serialization. The same logical payload always produces the same byte sequence, which produces the same hash, which produces the same signature. This is critical for cross-platform verification.

HALMAI™ uses Ed25519 (Edwards-curve Digital Signature Algorithm) for production signing. Ed25519 provides:

• 128-bit security level
• Deterministic signatures (same input always produces same signature)
• Fast signing and verification (microseconds)
• Small key and signature sizes (32 bytes and 64 bytes respectively)
• Resistance to side-channel attacks

Private keys are stored in PEM format and never exposed via any API. Public keys are published in both JWK and PEM formats at the JWKS endpoint for maximum interoperability.

HALMAI™ maintains a strict key lifecycle to support key rotation while preserving historical verifiability:

• Active Key: The current signing key. All new Proof Packets are signed with this key.
• Retired Keys: Previously active keys. Remain in the JWKS for verification of historical packets.
• Never Deleted: Retired keys are never removed from the JWKS. Deletion would break verification of all packets signed by that key.
• Key Age Signals: The health endpoint reports key age and rotation recommendations.

On key compromise, the compromised key is immediately moved to retired status and a new active key is generated. Historical packets signed by the compromised key remain verifiable but new packets use the new key.

HALMAI™ generates Auditor Packs for third-party verification and compliance. Each Auditor Pack contains:

• Proof Packet (the signed artifact)
• Public key (the key used for signing)
• JWKS snapshot (state of all keys at generation time)
• Verification script (standalone Node.js script)
• SHA-256 manifest of all included files

Auditor Packs are self-contained. An auditor can verify packet authenticity without network access to HALMAI™ infrastructure. This supports air-gapped compliance environments. A structured Underwriter Evidence Export — packaging these proof bundles for institutional underwriting workflows — is on the product roadmap.