When Does AI Evidence Become Provable? Decision Trace Ledgers and the Unanchored Evidence Window

Introduction

As AI agents begin executing real-world business operations, merely recording “what the AI did” is no longer sufficient.

Why did it choose that action?

What situation did it perceive at that moment?

Which policies or rules did it apply?

What level of trust had been assigned to it?

And did the action remain within the scope of autonomy it had been authorized to exercise?

A Decision Trace is a mechanism for preserving this information in a form that can be examined and verified later.

However, storing a Decision Trace in a ledger does not necessarily make the evidence independently provable immediately.

There is a temporal gap between the moment a trace is recorded in the ledger and the moment it is cryptographically committed to an external verification system.

In this article, I refer to this gap as the:

Unanchored Evidence Window

This concept emerged from a question raised by Daniela Wild, Founder and CTO of SITA OS, during a LinkedIn discussion about the design of the Decision Trace Ledger.

The Question Raised by Daniela Wild

I believe that an AI agent’s execution authority must be separated from the mechanism used to preserve and verify evidence of its actions.

An AI agent may submit execution records through a narrowly scoped, append-only interface.

However, it must not have permission to modify or delete previous records, nor should it be able to administer the ledger itself.

The evidence verification mechanism must also remain independent of both the AI agent that performed the action and the Trust Engine that authorized it.

To explore this architecture, I began developing a lightweight open-source implementation called Decision Trace Ledger Core.

Rather than writing every piece of evidence stored in the ledger directly to a blockchain, I am considering an architecture in which only the ledger hash or Merkle root is periodically anchored to an external system.

This would make it possible to detect subsequent modifications to the ledger while avoiding the cost and latency of storing the complete Decision Trace on-chain.

Daniela responded positively to this design. She noted that creating a verification boundary independent of both the agent and the Trust Engine addresses an important gap in the trustworthiness of execution evidence.

At the same time, she raised a critical question:

How should the anchoring cadence be determined?
If anchoring occurs too infrequently, does that not widen the period during which a compromised process could rewrite entries that have not yet been anchored?

Her question revealed that the trustworthiness of evidence is not only a matter of storage location or cryptographic technique.

It is also a matter of time.

The concept that emerged from this observation is the Unanchored Evidence Window.

What Is the Unanchored Evidence Window?

The Unanchored Evidence Window is the period between the acceptance of a Decision Trace by the ledger and the confirmation that a cryptographic commitment containing that trace has been anchored to an independent external system.

It can be expressed as:

[
UEW = T_{\text{anchor confirmed}} – T_{\text{trace accepted}}
]

An important distinction is that the window does not end when the anchor is submitted.

It ends when the anchor is confirmed by the external system.

For example, suppose an AI agent approves an important contract at 10:00 a.m., and its Decision Trace is recorded in the ledger.

If the Merkle root containing that trace is anchored to an external system and confirmed at 10:15 a.m., the Unanchored Evidence Window is 15 minutes.

During those 15 minutes, the evidence exists in the internal ledger.

It may be protected by hash chaining and digital signatures.

However, it has not yet been fixed against an independent external reference.

“Recorded” and “Provable” Are Not the Same

Traditional audit systems often assume that evidence exists as long as the relevant record has been stored.

For autonomous AI agents, however, we need to distinguish at least the following states:

1. The trace has been accepted by the ledger.
2. The trace has been hash-linked to the surrounding records.
3. The trace has been included in a Merkle tree and its batch has been sealed.
4. The Merkle root has been submitted to an external system.
5. The anchor has been confirmed by that system.
6. The evidence has become independently verifiable by a third party.

The state transition can be represented as follows:

ACCEPTED
    ↓
INTERNALLY_CHAINED
    ↓
BATCH_SEALED
    ↓
ANCHOR_SUBMITTED
    ↓
ANCHOR_CONFIRMED
    ↓
EXTERNALLY_VERIFIABLE

This distinction allows us to explicitly represent an intermediate state in which evidence has been recorded in the ledger but cannot yet be independently verified from outside the system.

We therefore need to ask two separate questions:

Has the evidence been preserved?

And:

When did the evidence become independently verifiable?

The Unanchored Evidence Window is the temporal gap between these two conditions.

Why Internal Hashing Alone Is Not Enough

If each Decision Trace is linked to the previous record through a cryptographic hash, changing a record will break the consistency of all subsequent hashes.

This is an important mechanism for detecting tampering.

However, if highly privileged access to the entire ledger is compromised, an attacker may be able to modify previous records and recalculate all the hashes that follow them.

If the records, hashes, signatures, and verification references all remain within the same system, there may be no independent point of comparison after that entire system has been compromised.

This is why an external anchor is needed.

If a Merkle root representing the ledger at a particular point in time is recorded on a blockchain, an external timestamping service, or an independent audit platform, rebuilding the internal ledger later would produce a root that no longer matches the externally preserved commitment.

The internal hash chain protects consistency within the ledger.

The external anchor makes that consistency independently verifiable from outside the ledger.

These mechanisms do not compete with each other. They address different threats and are therefore complementary.

The Trade-Off in Anchoring Cadence

Writing every Decision Trace to a blockchain immediately after it is created could reduce the Unanchored Evidence Window.

In practice, however, this approach introduces several challenges:

• Transaction costs increase.
• The system becomes subject to external network latency.
• Processing large volumes of traces becomes difficult.
• Failures in the external anchoring infrastructure may interfere with AI execution.
• Handling confidential information and metadata becomes more complex.

Alternatively, multiple traces can be grouped together, with their Merkle root anchored once every hour or once per day.

This reduces cost and improves throughput.

However, the longer the interval between anchors, the greater the number of records that remain externally uncommitted.

Daniela’s question points directly to this trade-off.

The important point is that anchoring cadence should not be treated merely as an infrastructure setting.

It should be designed as a security policy that determines the required assurance level of the evidence.

Risk-Based Anchoring

Not every Decision Trace requires the same anchoring frequency.

The evidence requirements for an information search are different from those for a high-value financial transfer.

We can therefore introduce a Risk-Based Anchoring model in which the permitted Unanchored Evidence Window varies according to the risk of the action.

Risk level	Example actions	Example UEW target	Anchoring method
Critical	Financial transfer, permission change, disabling a safety function	Within 60 seconds	Immediate or near-real-time anchoring
High	Contract approval, modification of important data	Within 5 minutes	High-frequency micro-batching
Medium	Customer interaction, routine business processing	Within 30 minutes	Periodic batching
Low	Information retrieval, recommendation, summarization	Within several hours	Aggregated batching

These time limits are only examples.

Actual thresholds should be determined based on factors such as the impact of the action, regulatory requirements, business criticality, likelihood of attack, cost, and recovery requirements.

The anchoring policy may also consider factors beyond the general risk level, including:

• The AI agent’s current Trust Score
• The authority granted for the action
• The sensitivity of the affected data
• The financial and social impact
• Whether human approval was obtained
• The threat level of the execution environment
• The assurance level required by regulations or contracts

Anchoring can therefore become a dynamic assurance mechanism that responds to the execution context of the AI, rather than a background process operating on a fixed schedule.

Protecting the Unanchored Evidence Window

Even if it is difficult to reduce the Unanchored Evidence Window to zero, the evidence must not remain unprotected during that period.

Until the external anchor is confirmed, multiple defensive measures should be combined:

• Hash-link each trace to the previous trace.
• Write traces to append-only storage.
• Apply a digital signature when each trace is accepted.
• Seal Merkle tree batches at short intervals.
• Manage signing keys in a KMS or HSM isolated from the ledger.
• Separate ledger write permissions from administrative permissions.
• Replicate roots to multiple independent destinations.
• Continuously monitor anchoring failures and delays.
• Automatically detect traces that have exceeded their permitted UEW.

Another possibility is to issue a signed receipt immediately after accepting a trace and transmit that receipt to a location independent of the executing system.

Even before the external anchor has been confirmed, this receipt can provide supporting evidence that a particular trace existed at a particular time.

These measures do not fully replace external anchoring.

The objective is to layer multiple independent forms of evidence so that a single compromise cannot erase or reconstruct the complete evidentiary record.

UEW as a Security Metric

The Unanchored Evidence Window is more than an architectural concept.

It can be operated as a measurable security metric.

For example, an organization could continuously measure:

• The age of the oldest currently unanchored trace
• The total number of unanchored traces
• Average UEW
• Maximum UEW
• UEW by risk level
• Percentage of traces anchored within their target time
• Number of anchoring submission failures
• External delay between submission and confirmation
• Number of traces currently violating their anchoring policy

An SLO could be defined as follows:

99.9% of Decision Traces classified as Critical must be included in an externally confirmed anchor within 60 seconds of acceptance by the ledger.

This replaces vague claims such as “the system is resistant to tampering” with a quantitative measure of how long it takes for evidence to become independently verifiable.

Anchoring Failures and the Reduction of Autonomy

Another important principle is that an anchoring failure should not result only in a monitoring alert.

If the system remains unable to provide independent assurance for its evidence, the autonomy granted to the AI should be reduced.

For example:

IF action.risk = CRITICAL
AND oldest_unanchored_age > 60 seconds
THEN require_human_approval

IF oldest_unanchored_age > 15 minutes
THEN suspend_high_impact_actions

IF anchor_verification = unavailable
AND action.requires_external_evidence = true
THEN deny_execution

In other words, the health of the evidence infrastructure should become one of the factors evaluated by the Trust Engine.

When external anchoring is operating normally and the Unanchored Evidence Window remains within the permitted threshold, the AI can retain its normal level of autonomy.

As the delay grows, high-risk operations can be redirected to a Human Gate.

If the condition deteriorates further, high-impact autonomous execution can be suspended.

This creates a direct relationship between the AI’s autonomy and the assurance level of its evidence.

An AI should not be allowed to continue performing actions that the system can no longer independently prove.

This becomes an important design principle connecting the Decision Trace Ledger with Runtime Autonomy Control.

Information That Should Be Preserved in a Decision Trace

Managing the Unanchored Evidence Window requires the relationship between each trace and its external anchor to be explicitly recorded.

For example:

{
  "trace_id": "dt_01...",
  "accepted_at": "2026-07-28T01:00:00Z",
  "risk_level": "high",
  "anchor_policy": "high-risk-5m",
  "batch_id": "batch_01...",
  "merkle_root": "sha256:...",
  "anchor_provider": "external-ledger",
  "anchor_submitted_at": "2026-07-28T01:03:00Z",
  "anchor_confirmed_at": "2026-07-28T01:03:18Z",
  "anchor_reference": "tx-or-timestamp-id",
  "unanchored_window_ms": 198000,
  "verification_status": "externally_verifiable"
}

With this information, a later audit can verify more than the content of the trace itself.

It can determine:

• When the trace was accepted
• Which batch included it
• Which Merkle root protected it
• Which external system received the anchor
• When it became independently verifiable
• Whether it satisfied the UEW required by policy

The Roles of the Trust Engine and the Decision Trace Ledger

The Trust Engine and the Decision Trace Ledger answer questions at different points in time.

The Trust Engine answers a runtime question:

Should this AI be permitted to perform this action now, in this context?

The Decision Trace Ledger answers a post-execution question:

Can we prove which Trust state, Context, Policy, and Authority permitted the action at that moment—and whether the action remained within those boundaries?

The Unanchored Evidence Window adds another question:

When did that evidence become independently verifiable outside the system?

Together, these three questions connect pre-execution Authorization, runtime Decision, and post-execution Evidence.

A Design Concept Born Through Dialogue

The Unanchored Evidence Window was not part of the original terminology of the Decision Trace Ledger.

It emerged after Daniela Wild identified the temporal risk between the creation of evidence and the external anchoring of its Merkle root.

This is also an example of the value of dialogue in technical design.

An architecture may appear structurally sound, but a question from another perspective can reveal a risk that has not yet been named.

Once a risk has a name, it can be measured.

It can be defined as a policy.

It can be monitored.

It can be tested.

And it can be connected to the system’s autonomy controls.

Daniela’s question transformed anchoring “frequency” from an implementation detail into a temporal security boundary for evidence assurance.

Conclusion

Storing a Decision Trace in a ledger does not make that evidence independently provable immediately.

An Unanchored Evidence Window exists between the acceptance of the trace and the confirmation of its external anchor.

By explicitly recognizing and governing this period, the Decision Trace Ledger can move to the next stage of its design:

• Distinguish between “recorded” and “externally verifiable”
• Determine anchoring cadence according to risk
• Operate UEW as a measurable security metric
• Define acceptable UEW limits as SLOs
• Reduce AI autonomy when anchoring fails
• Dynamically connect the Trust Engine with the Evidence Plane

The central question for auditing AI systems is no longer simply whether a log exists.

We must also ask:

From whose authority is that log independent?

When did it become externally verifiable?

And how much autonomy was the AI permitted to exercise while its evidence remained unanchored?

These questions must become part of the architecture.

Evidence is not trustworthy merely because it was recorded.

It becomes independently verifiable when it is externally committed—and the time before that commitment must be governed.

Evidence does not become sufficient merely by being recorded.

It becomes independently verifiable only when it is cryptographically committed to an external system.

And the time before that commitment must itself become an object of AI governance.