START WITH THE PRODUCT STEPS
Read START-HERE.txt first. It states the actual source acquisition, access/privacy limits, manual field mapping and exact next prompt. The original file templates and synthetic examples below are supporting review aids. Some paths need separately supplied documents or source text; a blank worksheet is not a native export or completed integration.

Q08 - Compare sent and received evidence-transfer manifests

Status: Proposed / not tested

WHAT THIS KIT CONTAINS
Exact input scaffolds and synthetic examples for an offline pilot. Header, JSON-shape and fixture-consistency checks validate these files only; they do not test an assistant, product integration, legal decision, PDF inspection or live workflow.

PREREQUISITES
1. Lawyer-approved production manifest and recipients, independently generated sender and recipient-side hashes on the same intended bytes, transfer timestamp, recipient acknowledgment metadata. If destination data is unavailable, return unverified; do not substitute a local reread for receiver evidence. Preserve containers and native files; approved transformations need their own mapped manifest, not a false corruption alert.

SETUP
1. Use the separate synthetic example inputs first. Fill a copy of the blank template or input checklist for your own preparation; do not mix fixture information with real records.
2. F1 uses SHA-256 of the exact UTF-8 bytes alpha (5 bytes, no newline); F2 uses beta (4 bytes, no newline). Do not hash these CSV files and expect those values.
3. Negative control: change received_by from P1 to P2. Keep recipient mismatch even while F1 bytes still match.
4. Preserve exact CSV headers. CSV templates contain only a header row. Import ID, hash, page-label and timestamp columns as text; inspect leading zeros and do not enable formulas from untrusted input.
5. Give only the selected synthetic input sections/files and the prompt below to an existing firm-approved private workspace, or perform the clerical comparison manually. Keep expected-result notes separate from the input. For planning checklists, leave unknown requirements explicit instead of inventing them.
6. Compare the draft output with the expected fixture result. A reviewer checks original evidence and all exceptions before any separately approved action. Retain the version, scope and source references with the review.

INPUT RULES
Join exact transfer_id + file_id. sha256 and expected_destination_sha256 must be 64 hexadecimal characters. size_bytes is a nonnegative integer. ISO timestamps include timezones. Destination evidence must be independently supplied. A blank acknowledgments table means no acknowledgment evidence, not receipt confirmation.

FILES
- sent.template.csv: Sender manifest with exact byte hashes
- sent.example.csv: Sender manifest with exact byte hashes
- received.template.csv: Independent recipient manifest; F2 is intentionally absent
- received.example.csv: Independent recipient manifest; F2 is intentionally absent
- acknowledgments.template.csv: Explicit acknowledgments; example intentionally contains only the header
- acknowledgments.example.csv: Explicit acknowledgments; example intentionally contains only the header
- approved_transformations.template.csv: Only separately approved byte-changing mappings; example has none
- approved_transformations.example.csv: Only separately approved byte-changing mappings; example has none

COPYABLE OFFLINE PROMPT
Compare these synthetic sent and received manifests by exact transfer_id+file_id. Report missing destination files, unexpected destination files, size/hash differences, recipient mismatches, missing acknowledgment and duplicate IDs. Validate hash format; do not calculate or invent a destination hash. Apply only explicit approved transformation mappings and keep them visible. Return transfer_id,file_id,exception,sender_source_ref,receiver_receipt_ref,ack_ref and coverage counts. Return transfer_unverified if receiver evidence, count coverage or acknowledgment is missing. Do not delete, deduplicate, rename, strip metadata, resend, contact recipients or certify authenticity, valid service or a legally sufficient chain of custody.

INPUTS
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.

OUTPUT
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.

Use only these synthetic or firm-approved inputs and preserve source row/page IDs. Keep missing or conflicting evidence unresolved. Return a draft for the named reviewer. Do not send messages, connect accounts, change records or permissions, move money, or make legal decisions. Keep source files unchanged. List missing prerequisites before continuing.

EXPECTED SYNTHETIC FIXTURE RESULT
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.

LIMITS
- 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.
- Synthetic data only in the delivered files. No credentials, real client records, API connection or Make blueprint is included. The advanced local snapshot helper was statically reviewed, not runtime-tested; authorized IT review and synthetic validation are required before use.
- Real use requires firm-approved access, confidentiality, processing terms, retention, product access and reviewer authority. Pseudonymous IDs alone do not anonymize real records.