---
title: "22. Review explainability and export evidence"
slug: "ai-agent-review-explainability-and-export-evidence"
updated: 2026-10-29T21:34:39Z
published: 2026-10-29T21:34:39Z
canonical: "docs.screenmeet.com/ai-agent-review-explainability-and-export-evidence"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.screenmeet.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 22. Review explainability and export evidence

Explainability is the record you use after a conversation to understand the sequence of requests, source retrieval, decisions, privilege changes, and tool outcomes. It helps a technician check an answer and helps QA distinguish an expected policy block from a runtime failure.

## Prepare the recording settings

**Explainability JSON Logs** and **Explainability HTML Logs** are separate Agent configuration options, both on by default. **AI Assist Activity in Session Logs** controls ordinary session event logging separately. Internal diagnostic retention and storage availability are deployment controls; turning on a customer artifact option does not grant access to internal diagnostics.

Save the intended configuration before creating the support session. Records that were never captured cannot be recovered by enabling logging afterwards. A session's HTML and structured export also require the host's normal artifact creation/upload to succeed.

## Obtain the right artifact

1. Finish the support workflow through the normal session controls.
2. Open the completed session from the history/review area available to your role.
3. Open **Files** or the available session artifact/download area and look for AI explainability files when the organization retains them.
4. Choose the HTML report for interactive reading, or the structured JSON/log export for automated analysis.
5. If an authorized internal administrator is investigating implementation details, use the internal **Explainability** area provided by that deployment. Keep those downloads separate from customer copies.

Some reports appear only after session close and upload. If a just-completed session has no report yet, allow upload to finish and reload the artifact listing. Persistent absence can reflect disabled retention, failed generation/upload, storage configuration, or insufficient access.

## Read the report in order

[![Customer explainability overview and activity filters](https://cdn.document360.io/9da39725-20e5-434f-83a4-d630456099dc/Images/Documentation/ai-agent-guide-50-explainability-overview.png)](https://cdn.document360.io/9da39725-20e5-434f-83a4-d630456099dc/Images/Documentation/ai-agent-guide-50-explainability-overview.png)

*This example was generated with the product's customer-report renderer from an in-progress session snapshot. The session remained open at the operator's request; the screenshot does not establish completed-session upload or download.*

1. **Session overview:** confirm the session and scope of the capture. Internal reports can include model/token/cost totals; customer reports omit those internal details.
2. **Initialization:** check whether the tool catalog and initial device environment capture completed.
3. **User turn:** read the actual request and relevant mode/context.
4. **Knowledge/Web retrieval:** inspect which source was queried, the outcome, and the returned article/page links. Search failures are distinct from empty results or reuse.
5. **Skill/plan decisions:** check the procedure and steps selected, along with any revision or refusal.
6. **Consent and administrator access:** distinguish an approval decision from a privilege offer, native attempt, denial, timeout, or grant.
7. **Tool execution and result:** confirm the operation actually started, which parameters/source it used, its role, status, duration, exit code, output, and errors where recorded.
8. **Reply:** compare the final claims with the evidence. A proposed or approved step is not proof that it completed.

[![Expanded diagnostic tool result with status, duration, and exit code](https://cdn.document360.io/9da39725-20e5-434f-83a4-d630456099dc/Images/Documentation/ai-agent-guide-51-explainability-tool-result.png)](https://cdn.document360.io/9da39725-20e5-434f-83a4-d630456099dc/Images/Documentation/ai-agent-guide-51-explainability-tool-result.png)

Use filters such as **Knowledge** and **Failed tools**, search, and expandable events to narrow a long session. Reset boundaries help distinguish work before and after **Start over**. Long conversations may summarize earlier context for the model; the event history remains important for tracing the original evidence.

For inline admin QA, look for the offer, the recorded attempt and its outcome, an observed privilege change, and the matching resumed work. “Request sent” is not “Administrator access granted.” A grant that belongs to an earlier/deferred request must not approve unrelated work.

For scripts, compare the reviewed source with the dispatched source and result. For custom-tool tests, also retain the test's exact snapshot/output in the authoring workflow; do not assume that every editor test appears as an ordinary Harness conversation step.

## Customer and internal records differ

| Customer-facing explainability | Internal explainability, when retained and authorized |
| --- | --- |
| Requests, decisions, tool outcomes, and recorded source context needed to explain the session | Additional model, transport, and runtime diagnostic detail |
| Recorded incident/case information and retrieved article text can remain | Full prompts, custom behavior, model schemas, state details, and usage/cost data can be present |
| Removes internal prompt/schema bodies, custom behavior text, token/cost data, and state snapshots | Must be handled as internal diagnostic material |

**Customer-facing does not mean anonymous.** A customer export can still contain user messages, device output, incident information, and source article text. Review it for the intended recipient. Hiding a prompt/cost panel in a viewer does not sanitize the underlying downloaded file; use the actual customer export.

Structured exports can be newline-delimited JSON: one event object per line, even when the file is labeled JSON or uses a `.log` extension. A parser expecting one JSON array can reject a valid event log. Retain event order and pair execution starts with their results when validating it.

Treat totals according to the events they count. In the captured renderer, the overview shows zero proposed/executed plans even though plan updates and diagnostic execution are present. Inspect the expanded plan/tool events for this capture; QA must resolve that summary-counter discrepancy before treating those counters as acceptance evidence. Failed-tool counts use explicit failed execution results, not every nonzero exit code or every message containing “error.” If tool output, an exit code, and a reported success disagree, inspect the specific operation and report the inconsistency. Cost estimates in internal reports can be incomplete, particularly for interrupted calls or provider search fees; they are not an invoice.

The internal QA capture and validation record identifies the captured session, screenshots, report verification, and scenarios still requiring a fresh live run. The examples in this guide do not replace acceptance testing on the target release.