Compare sent and received file manifests
Match sender and receiver evidence without treating a sent link as proof of receipt.
Tools for the documented steps
Practice relevance
Cross-practice idea · Useful supporting administrative method; no claim of practice-specific legal instructions.
Scope: PowerShell file hashes and Excel manifests; file-transfer identity check, not legal service or disclosure certification.
The problem
Match sender and receiver evidence without treating a sent link as proof of receipt.
Why it matters: A successful send does not establish that the intended recipient received the right files. Comparing independently captured manifests and acknowledgments helps staff identify missing or changed items while leaving legal custody conclusions to the reviewer.
Sources & evidence
Proposed / not tested. The public source describes the problem. Documentation supports only the stated method components; no result from this recipe has been verified.
What’s been verified
Source methods and reported problems have been reviewed. We have not run the adapted workflow. The sample below describes expected behavior on synthetic data, not a customer result.
What to measure: In a synthetic pilot, count correctly found exceptions, false alarms, and unresolved inputs. No time or cost saving is assumed.
- Pain evidence: Document production ↗Document production, 18 May 2025, older, original read. A firm paralegal preparing a large production with spreadsheets and videos asks how to transfer it reliably; a commenter explicitly raises missing/corrupted batches. Firsthand transfer burden is direct; specific corruption warnings are commenter observations, not independently verified product defects. Friday rant thread comment, 17 May 2019, older, practitioner comment read in the original thread (direct comment fetch failed) describes a 30,000-document production not downloaded for months before access complaints. The manifest/acknowledgment comparison is our proposed remedy.
- Pain evidence: Friday rant thread comment ↗Additional self-reported public account; no independent identity or outcome verification.
- Pain evidence: original thread ↗Additional self-reported public account; no independent identity or outcome verification.
- Method: Get-FileHash ↗Microsoft Get-FileHash documents SHA-256 file hashing for change detection. The script/tool must already be approved. Hash equality supports byte consistency for supplied files, not legal authenticity, chain-of-custody sufficiency or proof that someone reviewed the content.
Source checked: October 15, 2026. Pain accounts are self-reported. Documentation supports components; this adapted recipe and prompt have not been tested. We wrote these prompts. The adapted workflow hasn’t been tested.
Suggested approach
Start when: Staff has sent an authorized packet and receives destination hash/receipt data
- match transfer IDs and file IDs across sender/recipient manifests, compare sizes/SHA-256 and supplied acknowledgment
- Keep source references and report unknowns instead of filling gaps.
- The responsible reviewer checks the report before any separately approved action.
Limits and review
The assistant drafts or reports only. Check source records and review the output before a human performs any separately approved send or change. No automatic legal decision, money movement, account connection or publication is included.
Who reviews it: Litigation staff verify receiving evidence and custody records; lawyer decides production sufficiency, preservation and legal consequences. No inference that a link click equals successful receipt or review. This check does not authorize uploading/sending anything.
What you need
Your firm-approved AI assistant · prepared files
- Existing PowerShell 7 on Windows and IT approval to run the bundled helper under the existing script policy. No install, elevation or execution-policy bypass is part of this route.
- An approved stable, fully local working snapshot and an existing output folder outside it on the same fixed local drive. Both paths must be absolute drive-letter paths with ordinary, non-reparse-point ancestors. No live/cloud/network/mapped-drive repositories, original forensic media or restricted paths.
- The records/IT owner must exclude credential/profile directories and all secret material before selecting the snapshot. The helper uses -Force and hashes every readable regular file, including hidden files; it does not detect or redact secrets.
- Records owner supplies scope and identity/custodian/family metadata; hashes establish byte equality only.
- The actual authorized transfer scope, sender manifest, recipient identity, receipt/acknowledgment evidence and any approved transformation mapping.
- Recipient-side file access and independently generated hashes must be supplied by the authorized recipient/IT owner; this workflow does not contact them or transmit client data.
- Firm-approved Excel; optional Copilot entitlement and tenant approval for the exact minimized data. Native Excel analysis can be done manually if Copilot is absent.
- Keep raw exports and identifying source pointers in a separate restricted location. The AI workbook contains only approved alias-based tables and visible policy/scope text, never raw client records on another tab.
- Use synthetic inputs first. Keep real data in firm-approved accounts and processing, with appropriate access, confidentiality and retention controls. Aliases alone do not anonymize records. Never paste credentials, API keys or unnecessary client details.
How to use
Advanced · Advanced proposed local-snapshot route; helper statically reviewed only and not runtime-tested; full transfer verdict requires independent receiver evidence and acknowledgment
- Sender-side hash and a delivery notification do not prove receiver-side content. A receiver manifest is mandatory for byte comparison.
- Renames or transformations need an approved source/destination map. Equal hashes do not prove recipient identity, access or acknowledgment.
- Advanced helper route: existing Windows PowerShell 7, approved stable snapshot, IT code review and a safe synthetic test under existing policy are prerequisites. The helper is not a security boundary against concurrent or malicious filesystem changes. No runtime test was performed here.
Check access and setup
- Actual account access, plan and source-data completeness have not been tested.
Collect real local file sizes and SHA256 hashes
PowerShell 7 on Windows · Existing PowerShell 7 session > reviewed Inventory-ApprovedLocalSnapshot.ps1
Have IT review the bundled helper and test it on a synthetic fixture under existing script policy before using approved work files. Set absolute snapshot and output paths on the same fixed local drive, with the output directory outside the snapshot. Before running, exclude credential/profile directories and secret material: -Force includes hidden files and there is no automatic secret detection. Run the command below with approved paths. The helper checks path forms, drive type and every directory ancestor, then walks ordinary directories one level at a time without following reparse points, records read/enumeration errors, hashes readable regular files with SHA256, and writes new inventory/issues/control files outside the input. It does not change source bytes. Reads may affect access metadata; this is not forensic acquisition.
- Expected output
- Native-cmdlet-derived local_row_id,relative_path,original_name,size_bytes,sha256,observed_last_write_utc,captured_at_utc plus issues/control logs. local_row_id is a run-local row reference, not a persistent document ID.
- Next step
- Inspect the issue/control logs before mapping the actual sender-side transfer files. Import CSV via Excel Data > From Text/CSV > Transform Data; set IDs, hashes and paths to Text. Do not double-click untrusted CSVs or enable formulas/macros/links.
- Check before continuing
- Any skipped/unreadable/changing file is a coverage gap. No claims about deleted files, embedded attachments, alternate streams, cloud versions or access permissions. No repair/delete action. Stop if any path is rejected or changes during capture; do not bypass checks, elevate permissions, install PowerShell or change execution policy as part of this recipe.
Obtain independent receiver evidence
Authorized recipient / records owner · Recipient’s approved local received-file snapshot and actual acknowledgment record
The recipient or authorized IT owner independently runs the same reviewed helper on the actual received files, under their own approved scope, or supplies equivalent already-verified size/SHA256 evidence. Record receipt time, received_by, transfer_id and receipt_ref from the actual transfer system/receipt. Obtain an actual acknowledgment separately. If any is unavailable, stop the complete-transfer verdict and list what is missing.
- Expected output
- Independent receiver manifest and acknowledgment evidence, or explicit acquisition_blocked status.
- Next step
- No hashes are copied from the sender into the receiver table. Do not initiate external contact or upload as part of this recipe.
- Check before continuing
- A successful sender upload or email delivery does not establish received bytes or recipient acknowledgment.
Map the observed records to the starter input
Excel and authorized staff · Separate analysis workbook > Home > Format as Table
Populate sent.csv from the sender snapshot and actual transfer log: transfer_id,file_id,relative_path,size_bytes,sha256,recipient_id,sent_at,source_ref. Populate received.csv independently: transfer_id,file_id,size_bytes,sha256,received_by,received_at,receipt_ref. Populate acknowledgments.csv only from actual recipient acknowledgment. Copy approved_transformations.csv from explicit approval records, including expected_destination_sha256; no inferred transform. Put scope, identity crosswalk, capture times/errors and exclusions into visible Scope. Create named tables for Sent, Received, Acknowledgments and ApprovedTransformations. Put the policy and review scope in visible worksheets or paste them into the next prompt.
- Expected output
- Sent, Received, Acknowledgments and ApprovedTransformations; unacquired receiver evidence blocks completion.
- Next step
- Check the mapping against each original source before using AI.
- Check before continuing
- Aliases and missing policy fields are staff-created; do not relabel a native export as the kit schema. Unknown stays blank/unknown, not false or zero.
Review the bounded evidence with Copilot
Excel Copilot, optional · Approved analysis workbook > Copilot icon at lower right > Chat only
Use Chat only and submit the prompt. Without Copilot: compare independent sizes/hashes by exact approved keys, then check separate acknowledgment evidence.
- Expected output
- Transfer-integrity exceptions and evidence gaps.
- Next step
- Copy the draft exception list to the reviewer; retain row references.
- Check before continuing
- Check every flagged row and the scope. A fluent answer is not evidence of completeness; no automatic workbook or source-system edits.
Approve the review result
Final human reviewResponsible staff reviewer · Reviewed local worksheet
The transfer owner validates independent receiver evidence, every mismatch and actual recipient acknowledgment. Resolve exceptions through the separately authorized transfer process.
- Expected output
- Reviewed integrity finding or transfer-unverified hold.
- Next step
- Any external message, source change, payment or deletion requires its own authorized process.
- Check before continuing
- Do not certify delivery completeness from the sender manifest or an acknowledgment alone.
What you’ll get
transfer-review.csv: transfer_id, file_id, exception, sender_source_ref, receiver_receipt_ref, ack_ref; coverage counts for sent, received, matched, missing and unexpected files; transfer_status. Return transfer_unverified if receiver evidence, count coverage or acknowledgment is missing. Derive all IDs and findings from supplied evidence; do not certify authenticity or legal sufficiency.
Inputs and a sample test Synthetic example · not a measured result
Input files
- sent.csv = transfer_id,file_id,relative_path,size_bytes,sha256,recipient_id,sent_at,source_ref. received.csv = transfer_id,file_id,size_bytes,sha256,received_by,received_at,receipt_ref. acknowledgments.csv = transfer_id,recipient_id,acknowledged_at,ack_ref. approved_transformations.csv = transfer_id,source_file_id,destination_file_id,approved_by,expected_destination_sha256. SHA-256 values must be 64 hex characters; paths are synthetic and non-sensitive.
Synthetic example
Synthetic inputs are included in the starter kit. sent.example.csv received.example.csv acknowledgments.example.csv approved_transformations.example.csv
Expected output
Transfer T1 contains F1 and F2; received has F1 with identical size/hash but lacks F2. Acknowledgment is blank. Expected F1=byte match for supplied evidence, F2=missing recipient-side evidence, T1=acknowledgment missing. Use SHA256('alpha') on both sides for F1 and SHA256('beta') only in the sent row for F2; these are test setup instructions, not executed testing. A mismatched recipient ID must remain an independent exception even with equal bytes.Test a failure
Litigation staff verify receiving evidence and custody records; lawyer decides production sufficiency, preservation and legal consequences. No inference that a link click equals successful receipt or review. This check does not authorize uploading/sending anything.
Try with the sample files
Follow the tool steps above and use the inputs named in each step. Where provided, native-* files are blank scaffolds and NATIVE-INPUT-MAPPING explains their fields. Original examples and the optional full review prompt use a separate prepared-input schema. Keep them separate unless the mapping explicitly connects them. Downloading a kit does not connect accounts or prove the workflow works.
Download inputs and checklist 12 files
Instructions, blank templates and separate synthetic examples; these files do not install an automation. Blank templates still need verified source data.
- Download starter kit All inputs, synthetic examples and review notes in one ZIP. No automation is installed.
- Start here: get the sources and prepare the review Documentation-checked acquisition, explicit manual mapping, exact prompts and human review limits
- sent blank template Sender manifest with exact byte hashes
- sent synthetic example Sender manifest with exact byte hashes
- received blank template Independent recipient manifest; F2 is intentionally absent
- received synthetic example Independent recipient manifest; F2 is intentionally absent
- acknowledgments blank template Explicit acknowledgments; example intentionally contains only the header
- acknowledgments synthetic example Explicit acknowledgments; example intentionally contains only the header
- approved_transformations blank template Only separately approved byte-changing mappings; example has none
- approved_transformations synthetic example Only separately approved byte-changing mappings; example has none
- Setup and fixture review guide Recipe-specific setup, input rules, offline prompt, expected result and boundaries
- Advanced: approved local snapshot inventory helper Read an approved stable local snapshot and write inventory/error outputs outside its root; requires authorized IT review and synthetic validation first
Optional full review prompt for prepared inputs
Prepared-input review prompt with Your firm-approved AI assistant · prepared files
Proposed / not tested · editorial prompt. This prompt uses the original prepared-input schema shown in the sample test. Step prompts may use different tables. Follow NATIVE-INPUT-MAPPING where supplied; do not mix the original examples with native-step inputs without mapping and checking every field.