Evidence starts before execution

An assistant sends a document to the wrong recipient. The activity log says the send operation succeeded. Technically correct. Also a remarkably small contribution to understanding what happened.

The useful questions begin earlier. What did the person request? How was the recipient identified? Which version of the document was selected? What permission covered the disclosure? Did anything change between approval and execution?

This is why I think evidence should be designed alongside the action itself. If we wait until an incident to decide what we wish we had recorded, the list tends to become ambitious.

A useful record would connect the original instruction, its authenticated source, the proposed action, the applicable permission and the observed result. Those are different things. An incoming document may contain an imperative sentence without having any authority to issue instructions. A model may propose an action without being entitled to execute it. A service may accept a request without completing the underlying work.

Keeping these distinctions intact makes the record more valuable. Flattening everything into a transcript can leave the reader to reconstruct relationships that the system knew perfectly well at the time.

The W3C PROV framework offers an established vocabulary for describing provenance through entities, activities and agents. It provides a useful way to think about where information came from and how it was produced. Applying that vocabulary to an assistant would still require careful choices about which events to capture and which relationships can genuinely be established.

For example, imagine an assistant proposing a supplier-bank-detail change. The record should distinguish a request received by email from verification through an approved independent channel. It should preserve which account approved the exact change and whether that approval preceded execution. A later summary saying “the change was authorised” would be a conclusion. The underlying observations are what allow somebody else to assess it.

I would favour recording this evidence at the points that possess it. The identity service records authentication. The approval service records the decision and the action it covered. The executor records what it submitted. The destination supplies whatever acknowledgement it actually provides. Correlation identifiers can join the sequence without asking one model to narrate its own conduct afterwards.

There are limits. A compromised identity service may produce misleading records. Missing clocks or inconsistent timestamps can distort ordering. An external service may expose only part of what happened. These gaps should remain visible. Confidence becomes more useful when its boundaries are stated.

Cryptographic techniques can strengthen some claims. Certificate Transparency, for example, specifies append-only log structures and proofs for certificate records. That illustrates how inclusion and consistency can be checked within a defined system. It does not establish that arbitrary recorded content is true, that nothing happened outside the log or that a particular person understood an approval screen.

Those distinctions are worth preserving before somebody puts “tamper-proof” on a slide.

Operational evidence also has to support investigation. NIST's guide to integrating forensic techniques into incident response discusses multiple sources of computer and network evidence, while explicitly avoiding a promise of an all-inclusive forensic procedure. An assistant's records would be one source within that broader investigation. They should make correlation easier and disclose known collection limits.

There is a privacy question too. Recording every screen, message and credential indefinitely would create an impressive new collection of things to lose. The ICO's data-minimisation guidance emphasises information that is adequate, relevant and limited to the stated purpose. For an evidence system, that suggests deliberate retention periods, restricted access and references to protected content where full duplication is unnecessary.

A good design should allow a reviewer to answer a bounded set of questions with reasonable confidence. Who requested the action? What authority existed? What was attempted? What outcome was observed? Which parts remain uncertain?

That would already be a substantial improvement over a successful API response and a very articulate explanation of why everything was probably fine.