ed25519 signatures over rfc 8785 canonicalized payloads, hash-linked into a per-tenant chain, anchored by rfc 3161 timestamps from a digicert tsa. customer-controlled aws kms keys. aes-256-gcm envelope encryption at rest.
every one of these happened because no signed record existed at the moment the decision was made.
syen comply is running before the examiner arrives. the record already exists when they ask.
runs against a sandbox tenant. payloads are deterministic so you can diff them against the docs. nothing is stored.
syen comply records governance continuously from the moment it is integrated. when an auditor or regulator arrives, the record already exists. no manual log reconstruction. no scrambling.
when the examiner asks the specific question, you export the signed proof package and hand it over. that is the only step required.
no dashboards, no rules engines, no policy editors. an append-only ledger and the proofs to verify it offline.
each event canonicalizes to a deterministic byte sequence. one byte changes, the sha-256 changes. the record's identity is its content.
each event carries the digest of the one before it. rewrite a record in the middle, every record after it is invalid. the chain is its own audit log.
the proof package is a signed json bundle: the event, the chain context, the anchor, the kms attestation. an auditor verifies it with public tooling.
syen-verify proof.jsonthis isn't a demonstration video. the bytes below are real. sha-256 runs in web crypto. ed25519 runs in @noble/ed25519. the demo keypair is fixed and committed (it secures nothing). open devtools — every call is on window.__syen. [server-only steps — kms, rfc 3161 tsa, public-chain anchoring — are labeled inline.]