ZyndaX / Trust & Compliance
Governed by construction

Not a compliance feature. The same mechanism, everywhere.

Most software calls itself "compliant" as a marketing adjective. ZyndaX's governance is three specific, checkable mechanisms — a tamper-evident audit ledger, memory access that refuses rather than filters, and erasure that's the same code path as the regulation it satisfies. Here's exactly how each one works.

01 · The Ledger

A hash chain, not a database table anyone can edit.

Most SaaS "audit logs" are a database row like any other — anyone with delete access can edit or remove one without a trace. ZyndaX's Ledger is structurally different: every entry's hash is computed from the entry before it, so editing, deleting, or reordering any entry breaks every hash after it.

The mechanism

entry_hash​(n) = SHA-256( envelope​(n) ‖ payload_hash​(n) ‖ entry_hash​(n-1) )

Each entry's hash folds in the hash of the entry before it. Change entry 41 and every entry from 42 onward no longer matches its recorded hash — the tampering isn't hidden, it's mathematically unavoidable to detect.

Append-only

No update or delete path exists

The schema itself has no operation to modify or remove a past entry — not a permission that's revoked, a capability that was never built.

Verifiable on demand

verify_integrity walks the whole chain

A single operation walks every entry from genesis to the latest and reports the exact point of any break, if one exists.

Automatic

Every mutation, every conversation turn

Nothing needs to opt in to being audited — every module mutation and every Assistant conversation turn lands on the ledger by default.

02 · Engram

Memory access is a wall, not a filter.

A filter softens what it can't show you — a summary, a redacted version, a "you might not have access." A wall refuses outright and says so. ZyndaX's memory workspaces are walls: a request for information outside a user's workspace scope is refused, by name, and the refusal itself lands in the audit trail.

Dramatized

In the law-firm vertical: an associate asks about a matter he isn't staffed on. The assistant doesn't soften the answer or provide a partial summary — it refuses, names the workspace boundary, and the refusal attempt is itself recorded. That's a wall, not a filter.

03 · Erasure

GDPR isn't a retrofit — it's the same code path.

Article 17 ("right to be forgotten") and Article 15/20 (data export) are built into Engram as first-class operations, not a support ticket that eventually reaches an engineer. An erasure shows exactly what's removed versus what stays in the immutable audit trail — and a later search proves the erased record never resurfaces.

Dramatized

In the recruitment vertical: a candidate asks to be forgotten. The assistant shows what's erased versus what's retained for audit, cited from the real retention procedure — and a later search confirms the erased profile never comes back.

Talk to us

See the ledger, the walls, and the erasure — not just read about them.

Ask about a walkthrough of the compliance mechanisms behind ZyndaX.