Audit Evidence

This page is a one-stop reference for the evidence the platform produces, where it is stored, and how to extract it during an audit or forensic investigation.

What is recorded

Common evidence requests

Who has access to what?

• Pull the user list from the identity provider with role assignments.
• Cross-reference platform-side ownership records (user identifier → workflows, knowledge collections, assessments).

What did a user do during a window?

• Filter the run history by user and time range for workflow activity.
• Filter audit traces by user metadata for model interactions.
• Filter identity-provider events for sign-in / role-change events.

What changed in a workflow over time?

• The workflow version history is the audit trail of edits.
• Each version records a content hash; comparing hashes shows whether a publish actually changed behaviour.
• Combine with audit traces by workflow version to see which version handled which run.

Was a specific record accessed?

• Audit at the platform level via request logs (filtered by request path and user identifier).
• For knowledge sources, the download endpoint is the only path - filter logs accordingly.

Can I prove a deletion was complete?

• Deletion paths cascade across the application database, secure document store, and knowledge index.
• The post-deletion state is verifiable: query each store for the deleted IDs; absence is the proof.
• Audit traces tied to the deleted entity remain unless explicitly pruned - coordinate with your audit-trail retention policy.

Extraction procedures

From the API

• GET /flow and /flow/responses for workflow activity.
• GET /compliance/assessments/:id for a specific assessment.
• GET /knowledge for knowledge collections and sources.
• GET /documents for generated documents.

Run with a service-account token that has appropriate scope.

From the application database

The data layer schema is the authoritative reference. Joins on user identifier and creation timestamp cover most queries.

From the audit trail

The audit-trail layer exposes a query API and dashboards. For an audit:

• Export traces matching the relevant time window and user filter.
• Include the trace identifier in the audit packet so your auditor can validate it independently if granted access.

From the platform monitoring

• Use the monitoring tool's log explorer to filter request logs by path, status, and user-identifier claim.
• Export the relevant slice in CSV or JSON.

From the identity provider

• A realm export captures user accounts and role assignments.
• The event log captures authentication events.
• Both are exportable from the identity provider's admin UI or admin API.

Chain of custody

When extracting evidence for a regulator or auditor:

• Record who extracted the evidence, what tooling was used, when, and what was extracted.
• Hash each artefact and record the hash in the audit packet.
• Restrict access to the audit packet to the audit-handling team.

The platform does not provide a chain-of-custody workflow; that lives in your audit process.