AI Audit Trail & Decision Evidence | Dweve Trace

Choose the audience that matches your question

The page contains three selectable readings of the same subject.

An AI answer is only one part of the story. In observability terms, logs record events; a trace follows one request or case through its spans. Dweve's trace keeps the relevant record of what happened, which material and rules mattered, who had authority, what can be checked, and what still needs human judgement.

A trace turns an AI-assisted operation into a record that can move between operations, risk, audit and the affected person. It preserves the decision context without pretending that integrity, evidence and accountability are the same claim.

Trace is the stack-wide guide to evidence, provenance and replay contracts. It separates event capture, explanation, source lineage, integrity checks and re-execution, then shows where each Dweve system contributes a scoped record rather than one universal proof artefact.

Logs record events. A trace keeps the source, rule, owner, and replay scope in one bounded record that can be checked later.

A log helps an operator see that something happened. An explanation helps a person understand a result. A trace carries the relevant inputs, state, versions, actions and evidence as a checkable record. One system may produce all three, but they answer different questions.

Logs are usually arranged around system events: a request arrived, a tool returned, a job failed. They are valuable for operations, but a pile of timestamps does not by itself identify the decision contract or show which evidence supported the result.

An explanation is written for understanding. It may summarise why a route was taken or name the sources used. A trace is the underlying record that lets another person check those statements, including the parts the explanation leaves out for clarity.

A trace is useful when its boundary is visible

Relevant input, state, policy and version.

Use the record that answers the question in front of you

A plain account says which factors mattered.

The relevant state, authority and evidence travel with the result.

The distinction matters most when you open the record itself

A useful trace is produced as the work runs. It records the material state that was available then, the version that acted, the rule or authority in force and the result that followed. It is not a story reconstructed later from a dashboard and somebody’s memory.

Reconstruction tends to keep the visible result and lose the awkward context: a refusal, a changed source, an unanswered approval, an external service response or the exact version that was active. Those details are often the reason a decision is disputed.

Runtime capture does not mean recording everything. The record should keep what its declared claim needs and name what remains outside it. That is more useful than an exhaustive surveillance stream whose purpose, owner and retention period are unclear.

Capture the decision context, not a private thought stream

Input, policy and authority are identified.

Actions, checks and refusals are appended.

Output and verification scope are sealed together.

The final answer inherits the context recorded beside it

The source set, policy and active version are identified.

Routes, checks, refusals and approvals are added as they happen.

Evidence references and responsibility stay attached.

Once the record exists, the next question is what it proves

A signature can show who issued a record and whether it changed. It cannot make the recorded decision correct. Evidence can support a claim, but it can still be incomplete or contested. A good trace keeps those differences visible instead of collapsing them into a single trust badge.

Identity and integrity answer whether this is the record that a named producer issued. They do not establish that a source was accurate, that the policy was fair, that the authority was legitimate or that the final judgement was sound.

Evidence should stay attached with its origin, version and disagreement. That lets a reviewer challenge the claim without first attacking the container. The record can be intact while the decision is still revised, appealed or rejected.

A sound record makes disagreement easier to locate

One source is incomplete or out of date.

Integrity remains valid while the decision is reconsidered.

That boundary belongs in the record you keep and control

The person or organisation responsible for the work should know where the record lives, who may export it, how long it remains available and what happens when material must be restricted or removed. Portability is a governance choice, not a download button added at the end.

An export should preserve stable identities, versions, evidence references and the verification instructions needed outside the original interface. If a recipient only gets a screenshot or a prose summary, the most important parts of the record have not travelled.

Retention is not the same for every layer. The operational event, the evidence it references and the personal material around it may have different lawful purposes and clocks. Deletion, redaction and restriction should leave an intelligible account of what changed.

A record without custody rules becomes another data liability

Export identities, versions and references.

Apply purpose, access and retention rules.

Record restriction, redaction or expiry.

Each transfer carries the same identifiers and declared limits

A named workspace holds the primary record.

Stable identifiers, versions and references stay attached.

Purpose and review date govern what remains available.

Any restriction or redaction is visible in the history.

Control matters most when two people read the record differently

If you disagree with a decision, the trace should help locate the difference. You may dispute the input, the source, the rule, the authority, the action or the interpretation. The machine can present the record. A responsible person must still hear the challenge and decide what follows.

A useful challenge names the point of disagreement against a stable record: this source was out of date, this approval was missing, this policy version was not applicable or this output does not follow from the evidence shown. A challenge that names none of those is an opinion about the answer.

The reviewer should be able to preserve the original record, add the challenge and issue a correction or superseding decision. Overwriting the earlier result would make the appeal harder to understand and erase the reason the system changed.

The human role is to decide what the record means for the case

The correction adds a new decision instead of erasing the first

Its input, source, policy and result remain pinned.

They dispute the policy version and source date.

A new decision is added without erasing the first.

No single component carries this whole record on its own

Dweve products contribute different parts of the evidence story. Loom can expose a weave trace. Nexus records governed work and authority. Spindle keeps source provenance and disagreement. Mesh can leave an execution receipt. AION checks named certificate families. None of these replaces the others.

A source record cannot prove that hardware behaved honestly. An execution receipt cannot prove that a policy was fair. A reasoning certificate cannot reproduce an external producer it did not capture. Keeping the layers separate makes each promise easier to check. Collapsing them into one claim is what makes a record unreadable later.

The product you use determines which records exist and which replay contract applies. Ask for the record tied to the actual workflow, its export format, its retention rule and the verifier or review process that understands that record. Two products can hold different records for one workflow, so ask which one.

Different records answer different questions

Objectives, actions, approvals and owners.

Origin, versions, evidence and conflict.

Workload, nodes, resources and output identity.

Start with the decision, then follow the records it actually produced

Loom exposes the weave; Nexus records authority and approvals.

Spindle keeps origin, version, evidence and disagreement visible.

Core, Kera or Mesh provide their scoped execution records.

AION or a producer verifier checks only the declared contract.

That map is the starting point for a serious adoption conversation

A trace gives operations, risk and audit a common record of an AI-assisted decision. It keeps the action, relevant state, evidence, authority and outcome together. This reduces the need to rebuild a case from application logs, model-provider exports, tickets and recollection after something goes wrong.

Without a shared record, each team assembles a different version of the same event. Operations sees calls and failures, risk sees policy, the business owner sees the outcome and the affected person sees a message. Reconciliation becomes the investigation.

With a trace contract, those views refer to stable identities and versions. Teams may still disagree about the decision, but they disagree over the same recorded material. That shortens handovers and makes missing evidence visible instead of silently filling the gap with assumptions.