# How to keep agent evidence separate from investigator notes An agent investigation goes wrong the moment an analyst turns the evidence file into a notebook. The temptation is understandable. You have an encrypted audit record, a strange outbound request, and a deadline. You decrypt or export it, add a comment beside the suspicious call, reorder a few fields so the timeline reads better, and save the result as the case record. Months later, nobody can separate what the agent did from what the investigator thought it meant. Keep the original encrypted record intact. Put every conclusion, question, hypothesis, and correction in a separate case file that points back to stable session and call identifiers. That division sounds fussy until someone challenges the finding, a second analyst takes over, or legal asks which bytes existed before the investigation began. Then it is the difference between an auditable account and a persuasive looking document with an unknown history. ## Evidence and analysis answer different questions Evidence answers, "What record did the system preserve?" Investigator notes answer, "What do I think that record means?" Those are related questions, but they need different handling because the first must remain stable while the second must change as the case develops. An encrypted audit record can contain uncomfortable facts: an agent process invoked a credentialed HTTP action, an SSH command returned an unexpected result, or a user approved a run that later behaved differently than expected. The record is not a draft. Do not improve its wording, remove entries that seem irrelevant, or rewrite a timestamp into a friendlier format. Even a harmless edit destroys the clean answer to a basic review question: is this the same record that the system produced? Notes must stay editable because good investigations revise themselves. An early note might say, "Call c-204 appears to have sent customer data." After reading the request and response context, the analyst may correct it to, "Call c-204 sent an internal identifier in a request header; the record does not establish that customer data left the environment." That correction is healthy. It belongs in the case file, where the change remains a change in reasoning rather than a mutation of evidence. The distinction people routinely blur is preservation versus readability. Decrypting, exporting, searching, parsing, and rendering make evidence usable. They do not turn the output into the original. A JSON export, spreadsheet, PDF printout, or pasted transcript is a derivative. It may be accurate and useful, but it needs a label that says how it was produced and which preserved object it came from. Treat this as a working rule: the source record is read-only, and every explanatory sentence lives elsewhere. That rule also makes collaboration less brittle. A second analyst can disagree with your conclusion without touching the source, and a reviewer can test your citation without reconstructing your editing history. ## Stable identifiers make claims testable A conclusion should cite the smallest stable unit that supports it. In agent activity, that usually means a session identifier for the agent run and a call identifier for the individual action. Use both when the relationship between them matters. A session identifier answers, "Which agent process run are we discussing?" A call identifier answers, "Which specific HTTP or SSH action inside that run supports this claim?" Neither identifier proves anything on its own. They are durable addresses. The proof comes from the preserved record at that address, plus your explanation of what it says. Do not invent a friendly identifier scheme when the system already assigns one. Analysts sometimes write references such as "the third request after approval" or "the request near 14:00." Those phrases may help a reader, but they fail as citations. A timeline changes when a view is filtered; clocks can differ; later records can make "third" ambiguous. The assigned session and call IDs survive sorting, export, and handoff better than prose shortcuts do. Use a claim table in the separate case file. It does not need a case-management product. A plain structured document is enough if it preserves the distinction between the claim and the citation. | Claim ID | Investigator conclusion | Evidence reference | Status | | --- | --- | --- | --- | | C-01 | The agent run reached the payment API after its first authorization. | Session `s-7f31`; calls `c-204`, `c-205` | Supported | | C-02 | The request changed a payment record. | Session `s-7f31`; call `c-205`; response record | Unresolved | | C-03 | The human intended that change. | Approval record; no call evidence establishes intent | Unsupported | This table does two useful things. First, it prevents a citation from being mistaken for an explanation. Second, it lets an analyst mark an attractive story as unsupported without deleting it. That matters when a case gets tense. People often erase failed theories, then later cannot explain why the team ruled them out. Use exactly the identifiers the source exposes. Do not assume their format, length, or global uniqueness beyond the scope documented by the system. If an identifier only makes sense within one collected journal, record the journal or evidence-package identifier beside it. Stable does not mean magical; it means another investigator can resolve the reference against the same preserved source. ## A readable export is a derivative, not the record Most investigations need a readable view. You cannot examine encrypted bytes by squinting at them, and nobody should pretend otherwise. Create a derivative for review, but make its relationship to the source explicit before you start annotating it. Start with an evidence register entry. Record the case reference, the original file or package name, when and from where you collected it, who collected it, the session scope if known, and the verification result. Add the command used for verification and preserve its terminal output with the case materials. Do not fill gaps with assumptions. If you do not know the collector or collection time, write "unknown" and open a question. Sallyport projects its Sessions and Activity journals from one write-blind encrypted, hash-chained audit log. Its offline verifier needs no vault key, so an investigator can verify the preserved encrypted material before asking anyone to expose readable content: ``` sp audit verify ``` Record the actual command, its arguments, the exit status, and its complete output in the evidence register. Do not write a fictional success line into a report because a command "should" have worked. The output is part of the verification event. If verification fails, stop treating downstream interpretations as settled evidence. Preserve the failed result, collect the intact source again if possible, and explain the break rather than quietly swapping in a later export. Then create a review derivative under a name that says what it is. For example: ``` case-2026-041/ original/ audit-record.enc verification/ verify-command.txt verify-output.txt derivatives/ activity-readable-2026-07-24.json notes/ findings.md claim-table.md ``` The folder names are not a chain of custody by themselves. They force a useful habit: originals, verification material, readable derivatives, and analysis do not occupy the same conceptual bucket. Restrict write access to the original directory. If your storage controls cannot enforce that, calculate and record a digest where your evidence process permits it, then make a fresh working copy for analysis. The point is to make accidental edits obvious and recovery possible. Do not call a transformed file "raw" just because you did not manually edit the text. A tool that decrypts, parses, filters, pretty prints, normalizes time zones, or removes fields has transformed the representation. That transformation can be entirely legitimate. Name it. ## Reserializing records creates arguments you cannot win Reserialization means decoding structured content and writing it out again. Investigators do it when they reformat JSON, save a spreadsheet, regenerate a report, or pipe data through a parser that chooses its own field order and escaping. It feels harmless because the semantic content may look identical. In a challenged investigation, "looks identical" is a miserable standard. Suppose an analyst exports activity into JSON, sorts calls by a local display time, adds a `reviewed: true` field, and saves the file as `audit-final.json`. A reviewer later notices that two events share a displayed second, but their original order matters. The export no longer tells the reviewer whether sorting preserved the source order. If an error occurred during parsing, the altered file may hide it. The analyst now has to defend a toolchain and a workflow instead of pointing to a preserved record. Another common failure is redaction by replacement. Someone changes a credential-looking value to `REDACTED`, then circulates the edited record as evidence. That creates two problems. The value may not have been a credential at all, and the review copy now differs from the original at an unknown set of positions unless the team documented every change. Redact a copy for sharing, label it as a redacted derivative, and retain the source under the appropriate access controls. Human notes can also accidentally reserialize evidence. A pasted request body in a ticket may lose escaping, whitespace, order, or nonprinting characters. A screenshot can hide content outside the visible pane. A report quotation can omit the response that changes the meaning of the request. Cite the call ID first. Quote only the minimum text necessary to explain the conclusion, and say that the quotation came from a readable derivative. A good case file records transformations in prose that another person can test. For example: "D-03 was produced from original O-01 after successful offline verification. The export process decrypted the record for review, limited the view to session s-7f31, and did not overwrite O-01." If you filtered, say so. If you normalized time zones, say so. If a tool discarded fields, say so. Silence is where accidental evidence laundering hides. ## Approval records narrow the claim, not the meaning An approval record proves a narrower thing than people want it to prove. It can show that a person approved a particular agent process run, or that they approved a credential use when a per-call control required it. It does not prove that the person read every proposed action, understood every consequence, or intended the resulting business change. That limit matters when an investigation reaches an uncomfortable question: "Did the user authorize this?" Do not answer with a single word. Break the statement apart. The user may have authorized the process to operate in that session. The process may have used a credential later. The request may have succeeded. The resulting action may still have exceeded what the person believed they were allowing. The evidence can support some of those propositions and leave others open. Sallyport's decision ladder makes these distinctions concrete. A locked vault denies every action. Per-session authorization, enabled by default, approves a newly seen agent process run until it exits. A per-call key setting requires approval for each use of that credential. An investigation should identify which control applied, then state only what that control establishes. Write findings with that boundary visible. "The evidence shows that the user approved the signed process for session s-7f31" is a claim about session authorization. "The evidence shows that the user approved call c-205" needs a per-call approval record for that call. "The user intended to change a payment record" needs evidence about intent, which may sit outside the action journal entirely. Do not promote the first sentence into the third because it is convenient. This is one place where analysts often make a recommendation I reject: treat all approvals as equivalent evidence of informed consent. It is popular because it produces a simple verdict. It is wrong because the controls have different scopes. A run-level approval and an action-level approval answer different questions, and neither reads a person's mind. ## Build notes that can change without contaminating the case Your notes should invite correction while making authorship and time visible. A good finding contains a claim, a reason, citations, limits, and a disposition. It does not need a theatrical narrative voice. Use a format like this: ```markdown Finding: The agent called the payment API after session approval. Claim: Session s-7f31 included a credentialed HTTP call to the payment API. Evidence: Session s-7f31; call c-205; derivative D-03. Reasoning: The call record identifies the configured HTTP channel and the destination represented in the record. Limits: This record does not establish the human's business intent or the full downstream effect. Analyst: initials Recorded: 2026-07-24T18:32:00Z Status: supported ``` The word "reasoning" earns its place. A list of IDs is not a finding. State the connection you infer, and state what the record cannot establish. Readers trust a finding more when its boundary is written plainly. Do not embed mutable personal annotations inside evidence filenames or object metadata. A filename such as `bad-call-confirmed.enc` turns an opinion into apparent source truth. Use neutral evidence names such as `O-01-audit-record.enc` and place the opinion in `F-04-findings.md`. This saves trouble when "confirmed" becomes "not supported" after a second review. Keep observations separate from conclusions within the notes. An observation might read, "The activity record for c-205 reports a successful response." A conclusion might read, "The agent likely completed the requested action." The first depends on the record's contents. The second depends on what a successful response means for that API, and may require API documentation or an independent system record. Marking the boundary prevents analysts from smuggling interpretation into an alleged fact. If several people work the case, let them disagree in the notes. Give each competing conclusion a claim ID and evidence references. Do not merge disagreement into a bland consensus sentence. A later reviewer should see whether the evidence resolved the dispute or whether the team merely stopped discussing it. ## A failed timeline usually begins with a harmless edit Consider an incident where a coding agent accesses an internal deployment API. The operator notices an unfamiliar change and exports the activity journal to a spreadsheet. To make it easier to read, the operator sorts rows by local time, deletes fields that look repetitive, and colors the row believed to be the cause. They then add a comment, "Agent deployed unapproved configuration," and send the workbook to the response team. The first problem appears when another analyst asks which process made the call. The spreadsheet contains a call ID but the session ID column was one of the deleted "repetitive" fields. The team cannot quickly distinguish one run from another. The operator remembers that all rows came from the same run, but memory is not a citation. The second problem appears when the team compares the action to an approval. The workbook shows a nearby approval time, but it does not preserve enough context to establish whether the approval applied to the run or to that individual credential use. The comment has already shaped the discussion, so people begin arguing about whether the action was unapproved instead of first asking what kind of approval the evidence records. The third problem appears when the deployment team says the API response meant "accepted for processing," not "configuration deployed." The colored row was real. The conclusion was too broad. Because the operator placed it inside the apparent evidence artifact, readers treated it as a property of the record rather than a fallible interpretation. A cleaner reconstruction looks different. Preserve the encrypted audit record as O-01. Run `sp audit verify` against O-01 and save the command result. Create D-01 as the readable view. In the case file, write three separate claims: which session made which call, which approval scope applies, and what the response establishes. The third claim may require a deployment-system record. If it remains unresolved, leave it unresolved. That is not an incomplete investigation; it is an honest one. The detail that saves this case is boring: call c-205 is not the same thing as the sentence written about call c-205. One is a reference to preserved activity. The other is a conclusion with an author, a date, and a chance of being wrong. ## Verification must happen before interpretation hardens Verify the preserved audit material before the team builds a story around it. Once a theory circulates in chat, tickets, and meetings, people start reading records to defend it. Verification then becomes a ritual performed after the conclusion has social weight. The sequence should be simple. Collect the source without altering it. Record where it came from and who handled it. Verify the encrypted material with the supported offline command. Preserve the verification result. Create a labeled readable derivative only after that. Then begin the claim table and notes. Hash-chain verification is especially useful because it checks the stored encrypted record without requiring the vault key. That separates two questions people often combine: "Has the record retained its chain integrity?" and "Who is allowed to read the sensitive contents?" An investigator can answer the first without widening access to secrets merely to perform a basic integrity check. A successful verification result does not settle source identity, completeness outside the collected range, or interpretation. It says the verifier accepted the chain presented to it. Record the scope you actually collected. If the case concerns a suspected gap before the first retained session, do not write "the audit shows no earlier action" unless you know the collection contains the relevant earlier history. The defensible sentence is narrower: "The collected record contains no earlier action of this type." The same discipline applies to revocation. A session may be revoked in the journal, but that record describes the control event and its recorded scope. It does not automatically explain actions that completed before revocation, work already accepted by an external service, or side effects outside the channel's response. Tie each proposition to the record that can support it. ## Put the case file under review, not the source under revision Evidence should remain stable. Findings should face review. Make reviewers challenge the link between each conclusion and its cited session or call, rather than asking them to compare unexplained versions of a modified export. A useful review pass asks four direct questions: 1. Can I locate every cited session and call in the preserved record or a documented derivative? 2. Does the finding distinguish the recorded event from the analyst's inference? 3. Does the stated approval scope match the conclusion being drawn? 4. Did the author name any transformation, filter, redaction, or missing context that affects this claim? If a reviewer cannot answer one of those questions, the fix belongs in the case file unless the preserved source itself was collected incorrectly. Do not patch a derivative until it resembles the desired narrative. Correct the derivative process, produce a new labeled derivative, and retain the earlier one if it informed a material finding. For teams using Sallyport, the Sessions journal and Activity journal give investigators two natural citation levels, while instant session revocation gives a separate control event to examine. Use those records as anchors, not as a substitute for analysis. The journal can tell you what it recorded; the case file must explain what the team can responsibly conclude from it. The first action after collection should be dull and precise: reserve an original, verify it, and open an empty findings file beside it. Write the first conclusion only after you can cite the session and call that support it. That small bit of discipline prevents months of argument about whether the evidence changed when the investigation did.