TiZNO Explained

EXPLAINER · ISSUE NO. 06

How TiZNO handles an audit

This piece is not a rebuttal. It is how TiZNO turns AI from a liability narrative into a compliance asset. Every agent step, tool calls, policy retrievals, reasoning checkpoints, and human approvals, is recorded in an immutable execution trace tied to tenant, user, and UTC timestamp at millisecond precision.

Each entry carries the same fields your second line would expect: the actor, whether agent or authenticated user, the tenant, the action type, the inputs passed, the output produced, the policy citations relied on as page references or clause identifiers, and the source record identifiers for any client data fetched. The trace describes how a result was reached, not merely that a result occurred.

You can export a complete audit packet as signed JSON or as a human-readable PDF, aligned to how your team already works. JSON suits ingestion into GRC tooling; the PDF pack suits committees that do not work in structured logs. The goal is to fit your examination rhythm rather than to introduce an audit dialect that only TiZNO understands.

Retention is set conservatively. A five-year floor is fixed at the platform level and cannot be lowered by tenant configuration, in line with GFSC and POCA 2015 record-keeping obligations, and tenants may configure longer. SAR-related traces are retained permanently and are never purged.

Over time this visibility changes the conversation. The question moves from “can we trust an unobservable model” to “does this system carry the same evidentiary discipline as the rest of our control environment.” For most institutions, clearing that bar is the precondition for expanding production use.

Workflow example

A sample of high-risk onboarding decisions is requested. You export a signed trace for each case: the data queried, the policy excerpts retrieved, the reasoning summary, the Action Card approval events, and the final API calls, as one bundle per client file.