Building an Evidence Pack for a Disputed Transfer

The dispute never lands the day of the transfer. It lands months later, in an email that begins "regarding the file you claim to have sent" — long after the details left your head, after logs may have rotated away, after the person who set up the flow moved teams. In that moment you do not need to have been perfect back then. You need to reconstruct what happened, quickly and convincingly, from records you had the foresight to keep. That reconstruction, gathered into one tidy bundle, is an evidence pack.

This is the capstone of the series, because an evidence pack is where everything else comes together: the signatures from signing files in practice, the receipts from proof-of-delivery patterns, the trustworthy times from timestamps and evidence quality, and the logic of non-repudiation. By the end you will know what belongs in a pack, how to assemble one without contaminating your own evidence, how to turn a pile of artifacts into a story, and — the part that quietly decides everything — the retention habits that keep the pieces reachable when you finally need them. This is part of our Signatures & Receipts series.

What an Evidence Pack Is

An evidence pack is a self-contained bundle that tells the complete story of one transfer, with proof attached at every step. Self-contained is the operative word: someone who was not there, handed only the pack, should be able to follow what happened and check each claim without hunting through live systems or being asked to "just trust me." It is the difference between saying "I'm sure we sent it" and putting a folder on the table that shows, in order, that you did.

A good pack has two layers. The artifacts are the raw proof — logs, the file, its signature, receipts, timestamps. The narrative is the short, human-readable story that walks a reader through those artifacts in sequence. Artifacts without a narrative are a shoebox of receipts; a narrative without artifacts is just your word again. Together they are evidence.

The Five Ingredients

Every pack draws from the same five sources, each answering a different question. You have met them individually across this series; here is how they combine:

• Logs — what happened and when. Connection, authentication, filename, byte count, and result, recorded at the time by systems with no stake in the later argument. Making these complete and trustworthy is the subject of our pillar on transfer logging and audit trails.
• Hashes — which exact bytes. A recorded hash lets you prove the file in the pack is the file that moved, and is the backbone of file integrity verification.
• Signatures — who produced the content. A detached signature ties the file to a key, and, if you confirmed that key, to a party.
• Receipts — that the far side received it. A confirmation file, a signed acknowledgment, or an AS2 MDN turns "we sent it" into "they got it."
• Timestamps — the thread that orders everything, trustworthy only because your clocks were synchronized and your logs speak UTC.

No single ingredient carries a dispute alone. The pack's strength is corroboration — a log time that matches a receipt time that matches a signature over a file whose hash matches the log. When five independent things agree, denial runs out of room.

Assembling the Pack: A Checklist

Assembly is methodical, not clever. Work through this checklist for the specific transfer in question, and resist the urge to skip the steps that feel obvious — the obvious ones are exactly what a skeptic probes.

Evidence-pack assembly checklist  (one transfer = one pack)
-----------------------------------------------------------
1. Identify the transfer precisely
   [ ] File name(s), batch/transfer ID, direction (sent or received), partner

2. Collect the file evidence
   [ ] The exact file as sent or received (or its recorded hash, if the file is gone)
   [ ] Its detached signature
   [ ] The public key needed to verify that signature

3. Collect the movement evidence
   [ ] Your server or client logs for the session
        (authentication, filename, byte count, hash, timestamp)
   [ ] The partner-side log or pickup record, if you can get it (for correlation)

4. Collect the delivery evidence
   [ ] Any confirmation file, signed acknowledgment, or AS2 MDN receipt

5. Pin down the timeline
   [ ] Confirm every timestamp is UTC and the clocks were synchronized
   [ ] Include any trusted-timestamp tokens

6. Protect the integrity of the pack itself
   [ ] Copy originals read-only; never edit them in place
   [ ] Record who assembled the pack, when, and from which systems
   [ ] Hash each collected item and list the hashes in an index

7. Write the one-page narrative
   [ ] Who, what, when, and the proof for each step, in order

A simple, consistent folder layout makes a pack easy to hand over and easy to revisit. One folder per disputed transfer, with numbered subfolders so the order is obvious, goes a long way:

disputed-transfer-nightly-invoice/     (one folder = one pack)
  00-index.txt        list of every file in the pack + a hash of each
  01-narrative.txt    the one-page story, in order
  10-file/            the data file + its .asc signature + the signer's public key
  20-logs/            sender log excerpt, receiver or pickup log excerpt
  30-receipts/        signed acknowledgment, or MDN, or confirmation file
  40-timestamps/      trusted-timestamp tokens, and clock-sync notes

Turning Evidence Into a Narrative

The narrative is where a pile of artifacts becomes a story a non-specialist can follow. Keep it to a page, keep it chronological, and for every step name the evidence that proves it. The shape is always the same:

• Who and what. Which partner, which file, which direction, and any batch or transfer identifier.
• Then, in time order: the file was prepared and signed (point to the signature and public key); it was sent or collected (point to the log line with the hash and UTC time); the far side acknowledged it (point to the receipt); the times line up (point to the correlated logs).
• The conclusion the evidence supports — stated plainly and no further. "These records show the file was delivered to the partner and acknowledged, unchanged, at this time," not "this proves they are lying."

Write it so that each sentence has a citation into the folder — "see 20-logs/sender.txt line 44." That discipline does two things: it makes the pack checkable by anyone, and it forces you to notice any claim you cannot actually back with an artifact. A claim you cannot cite is a gap to close, not a sentence to keep.

A Pack in Action

See how it pays off. A customer disputes an order they say they never authorized, and it hinges on a signed purchase file your system received from them months earlier. You open the pack for that transfer. The narrative reads in order: the file arrived on your SFTP endpoint (log line, with hash and UTC time); its detached signature verifies against the customer's public key, whose fingerprint your onboarding notes show you confirmed by phone; your ingestion job logged the same hash a minute later; and the signed acknowledgment your system returned is filed alongside.

You hand over the folder. A reviewer who has never met you can, from the pack alone, recompute the file's hash and match it to the log, verify the signature with the included public key, and watch the timeline agree to the minute across two systems. There is nothing to take on faith. The dispute resolves not because you argued well but because the evidence was assembled, indexed, and preserved before anyone asked for it. Notice, too, what would have wrecked it: had the public key been deleted when that customer relationship cooled, the signature in the pack would verify against nothing, and the strongest artifact would be inert. A pack is only ever as good as the retention behind it — which is the next thing to get right.

Retention: The Habit That Makes It Possible

Here is the uncomfortable truth the whole article turns on: you cannot assemble a pack from evidence that no longer exists. The most common reason a reconstruction fails is not a missing signature or a clever adversary — it is that the logs rotated away, the receipt was never saved, or the public key needed to verify a two-year-old signature is long gone. Retention is not glamorous, and it is the single habit that decides whether any of the rest was worth doing.

A few principles make retention reliable rather than hopeful:

• Keep the verifying material, not just the signature. The public key that checks a signature must outlive the signature itself. Retire a partner and delete their key, and every signature you kept from them becomes unverifiable overnight.
• Protect evidence from quiet edits. Evidence you can alter is evidence someone can claim you altered. Store packs and their source logs somewhere append-only or write-once — the idea often labeled WORM (write once, read many) — so nobody, including you, can change them after the fact.
• Set a retention period on purpose. Match it to how long a transfer could realistically be disputed and to any rules your industry imposes. Then make sure log rotation and cleanup jobs respect that period instead of silently undercutting it.

The table below is a starting point for what to keep and why. Treat the "keep until" column as guidance to adapt, not a rule — your dispute window and any regulations you follow set the real numbers, which is a good conversation to have with compliance rather than to guess at.

Most of this retention happens for you if the flow was built to log richly and keep receipts as a matter of routine. A server that records detailed activity logs, such as Sysax Multi Server, gives you the movement half of every pack automatically, and an automation client such as Sysax FTP Automation that signs on the way out and files the acknowledgment on the way back means the artifacts already exist when you go looking — you are collecting, not manufacturing.

Common Gaps That Sink a Pack

When a pack fails to convince, it is almost always because of a hole that was cheap to prevent and impossible to fix after the fact. The recurring ones, and the habit that closes each:

• No recorded hash. Without a hash captured at transfer time, you cannot prove which exact bytes moved, and "the file was different" becomes unanswerable. Log a hash on every transfer.
• The receipt was never captured. A delivery happened but nothing came back, or the acknowledgment was deleted with an old mailbox. Design receipts into the flow and file them with the transfer record.
• Logs that lived only on the box. When the sole copy of a log sits on the server, it dies with the server — or with an attacker who clears it. Ship logs off the box so a second copy survives.
• An unconfirmed key. A signature verifies, but you never confirmed the key belonged to the partner, so it proves nothing about identity. Confirm fingerprints out of band and record when you did.
• A timeline that contradicts itself. Unsynchronized clocks turn corroboration into an argument. Keep every evidence-producing machine on the same synchronized, UTC time.

Every item on that list is decided long before the dispute, by how the flow was built. That is the real lesson of the pack: it is assembled after the fact, but it is made possible by choices you make when you first set the transfer up.

Chain of Custody, Lightly

Chain of custody is a heavy legal phrase for a light, sensible idea: being able to show that the evidence in your pack is the same evidence that came off the systems, unaltered since you collected it. You do not need a courtroom process for everyday disputes, but a few habits cost nothing and pay off enormously if things escalate:

• Work on copies, never originals. Pull logs and files into the pack as read-only copies and leave the source untouched, so the live record and your working copy can be compared if anyone asks.
• Record who, when, and from where. A single line — assembled by whom, on what date, from which systems — turns an anonymous folder into a collected exhibit.
• Hash the collected items and index them. Listing a hash for every file in the pack lets you later prove nothing changed since assembly. If a hash still matches, the item is exactly as collected.
• Store the pack under access control. Somewhere append-only if you can, with limited write access, so the bundle itself has the same tamper-resistance you want for the logs inside it.

The theme echoes the whole series: you are not proving a negative is impossible, you are stacking small, honest measures so that any claim of tampering has to explain away all of them at once.

When to Involve Legal and Compliance

Assembling and preserving technical evidence is squarely an administrator's job. Interpreting what it means for liability is not. The moment a dispute involves real money, a contract, or a regulatory obligation, bring in legal and compliance — and bring them in early, because their first instruction is usually about preservation. They may place a hold that requires you to stop the normal deletion clock on everything related, and losing evidence to a routine cleanup job after a dispute has begun is a genuinely serious mistake you want to avoid by asking sooner rather than later.

Your value in that conversation is precision: here is exactly what we have, here is how it was collected and kept, here is what each piece does and does not prove. That is admin evidence practice, and it is a world away from opining on the legal outcome. Keep your statements to what the artifacts support, hand the interpretation to the people whose job it is, and you serve the case far better than by overreaching.

Putting It Together

An evidence pack is the point of the entire series: one self-contained bundle that tells a single transfer's story with proof at every step. Gather the five ingredients — logs, hashes, signatures, receipts, timestamps — collect them onto copies without disturbing the originals, index and hash what you gather, and write a one-page narrative that cites each artifact in order. Then remember that none of it survives without retention: keep the logs, the receipts, and above all the public keys long enough to outlast any realistic dispute, stored where they cannot be quietly changed. Do this, and the email that arrives months late stops being a scramble and becomes a folder you already have.

To revisit the pieces, start with non-repudiation for business for the why, then timestamps and evidence quality and proof-of-delivery patterns for two ingredients admins most often get wrong. The broader habits live in our pillars on transfer logging and audit trails and file integrity verification.

Frequently Asked Questions