The log says done. Prove it.

A clean finish can hide a dirty handoff

An AI assistant says it completed the task. The terminal shows a green exit code. The work tracker says done. You open the result and discover that the wrong file was changed, the command ran against a different revision, the test covered an easier case, or nobody checked the final output after the last edit.

The problem is not that logs are useless. A log can tell you that a process emitted a message at a particular time. It cannot, by itself, tell you that the intended input was used, that the output is correct, or that a human agreed with the decision.

NIST's AI Risk Management Framework puts the useful distinction in more formal language: validity is confirmed by objective evidence that requirements for an intended use have been met, while reliability is assessed under defined conditions over time. Monitoring and human intervention may still be needed when a system cannot detect or correct its own errors. For an everyday AI-assisted task, the translation is simple: treat a log as one witness in an evidence packet, not as the verdict.

Five questions a small evidence packet should answer

**1. What was the task supposed to do?**

Write the intended outcome in one sentence, then write the boundaries beside it. “Update the article link” is incomplete. “Update one link in this article, keep the wording unchanged, do not alter navigation or deployment files, and leave the change ready for review” is testable.

This matters more with an agent because a fluent explanation can make extra work sound like helpful initiative. State which files, commands, systems and outward-facing actions are out of scope before the tool runs.

**2. Which inputs and revision were used?**

Record the source version, not only the source name. That may be a Git commit, a document revision, a model and runtime identifier, a dependency lockfile, or the retrieval date of an external source. If the input can change while the task is running, say which snapshot counts.

This is the everyday version of provenance. SLSA describes provenance as verifiable information about where, when and how an artifact was produced, separating inputs, dependencies and execution details. You do not need to implement SLSA to borrow the habit: put the exact revision and important dependencies in the record.

Git helps here because its objects are content-addressed, and a commit points to a project snapshot plus its parent history and message. A branch name such as `main` is useful for navigation, but it is not a durable answer to “which code did this run use?” Record the immutable commit identifier as well.

**3. What actually happened?**

Capture observed facts, not the agent's narration. A useful minimum is:

Do not put secrets, private prompts, credentials or sensitive household data into the packet just to make it look complete. A checksum, file list, test result and redacted outcome often provide more durable evidence than a full transcript.

**4. Who or what challenged the result?**

Self-checking is useful for catching obvious mistakes, but it is not independent review. The person or agent that authored a change should not be the only authority deciding that the same change is ready. A reviewer needs the exact revision, the intended scope and the checks that matter for the consequence of failure.

GitHub's protected-branch guidance makes this operational: repositories can require pull-request reviews and status checks, and approvals can become stale when the diff changes. The practical rule is portable: review the version you are about to accept, not a nearby version that used to be current.

**5. What is the recovery path?**

An evidence packet is not complete if it can only explain success. Name the previous revision, backup, revert, disable switch or manual fallback before the irreversible step. Record who owns the recovery action and what observation would trigger it.

For a small content change, recovery might be a revert commit and a check that the previous page returns. For an agent that edits a home-automation rule, it might be a known-good configuration export and a manual control path. For a production release, it includes the old build identifier and a health check. The right recovery is proportional to the harm, but “we can probably undo it” is not a recovery plan.

• the run identifier and start and finish times;
• the exact commands or checks that were allowed to run;
• the files or systems that changed;
• the output or result that was inspected;
• failures, skips, retries and unknowns.

Turn a claimed fix into a reviewable handoff

For a one-link documentation update, the useful deliverable is not a confident summary. It is a compact release record that lets a reviewer reconstruct the decision without opening the agent transcript. Write these six fields:

Notice what this packet does not claim. It does not prove that the agent “understood” the request, that every unobserved side effect is impossible, or that a passing test covers every future environment. It proves the narrower thing that matters: what was intended, what version was used, what was observed, who challenged it and what to do if the result is wrong.

• **Intent:** change only the link target and its source-register row; leave prose, layout and deployment configuration alone.
• **Inputs:** record the starting commit, the exact source URL checked today, and the two files in scope.
• **Execution:** let the agent work on an isolated branch, then record the resulting commit, exact diff file list, content validation result and tests. If a check was skipped, say why.
• **Review:** ask an independent reviewer to inspect the claim, link, privacy boundary and diff at that exact commit. If corrections land, run the checks and review again at the new commit.
• **Decision:** keep the change unpublished until the authorised person accepts that exact candidate. A separate publisher can then merge and release it, followed by a check of the public page.
• **Recovery:** retain the prior commit as the rollback reference and state what would cause a revert.

Limits and what we would do next

Evidence is not certainty. Logs can be incomplete, a source can be stale, a test can miss an important condition and an independent reviewer can share the author's blind spot. Provenance also describes production history; it does not automatically prove that an artifact is good. NIST's framework is voluntary guidance, not a certificate that a workflow is safe. Do not turn a tidy packet into a claim of compliance or guaranteed correctness.

What we would do next is pick one AI-assisted routine and create a six-line record before its next run: intent, exact inputs, allowed authority, observed checks, independent reviewer and recovery owner. If any line is blank, the routine is asking a log, a model or a scheduler to carry a decision it cannot safely carry. Fill that gap before granting the workflow more autonomy.

Sources and limits

This article synthesises the sources below into a practical explanation. It is not a security standard, legal advice, or a guarantee that guidance current at review time still applies — check the review date above against your own situation.

1. Artificial Intelligence Risk Management Framework 1.0 — National Institute of Standards and Technology. Defines valid and reliable AI operation in terms of objective evidence, testing and monitoring, and connects transparency with accountability and actionable redress.
2. Provenance v1.2 — SLSA. Defines provenance as verifiable information about where, when and how an artifact was produced, including source provenance and build provenance.
3. Git Objects — Git. Explains Git's content-addressable object store and how commits identify a project snapshot together with its history and message.
4. About protected branches — GitHub Docs. Documents required reviews and status checks, including the need to review the latest change and the possibility of stale approvals after the diff changes.

More from Server Attic

• 2026-09-04

  A web page is not permission for your AI agent

  An agent can use a page, document or message as evidence without treating instructions inside it as authority. Design that boundary before connecting powerful tools.

• 2026-08-14

  Give your AI agent a budget

  Permissions limit what an agent may touch. A separate budget for time, steps, data and queued work limits how much it can consume before it must stop.

• 2026-08-12

  An agent's memory is not an audit trail

  Memory helps an agent continue a task, but it cannot prove what happened. Separate useful context from a small, reviewable record of each run.