Trust
Audit trace
Audit trace is ISAACs proof layer. It records the important steps behind an answer, workflow, or deploy so teams can inspect, replay, support, and improve the result.
Request ID -> source scope -> model route -> tool calls
Verifier checks -> issue codes -> final answer
Trace ID -> Steward outcome -> scorecard history
Why an audit trail is required
Raw AI systems may perform many internal operations without leaving a useful business record. That creates a trust problem: the final answer may sound confident, but the organization cannot prove which facts or rules supported it.
ISAAC makes the trace a product feature. The trail captures the inputs, route, retrieval status, tool activity, verifier result, issue codes, and release decision at a level that can be reviewed without exposing raw secrets.
What the trace should include
A useful trace includes request ID, tenant or client scope, domain lane, source status, model route, workflow name, tool invocations, OTel trace ref, quality checks, final answer status, and any human escalation result.
For regulated or sensitive workflows, the trace should also separate known facts, assumptions, missing data, and unsupported claims. That makes the answer easier to challenge and repair.
How teams use it
Support teams use traces to reproduce issues. Compliance teams use traces to prove how an answer was created. Product teams use traces to find repeated failures and improve adapters. Finance teams use traces to connect usage to cost and business value.