A chat transcript is not enough to explain a business action. Learn which identity, authorization, approval, execution, outcome, and audit evidence makes AI-assisted work reviewable without logging unnecessary sensitive data.
On this page
Key takeaways
Evidence for an AI-assisted business action should connect intent, authority, decision, execution, and outcome. A model response or chat transcript cannot establish all five.
Different records serve different purposes. An operational draft, execution attempt, audit event, and Evidence Pack should not be treated as interchangeable.
Useful evidence identifies the actor, workspace, action contract, source state, policy, approval, idempotency identity, and observed result where those fields apply.
More logging is not automatically better. Sensitive payloads should be minimized and redacted; complete prompts and hidden model reasoning are not necessary to prove that a structured action was authorized.
Review an app connection against its purpose, permissions, data direction, mapping, owner, and observed result. Distinguish saved configuration from verified data movement.
·6 min read
Security & Trust
Uncertainty is itself an outcome worth recording. If an external effect may have happened but cannot yet be verified, the record should move to reconciliation instead of claiming success or retrying blindly.
When a person changes a transaction in a business system, the important questions are familiar: Who made the change? What did they change? Were they allowed to do it? What was the previous state? Did the operation succeed?
AI does not make those questions disappear. It introduces a few more. Which information was the proposal based on? Did the AI only recommend an action, or did it prepare a structured draft? Which person or service authorized execution? Did a provider receive the request once or twice? Does the result reflect what the proposal promised?
Answering those questions requires evidence across a workflow, not a screenshot of a confident response. The goal is a reviewable chain that is precise enough for operations and restrained enough for privacy.
Evidence is a chain, not a transcript
A conversation can explain why somebody asked for help. It does not, by itself, prove what an operational system did.
Suppose an AI assistant says, “I created the transaction.” That sentence leaves several possibilities unresolved:
the assistant may have produced only a draft;
the user may not have permission to create a transaction in that workspace;
the underlying account may have changed after the proposal was generated;
the write may have failed validation;
an external provider may have accepted the request before a timeout;
the record may have been created successfully but not linked back to the conversation.
The sentence is therefore a claim, not completion evidence.
A stronger design records transitions. It distinguishes the original request from the structured action, the proposal from the decision, the decision from the execution attempt, and the attempt from the observed result. That makes it possible to investigate a failure without treating generated prose as system truth.
This distinction also keeps AI governance proportional. A read-only summary does not need an execution receipt because it has no business-side effect. A draft may need a source revision and preview but no provider result. A confirmed external action may need an idempotency key, attempt history, provider reference, and reconciliation state. Evidence should follow the effect and risk of the action.
Figena’s business overview describes this progression as source, context, draft, controls, and record. That is a useful product-level view. The evidence model below examines what a reviewer should be able to establish at each transition.
Four records that should not be confused
Teams often use “audit log” to describe every historical record. That shorthand can obscure important differences.
Scrollable article table
Record
Primary purpose
Typical contents
What it does not prove alone
Operational draft
Preserve the proposed action before it changes business state
That a person approved it or that the effect occurred
Execution record and attempts
Track how an approved or policy-permitted action was processed
Idempotency identity, attempt status, effect strategy, result or error, provider reference where available
That the original context was authorized unless linked to authorization evidence
Audit event
Provide a normalized, searchable account of a material event
Actor, action, target, outcome, reason, request or correlation identifiers, redacted details, time
The full payload, full prompt, or every domain-specific fact
Evidence Pack
Curate selected operational sources for a defined review purpose
Scope, period, source items, summaries, export snapshot, review state
That every AI action automatically generated it
These records can link to one another, but combining them into one oversized object would not necessarily improve trust. Operational records change state as work progresses. Execution attempts may be append-only facts about retries or external effects. Audit events need stable, normalized fields. An Evidence Pack is a deliberate review artifact with a chosen scope.
The useful design question is not, “Where is the one perfect log?” It is, “Can an authorized reviewer move from the action to the relevant decision, attempt, outcome, and source without ambiguity?”
The evidence an action should leave
Not every action needs every field below. A read-only analysis and an external mutation have different evidence needs. For a business-side effect, however, the chain should usually answer eight groups of questions.
1. What action was actually proposed?
Natural language should be translated into a registered action contract before execution. Evidence can identify the action type, owning domain, mode, risk, required capability, and the version or digest of the action definition used for the decision.
This prevents a later reviewer from having to reverse-engineer an operation from prose. “Handle this client” is ambiguous. “Prepare a follow-up draft for client A” and “update client A’s status” are distinct actions with different effects and controls.
The record should also make unsupported actions visible. If a workflow can only prepare a recommendation or manual handoff, its evidence should not imply that a business mutation occurred.
2. Who and which workspace were involved?
The chain should identify the relevant principal and operating boundary. Depending on the route, that can include a signed-in user, an application, a service identity, a sponsoring workspace member, or an approver.
Useful fields include the organization or workspace, principal type, role or capability checked, application or key identifier, and the target resource. For an external-agent request, several participants may be relevant: the publisher that registered the tool, the workspace sponsor, the service actor used to request the action, and the human who approved it.
Recording these identities does not mean copying credentials into an audit log. Secret material should never become evidence. Stable identifiers and authorization snapshots are more useful and safer.
3. Which source state supported the proposal?
A proposal should be tied to the business state used to create it. That can mean a record identifier and exact revision, a preflight snapshot, or references to authorized knowledge sources.
Revision evidence matters because approval can happen later. If the target changed after the draft was prepared, the earlier decision may no longer apply cleanly. A governed system can reject the stale operation or require a refreshed proposal instead of silently writing over newer work.
When permission-aware retrieval supports an answer, citations can help a reviewer return to the relevant knowledge source. Citations are not universal completion evidence, however. Not every action uses retrieval, and a retrieval service may be unavailable. The absence of a citation should not be hidden by inventing one; the workflow should state which source references it actually has.
4. What change and impact were presented?
The proposed payload, human-readable preview, and expected impact form the center of a meaningful review. A person cannot approve responsibly if the interface shows only a generic “Allow” button.
For sensitive actions, a preflight can calculate the expected effect before execution. Evidence can preserve a fingerprint of the proposed payload and a hash of the preflight result. Those values help establish that the action later executed corresponds to what was reviewed without requiring every sensitive field to be duplicated into the audit event.
The full operational payload may remain in a protected draft or domain record. A normalized audit event can carry a smaller allowlisted summary and the identifiers needed to find the protected source under the reviewer’s own permissions.
5. Which policy and decision applied?
The chain should show whether the action was denied, saved as a draft, approved by a person, or allowed to execute under an active policy. Relevant evidence can include the policy snapshot, confirmation requirement, decision time, approver, reason or justification, and stronger-verification result when that policy change requires it.
This is especially important for configurable automation. OpenPort is draft-first by default, but an administrator can allow supported actions to execute directly under bounded policy. A later reviewer needs to know which policy was active for that request—not merely what the workspace policy says today.
Approval evidence should remain separate from permission evidence. A person may approve a draft and then lose the relevant capability before execution. The approval still happened, but the action should not use it to bypass the current authorization check.
6. How was execution made safe to repeat?
Networked systems retry. People double-click. Workers restart. An evidence chain should therefore include a stable request or idempotency identity for a mutation.
Idempotency lets the system recognize a replay of the same intended action. It does not mean that every failure can be retried safely. The execution record should also show the effect strategy, attempt identity, and whether the executor permits recovery after an interrupted operation.
An append-only attempt history is useful here. It can distinguish “the request was never sent,” “the provider may have received it,” and “a later read confirmed the result.” That sequence is more informative than repeatedly overwriting one status field.
7. What outcome was actually observed?
A completed API call and a completed business effect are related but not identical. Evidence should record the strongest outcome the system can support.
For an internal change, the result may include the affected record and new version. For an external effect, the result may include a provider reference, receipt, or readback. Those artifacts are conditional: some providers support them and others do not.
If a provider might have accepted a request but the platform cannot verify the final state, the accurate outcome is “reconciliation required,” not “failed” and not “completed.” The record can preserve the external attempt key, known provider information, alert, operator note, and eventual resolution.
Honest uncertainty is a control. It prevents a well-intentioned retry from creating a duplicate effect and gives an operator a clear place to continue the investigation.
8. Can the event be found and verified later?
Finally, the action should connect to a normalized audit event with enough stable fields to support review: event identifier, actor, action, target, outcome, severity where relevant, reason, request or correlation identifier, and occurred and recorded timestamps.
A content hash can help detect whether the normalized event content matches the version originally recorded. An idempotency hash can help detect conflicting reuse of an event identity. A canonical link can connect specialized action logs to the normalized audit projection.
These controls support integrity checks; they should not be described as mathematical proof that an entire operational system can never be altered. Retention, access, backup, export, and administrative controls still matter. Accurate language is stronger than an absolute “immutable” label.
A worked example: an external agent requests a high-risk action
Consider an approved external tool that requests a high-risk action through OpenPort. This example illustrates the chain and does not imply that every domain exposes high-risk direct execution.
Request and preflight
The tool authenticates with a scoped identity and submits a specific registered action. The server checks its application, key, workspace, required scopes, current domain capabilities, entitlement, tenant boundary, and target access. In this example, the current policy requires a preflight, which calculates the server-side impact and returns a hash tied to that impact.
At this point, evidence can include the action type, tool and workspace identifiers, request identity, target, payload fingerprint, risk, preflight summary, and preflight hash. No business effect has occurred.
Policy decision
Under the default draft-first posture, the request becomes a draft for review. The reviewer sees the impact and proposed payload. An authorized approver can approve or reject it, with a reason or required high-risk note captured in the decision record.
If an administrator has explicitly enabled a qualifying high-risk direct-execution policy, the route is different. The authorization must still be active and time-bounded, and the request needs a justification and an idempotency identity. Any configured action allowlist and impact limits must pass; a valid matching preflight is also required when the current policy calls for one. The evidence should preserve the applicable policy snapshot. Direct execution is therefore a governed policy outcome, not an absence of controls.
Execution and outcome
Immediately before execution, the service checks current authorization and target access again. It records an execution identity and attempt, invokes the registered executor, and stores the supported result.
If the effect completes, the record can link the draft or request, execution, result, and canonical audit event. If an external response is ambiguous, it enters reconciliation with the known attempt information. The system does not need to turn the original chat into an audit payload; the structured records establish what was requested and processed.
Operators using programmatic workflows can review the developer resources. Where command-line access is available, the Figena CLI remains subject to server-side permissions and the commands supported by the current release and access level.
Keep evidence useful without collecting everything
“Record everything” sounds safe until the record contains secrets, personal data, raw documents, and prompts copied into systems with broad administrative access. Evidence design should follow purpose limitation.
A normalized audit payload can use an allowlist, depth and size limits, and secret-field filtering. Email addresses can be represented by a fingerprint when exact content is unnecessary. IP information can be reduced to a prefix. User-agent detail can be normalized to a family. Sensitive operational payloads can remain in their protected domain records while the audit event stores a reference and minimal summary.
This approach also clarifies the role of model information. A generated explanation, confidence indicator, or concise rationale may help a reviewer understand a proposal. Hidden chain-of-thought is not a durable business control, and storing it is not required for authorization evidence. Complete prompts may contain unrelated workspace context and should not be copied into audit logs by default.
Data minimization does not mean losing accountability. A reviewer can still establish who acted, what registered action applied, which policy allowed it, which proposal was approved, which attempt ran, and what outcome was recorded. The privacy policy provides the broader public context for how Figena describes data handling; implementation details and retention can vary by feature and environment.
Evidence review checklist
Use this checklist for a mutation, export, permission change, or other consequential AI-assisted action.
Intent and context
[ ] Is the action type explicit rather than inferred later from prose?
[ ] Are the owning domain, mode, risk, and required capability identifiable?
[ ] Are the principal, workspace, and target resource clear?
[ ] Is the relevant source revision or preflight state preserved?
Decision
[ ] Does the review show the proposed change and expected impact?
[ ] Is the applicable policy snapshot linked to the request?
[ ] Is an approval, rejection, denial, or direct-execution basis recorded?
[ ] Can the system distinguish the approver from the requesting service identity?
Execution
[ ] Does the mutation have a stable idempotency identity?
[ ] Are authorization and target access checked again at execution time?
[ ] Are individual attempts distinguishable?
[ ] Is provider receipt or readback recorded only where the executor actually supplies it?
[ ] Can an uncertain external effect enter reconciliation without an unsafe retry?
Audit and privacy
[ ] Are outcome, reason, identifiers, and timestamps sufficient for investigation?
[ ] Does the audit event link back to protected operational records?
[ ] Are secrets and unnecessary personal data excluded or redacted?
[ ] Are integrity hashes described accurately rather than as an absolute guarantee?
[ ] Is an Evidence Pack created only when a defined review workflow calls for one?
Frequently asked questions
Is a chat transcript enough evidence for an AI action?
No. A transcript can preserve the request and explanation, but it does not prove current permission, a validated action payload, approval, execution, or the resulting business state. It should link to structured operational records rather than substitute for them.
Should an audit log store the complete prompt?
Not by default. A complete prompt can contain sensitive or irrelevant context. A minimal audit event should preserve stable identifiers, the action and target, the decision, outcome, reason, and links needed for an authorized reviewer to inspect protected source records.
Is approval evidence the same as success evidence?
No. Approval shows that an authorized decision was recorded under a policy. Execution may still be blocked by changed permissions, stale source state, validation failure, or provider availability. Success needs its own result evidence.
Does every execution need a provider receipt or readback?
No. Internal domains and external providers offer different verification capabilities. Record a receipt or readback when the executor supports it. Otherwise, state the strongest observed result and use reconciliation when the effect remains uncertain.
Is an Evidence Pack the same as an audit trail?
No. An Evidence Pack is a curated artifact for a defined scope, period, or review. An audit trail records operational events. A pack may reference selected source and audit material, but ordinary AI actions do not automatically create one.
Do hashes make records impossible to change?
Hashes can detect content mismatch and strengthen integrity checks. They do not replace access control, retention rules, backups, exports, or operational oversight, and they should not be marketed as an absolute guarantee of immutability.
Preserve what a reviewer needs to know
The evidence left by an AI business action should be more reliable than the language used to request it and more restrained than a complete data dump.
Connect the action definition to the authorized context. Preserve the proposal and impact that informed the decision. Record why a person or active policy allowed the action. Give the execution a stable identity, distinguish its attempts, and report only the outcome the system can actually verify. Link those records through a normalized, minimized audit event. Create a dedicated Evidence Pack only when a review workflow calls for one.
That chain supports practical questions after the moment has passed: what was intended, who had authority, what changed, whether it happened once, and what needs attention now. Those are the questions that turn AI activity into accountable business work.
Prepare for a lost device with approved backup authentication, a known recovery route, clear business coverage, and checks after access is restored. Use a practical recovery plan.
Check the purpose, content, version, recipient, and delivery method before sharing a business record. Use a practical checklist for internal and external handoffs.
