Chain of Custody Log Drafter

intent

use this skill when a digital-forensic examiner, DFIR responder, or e-discovery custodian needs to draft a court-admissible chain-of-custody record aligned to NIST SP 800-86 and ISO/IEC 27037. the skill converts case facts, evidence-item details, and acquisition data into a DRAFT CoC log with hash-verification gates, acquisition worksheet, and examiner-action log for examiner and counsel review. the output enforces evidence-integrity discipline and flags missing metadata without inventing data or authenticating evidence. use this skill when evidence handling must remain transparent, auditable, and admissible under forensic best-practice standards.

inputs

user context:

• role of the person initiating the skill (examiner of record, DFIR responder, e-discovery custodian, investigator, counsel, internal-investigation lead)
• engagement type (law enforcement, civil litigation under FRCP, internal investigation, regulatory inquiry, incident response, employee misconduct, criminal defense)
• case identifier and matter name
• litigation hold or preservation notice details (name, date, scope) if applicable

evidence-handling framework and authority:

• preferred evidence-handling framework (NIST SP 800-86, ISO/IEC 27037, ACPO Good Practice Guide, RFC 3227, jurisdiction-specific rules); default is NIST SP 800-86 + ISO/IEC 27037
• written search authority (warrant, court order, consent, employer policy, MOU, or none) with reference and date
• examiner-of-record identity (role, name, credentials such as GCFA, EnCE, CCE, CFCE, or internal cert ID)

evidence-item characterization (per item):

• evidence ID (zero-padded, case-prefixed, e.g., CASE-2026-0042-E001)
• device class (laptop, desktop, server, mobile, removable media, network capture, cloud export, paper, other)
• make, model, serial number, IMEI, MEID, ICCID (where applicable), asset tag, distinguishing marks
• physical condition on receipt (powered state, screen lock state, visible damage, tamper-evident seal status, packaging)
• location of seizure or collection (address, room, position, time zone)
• custodian (person or system from which item was taken)
• seizing or collecting officer, responder role, date/time (ISO 8601 with time zone), method
• photographs taken on collection (yes/no; storage location if yes)

acquisition data (per evidence item):

• acquisition type (forensic image in E01, Ex01, AFF4, dd, DMG format; live acquisition or triage; logical copy; selective collection; memory capture; cloud-API export; network capture in pcap; photograph only)
• acquisition tool name and version (e.g., Cellebrite UFED Pro 7.x, Magnet AXIOM Process 8.x, EnCase Imager, FTK Imager, dd, GrayKey, Velociraptor, KAPE)
• write-blocker or isolation control (hardware model and firmware such as Tableau T8u for storage; faraday bag and airplane mode for mobile; read-only mode for cloud-API; or explicit note if live system)
• source identifier (interface, drive, partition, slot, account, mailbox)
• output destination (target drive serial, examiner workstation, evidence locker tag)
• acquisition start time, end time (ISO 8601 with time zone), duration, sector count, bytes acquired, errors encountered
• hash values at acquisition (source-hash, image-hash, verification-hash; minimum two algorithms such as SHA-256 plus SHA-1 or MD5)
• verification result (Pass, Fail, or Partial with reason)
• acquisition examiner role, name, and credential reference

transfer and custody events (per event):

• date and time (ISO 8601 with time zone)
• from custodian (role, name) and to custodian (role, name)
• action type (Seized, Bagged & sealed, Transported, Received at lab, Stored, Checked out for examination, Imaged, Verified, Duplicated for working copy, Checked back in, Transferred to counsel, Returned to owner, Disposed)
• method (in-person, courier with tracking number, encrypted-drive transfer, secure-FTP with checksum)
• seal status before and after (intact, broken, re-sealed with seal ID)
• hash verification at event (before and after where applicable)
• notes on anomalies, environmental conditions, deviations

working-copy and retention details:

• number of working copies, their hash values, storage locations
• destruction or retention policy
• encryption at rest (algorithm, key custodian, key escrow)
• retention schedule (legal-hold duration, statutory minimum, contractual retention, or release condition)

external connections: no external API calls required. all case data remains confidential on the user's system. if the user integrates with case-management or evidence-locker systems (Relativity, Vault Dynamics, Nuix, etc.), those tools must already be configured locally; this skill does not initiate external uploads or calls.

procedure

step 1: intake and authority context

input: user role, engagement type, case identifier, matter name, search authority, litigation hold details

process: ask one question at a time; wait for answer before proceeding.

1. request user role and engagement type
2. request case identifier, matter name, litigation hold or preservation notice (name, date)
3. request evidence-handling framework; default to NIST SP 800-86 + ISO/IEC 27037 if user does not know
4. request written search authority (warrant, court order, consent, employer policy, MOU, none); capture scope and date

output: engagement context summary with role, case ID, framework, authority reference, legal hold notation

step 2: evidence-item characterization

input: for each evidence item, user provides ID, description, physical state, seizure location, custodian, seizing officer, photographs

process: for each evidence item, ask one question at a time in this order:

1. evidence ID (zero-padded, case-prefixed)
2. device class, make, model, serial, IMEI, asset tag
3. powered state, screen lock state, visible damage, tamper seal, packaging
4. seizure location (address, room, time zone)
5. custodian (person or system name)
6. seizing officer role, date/time (ISO 8601), method
7. photographs taken (yes/no; storage location if yes)

repeat for each additional evidence item until user indicates no more items.

output: evidence-item register table with ID, description, serial, powered state, tamper seal, custodian, seizing officer, location, timestamp

step 3: acquisition method and verification

input: for each evidence item, user provides acquisition type, tool, write-blocker, source/output identifiers, hashes, verification result, examiner

process: for each evidence item, ask one question at a time in this order:

1. acquisition type (forensic image format, live acquisition, logical copy, selective collection, memory capture, cloud export, network capture, photograph only)
2. tool name and version (mandatory; tool name alone is insufficient)
3. write-blocker or isolation control used (hardware model, firmware, method, or reason if not feasible)
4. source identifier (interface, drive, partition, slot, account)
5. output destination (target drive serial, workstation, locker tag)
6. acquisition start time, end time (ISO 8601), duration
7. sector count, bytes acquired, errors encountered
8. source hash value (algorithm and hash string)
9. image hash value (algorithm and hash string)
10. verification hash value (algorithm and hash string)
11. verification result (Pass, Fail, or Partial with reason)
12. acquisition examiner role, name, credential reference

if any hash is missing, flag acquisition as Unverified , acquisition hash required and refuse to mark evidence as preserved. do not proceed to CoC transfers until hashes are supplied.

output: acquisition worksheet table with evidence ID, acquisition type, tool+version, write-blocker, source, destination, timestamps, hashes, verification result, examiner

step 4: transfer and custody events

input: for each custody transfer, user provides timestamp, from-to roles and names, action, method, seal status, hash verification, anomalies

process: for each transfer event, ask one question at a time in this order:

1. event date and time (ISO 8601 with time zone)
2. from custodian (role and name)
3. to custodian (role and name)
4. action (from predefined list: Seized, Bagged & sealed, Transported, Received at lab, Stored, Checked out for examination, Imaged, Verified, Duplicated for working copy, Checked back in, Transferred to counsel, Returned to owner, Disposed)
5. method (in-person, courier with tracking, encrypted drive, secure FTP)
6. seal status before (intact, broken, re-sealed with seal ID)
7. seal status after (intact, broken, re-sealed with seal ID)
8. hash verification (which hash algorithm, source value, current value, result: Pass, Fail, or Partial)
9. notes (anomalies, environmental conditions, deviations)

repeat for each transfer until user indicates no more events. ensure transfers form a chronological sequence; flag gaps explicitly.

output: chain-of-custody transfer log table with row number, timestamp, from-role/name, to-role/name, action, method, seal before/after, hash check, notes, signature block (unsigned)

step 5: examiner-action log for working copies

input: for each examination operation on a working copy, user provides action ID, timestamp, examiner, tool+version, working-copy source, operation type, output artefact, notes

process: for each examination action, ask one question at a time in this order:

1. action ID and timestamp (ISO 8601)
2. examiner role and name
3. tool name and version (one tool per row; mandatory)
4. working-copy identifier (never original)
5. operation type (mount, parse, carve, decrypt, keyword search, hash-set comparison, timeline build, export)
6. output artefact reference (report ID, export path, redaction state)
7. notes (tool warnings, errors, unsupported file types)

repeat until user indicates no more actions. maintain append-only, timestamped order.

output: examiner-action log table with row number, timestamp, examiner, tool+version, working-copy ID, operation, artefact, notes

step 6: working-copy and original handling

input: user confirms number of working copies, their hashes, storage locations, encryption, retention policy

process: ask one question at a time:

1. number of working copies created from acquisition image
2. for each working copy: hash value (algorithm and string), storage location, encryption algorithm, key custodian
3. working-copy retention schedule (legal-hold duration, statutory minimum, contractual, or release condition)
4. original storage location, access control, environmental conditions
5. original retention schedule and release condition

output: working-copy register table with working-copy ID, source acquisition image, SHA-256, storage location, encryption, retention until; original-evidence handling section with storage, access control, retention, release

step 7: assumption summary and confirmation

input: user review of all captured data

process:

1. restate all facts captured in intake, characterization, acquisition, transfer, examiner-action, and working-copy sections
2. tag each fact as Confirmed (source: …), Assumed (basis: …), Reconstructed (basis: …), or Unknown , open question
3. display evidence-item table, acquisition table, transfer-event table, examiner-action log, working-copy register
4. ask: "does this match your understanding? reply yes to draft the CoC record, or correct any line."

output: assumption summary with status tags; evidence, acquisition, transfer, and examiner-action tables; open-questions list

decision: if user replies "yes", proceed to step 8. if user corrects a line, update the relevant section and re-display the assumption summary. repeat until user confirms.

step 8: draft the CoC record

input: confirmed assumption summary from step 7

process:

1. render output in the format specified under output contract
2. use section structure: evidence-item register, acquisition worksheet, chain-of-custody transfer log, examiner-action log, working-copy register, original-evidence handling, evidence-integrity verification, evidence matrix, unresolved open questions
3. carry source attribution for every entry (e.g., "user provided", "reconstructed from …", "missing from user input")
4. render unsourced fields as Unknown , required for admissibility and flag in unresolved section
5. label reconstructed entries as Reconstructed (basis: …); do not present reconstructed entries as original entries
6. include DRAFT header and footer with examiner-of-record review notice; leave signature blocks unsigned

output: complete DRAFT CoC record in markdown or structured text format

step 9: self-check against rubric

input: completed DRAFT CoC record

process: validate each checklist item:

• every evidence item has ID, description, serial/IMEI/asset (or Unknown), custodian, seizing officer, location, ISO 8601 timestamp
• every acquisition row carries tool name and version, write-blocker/isolation, source hash, image hash, verification hash with Pass/Fail/Partial
• transfers form unbroken sequence; gaps explicitly flagged as Unknown
• reconstructed entries labelled; no reconstructed entry presented as original
• examination performed only on working copies; working-copy hashes match acquisition hashes
• tool warnings, errors, unsupported file types recorded in examiner-action log
• legal hold/preservation notice and search authority recorded
• working-copy encryption (algorithm + key custodian) recorded
• retention/release condition recorded for original and working copies
• no hash, timestamp, serial number, tool version, custodian name invented
• DRAFT label and examiner-of-record review notice present; signature blocks unsigned

output: list of failed checklist items (if any) with offer to correct before finalizing; success message if all items pass

decision points

if user does not know the evidence-handling framework: default to NIST SP 800-86 + ISO/IEC 27037. flag the assumption in the assumption summary and offer to switch frameworks if the user learns jurisdiction-specific or corporate requirements later.

if user cannot supply a written search authority: record the absence explicitly as No written authority on file. flag this as a remediation item in the unresolved section; counsel must advise whether the engagement can proceed.

if user supplies an estimated or reconstructed timestamp (e.g., "approximately 3 PM on the 22nd"): do not backfill the timestamp as original. instead, record it as Reconstructed (basis: user estimate from context) and add a remediation note flagging it for the examiner. do not insert it into the transfer log as a precise ISO 8601 entry.

if acquisition hashes are missing or mismatched: refuse to mark the evidence item as preserved. flag it as Unverified , acquisition hash required and stop processing that evidence item until hashes are supplied. do not proceed to working-copy or examiner-action steps for that item.

if working-copy hashes do not match acquisition image hashes: flag the mismatch in the evidence-integrity verification section and refuse to mark the working copy as verified. do not proceed with examination entries that reference an unverified working copy.

if examiner performs analysis on the original instead of a working copy: flag this as a critical violation in the examiner-action log. add a note: INTEGRITY VIOLATION , examination performed on original evidence, not working copy. chain compromised.

if user is not the examiner of record: ask them to identify the examiner of record and capture that role explicitly. do not proceed until the examiner-of-record identity is confirmed. the CoC entries must reference the responsible person, not the drafting agent or a generic team.

if user asks to invent a missing hash, timestamp, serial number, or tool version: refuse explicitly. explain that invented data renders the CoC inadmissible and compromises chain integrity. offer to flag the field as Unknown and mark it as a remediation item for the examiner.

if user asks to recommend destruction, sanitization, wiping, factory-reset, decryption-key disclosure, or chain-breaking actions: refuse and surface the legal-hold and preservation obligation. provide the user with a template language for their counsel or legal team if needed.

if user asks to assert admissibility, evidentiary weight, or sufficiency of the CoC record: decline. explain that admissibility is a matter for counsel and the court, not for the drafting agent. your role is to produce transparent, complete documentation; counsel determines what is sufficient.

if case data (hashes, PII, exhibit content) is offered for transmission to external services: refuse. instruct the user to keep all case data local and confidential.

if user expresses dissatisfaction or the skill does not cover their situation: append this message: "this skill may not fully cover your situation. suggestions for improvement are welcome , open an issue or PR."

output contract

format: markdown or structured text document

file location: user's local system; no external upload

sections (in order):

1. DRAFT header and metadata:

   • DRAFT , EXAMINER OF RECORD MUST REVIEW AND SIGN
   • case ID, matter name, framework, engagement type, search authority, legal hold details
   • examiner-of-record identity (role, name, credential)
   • drafted date and drafted-by role

2. evidence-item register: table with columns: Evidence ID, Description, Serial/IMEI/Asset, Powered state, Tamper seal, Seized from custodian, Seized by (role, name), Location, Date/time (ISO 8601)

3. acquisition worksheet: table with columns: Evidence ID, Acquisition type, Tool+version, Write-blocker/isolation, Source identifier, Output destination, Start/end (ISO 8601), Sectors/bytes, SHA-256 source, SHA-256 image, SHA-256 verification, Result (Pass/Fail/Partial), Examiner role

4. chain-of-custody transfer log: table with columns: row number, Date/time (ISO 8601), From (role, name), To (role, name), Action, Method