Export evidence for a review

Use this workflow when a reviewer, incident manager, or auditor needs a date-bounded package of Keeptrusts decision-event evidence. The console workflow exports organization-scoped Events; it does not export the immutable Trail records shown in the Trail event list.

For a filtered export of Trail change records, use kt trail export instead.

Prerequisites

Before you begin:

• Sign in to the intended Keeptrusts organization and region.
• Confirm that you can view export jobs with exports:read.
• Confirm that you can request exports with exports:write.
• Write down the review owner, purpose, inclusive start and end dates, and any request, escalation, incident, gateway, or agent IDs that anchor the review.
• Confirm that the relevant application traffic produced Events in Keeptrusts. History capture is not required for an Events export.
• Decide where the downloaded artifact may be stored and who may receive it.

Use the narrowest date window that answers the review question. Evidence files can contain sensitive operational metadata even when prompt content was redacted or not captured.

Workflow

1. Open the evidence export view

In the console, open Trail, then choose Evidence exports. The direct console path is /trail?view=exports; the command palette also exposes the same destination.

The export form has its own date and format controls. It does not inherit filters from the Trail event list, History, Inbox, or another page.

2. Choose the evidence window

Select a start date and end date. Both dates are included in the export.

Record the same dates in the review ticket or handoff note. If the reviewer gave you a timestamp-level window, select the calendar dates that contain it, then explain the narrower timestamps in the handoff.

3. Choose a format

Choose the smallest artifact that the receiving workflow can use:

Format	Artifact	Use it for
CSV	Comma-separated decision-event rows	Spreadsheet review and lightweight data exchange
JSON	Structured decision-event data	Programmatic review and downstream tooling
EU AI Act (AESIA)	JSON compliance evidence report	Review aligned to the AESIA report structure
AEPD	JSON compliance evidence report	Data-protection assessment aligned to the AEPD report structure
ENS	JSON compliance evidence report	Security evidence aligned to Spain's National Security Framework
All compliance	Gzip-compressed tar archive with a manifest and the organization's selected framework reports	A combined compliance handoff

Compliance reports summarize exported Events against a report structure. They support a review; they do not certify compliance or replace legal, security, or auditor judgment.

4. Request and track the job

Select Request export job. The API accepts the request asynchronously:

State	Meaning	Action
queued	The request is waiting for an export worker.	Wait; the console refreshes active jobs.
processing	A worker is building and storing the artifact.	Wait; do not request a duplicate.
completed	The artifact exists and is ready when Download is enabled.	Download and validate it.
failed	Processing stopped and the job record can include a failure message.	Preserve the job ID and message, correct the cause, then request a new job.
expired	The artifact is no longer available.	Request a replacement with the recorded parameters.

Download is available only when the job is completed and the artifact is ready. A job that is still queued or processing is not evidence of completion.

5. Validate the artifact

Before sharing the file, compare it with the job record:

• Job ID and final state.
• Inclusive start and end dates.
• Format and generated filename.
• Exported row count and file size, when shown.
• Expected request IDs, time coverage, environment, gateway, or agent context.
• integrity.artifact_sha256, size, event count, recorded time, and append-only indicator when returned.
• Manifest and artifact inventory from GET /v1/exports/jobs/{job_id}/manifest. Combined compliance bundles also include manifest.json inside the archive.

The generated filename includes the selected dates, but the filename alone does not prove that the artifact contains the evidence you expected. Open the file with approved tooling and inspect a representative sample.

Calculate SHA-256 with your organization's approved evidence tooling and compare it byte-for-byte with integrity.artifact_sha256. Preserve integrity.manifest_sha256 and the manifest response as separate proof of the recorded inventory; a manifest hash is not a substitute for hashing the downloaded artifact. Do not put credentials, one-time secrets, payment identifiers, or unrelated personal data in the review note.

6. Build the evidence packet

Pair the artifact with a concise note that includes:

• Review purpose and owner.
• Keeptrusts organization and region.
• Inclusive export dates and any narrower timestamp window.
• Export job ID, format, filename, calculated artifact SHA-256, and the matching recorded integrity value.
• Request, event, escalation, incident, gateway, agent, or configuration IDs that help the reviewer correlate the evidence.
• The conclusion the evidence supports.
• Known gaps, redaction, disabled capture, unavailable fields, or other limitations.
• Storage location, access restriction, retention requirement, and next owner.

History content should be included only when capture was enabled and the review genuinely needs it. Inbox decisions and Trail change records are separate evidence sources; reference them explicitly rather than implying that the Events export contains them.

Troubleshooting

The export is empty

Do not widen the window immediately. First confirm:

1. You are in the intended organization and region.
2. The selected dates include the reported activity.
3. The application used the expected Keeptrusts gateway and produced Events.
4. The relevant traffic was delivered to the control plane.
5. The review is asking for decision Events rather than Trail change records, History content, or Inbox decisions.

Widen the dates only when the review scope permits it. Record the original and revised parameters.

The job failed

Preserve the job ID and displayed failure message. Correct the request, authorization, or service issue indicated by the failure, then create a new job. A failed job cannot be downloaded and should not be relabeled as complete.

Download is unavailable

Refresh the job list and check the state. Download requires both completed status and a ready artifact. If the job is expired, request a replacement. If it is completed but still unavailable, preserve the job ID and escalate the export-service issue rather than repeatedly creating duplicate jobs.

The artifact is missing expected evidence

Confirm the IDs and date window against Events. Then check whether the missing record belongs in Trail, History, or Inbox instead. Absence from one export is not proof that the activity did not occur.

Completion checklist

• The organization, region, review owner, and purpose are recorded.
• The export uses the narrowest sufficient inclusive date window.
• The chosen format matches the receiving workflow.
• The job reached completed, and the artifact was downloaded.
• The artifact's content, dates, row count, and manifest were checked as applicable.
• The handoff includes correlation IDs, a digest, known limitations, and the next owner.
• Storage, access, retention, and deletion follow the approved evidence process.

Next steps

• Trail and audit evidence
• kt export-jobs
• Reviewing alerts and evidence
• Investigate a blocked request