Chain of Custody Event Log Prompt for Digital Evidence

This prompt is for forensic analysts and evidence management systems that need to convert natural-language descriptions of evidence handling into structured, machine-readable custody records. Use it when you need to produce a tamper-evident log entry with a validated evidence ID, handler identity, a controlled custody action, and an ISO 8601 timestamp. This prompt belongs in a workflow where every evidence transfer, check-in, check-out, or disposal must be documented in a consistent format for downstream ingestion into a Laboratory Information Management System (LIMS), evidence management platform, or audit database. It is not a replacement for a secure chain-of-custody application, but it provides the structured data layer that such systems require.

The ideal user is a forensic analyst, evidence custodian, or system integrator who already has the facts about an evidence event but needs to normalize them into a strict schema. Required context includes a known evidence ID format (e.g., CASE-YYYY-NNNNN or EVD-<GUID>), a controlled vocabulary of custody actions (CHECK_IN, CHECK_OUT, TRANSFER, DISPOSAL, SEALED, UNSEALED), and the handler's verified identity. Without this context, the prompt cannot enforce field-level validation and should not be used. Do not use this prompt to adjudicate chain-of-custody disputes, to reconstruct missing evidence history from memory, or to generate legal opinions about evidence admissibility.

The prompt is designed to be wired into a larger evidence management pipeline. Before calling the model, your application should validate the handler's identity against an active directory or IAM system and confirm that the evidence ID exists in your evidence registry. After the model returns the structured record, your system must validate the output against the same schema, log the raw prompt and completion for audit purposes, and append the record to a write-once, append-only custody log. The model's output is a structured proposal; the system of record is the final authority. In regulated environments, require a human reviewer to confirm the generated record before it is committed to the permanent custody log.

This prompt template is designed to be pasted directly into your system instructions or user message. It instructs the model to extract forensic custody events from unstructured text and produce a single, valid JSON object with no surrounding commentary. The template uses square-bracket placeholders that you must replace with your specific inputs before use. The output schema enforces strict field types, controlled vocabularies for custody actions, and ISO 8601 timestamps, making the output suitable for direct ingestion into evidence management systems or audit databases.

textCopy
You are a forensic evidence custodian assistant. Your task is to extract chain of custody events from the provided narrative and output a single JSON object conforming to the schema below. Do not include any text outside the JSON object.

INPUT NARRATIVE:
[INPUT]

OUTPUT SCHEMA:
{
  "evidence_id": "string (format: EV-XXXX-XXXX where X is alphanumeric, required)",
  "custody_events": [
    {
      "event_id": "string (UUID v4 format, required)",
      "timestamp": "string (ISO 8601 format in UTC, required)",
      "handler": {
        "name": "string (required)",
        "badge_id": "string (required)",
        "role": "string (enum: [\"Forensic Analyst\", \"Evidence Officer\", \"Investigator\", \"Lab Technician\", \"External Custodian\"], required)"
      },
      "action": "string (enum: [\"COLLECTED\", \"TRANSFERRED\", \"CHECKED_OUT\", \"CHECKED_IN\", \"ANALYZED\", \"SEALED\", \"UNSEALED\", \"DISPOSED\"], required)",
      "location": "string (required)",
      "notes": "string (optional, max 500 characters)",
      "integrity_check": {
        "hash_algorithm": "string (enum: [\"SHA-256\", \"SHA-512\", \"MD5\"], required if action is CHECKED_IN or CHECKED_OUT)",
        "hash_value": "string (required if hash_algorithm is present)"
      }
    }
  ],
  "chain_of_custody_complete": "boolean (required, true if no gaps in custody timeline)",
  "extraction_confidence": "number (0.0 to 1.0, required)"
}

CONSTRAINTS:
- All timestamps must be in ISO 8601 UTC format (e.g., 2024-01-15T14:30:00Z).
- Custody events must be ordered chronologically by timestamp.
- If the narrative contains ambiguous or conflicting information, set extraction_confidence below 0.8 and note discrepancies in the event notes.
- If no evidence ID matching the format EV-XXXX-XXXX is found, set evidence_id to null and extraction_confidence to 0.0.
- Do not fabricate events. Only extract what is explicitly stated or directly implied by the narrative.
- If the narrative describes a transfer between two handlers, create two events: one CHECKED_OUT by the sender and one CHECKED_IN by the receiver.

To adapt this template, replace the [INPUT] placeholder with the forensic narrative text. For production use, consider injecting additional context via a [CONTEXT] placeholder that includes known evidence metadata, handler rosters, or facility locations to improve extraction accuracy. The controlled vocabularies for action and handler.role should be customized to match your organization's standard operating procedures. If your evidence management system uses a different evidence ID format, update the regex constraint in the prompt and the downstream validation logic accordingly. Always pair this prompt with automated JSON Schema validation and a human review step for events where extraction_confidence falls below 0.9 or where chain_of_custody_complete is false.

This prompt is designed to be called from a backend service or an API endpoint that receives raw custody notes from a forensic analyst. The application layer should first authenticate the handler and resolve their identity before injecting it into the prompt's [HANDLER_ID] placeholder. The [EVIDENCE_ID] should be validated against your evidence management system's identifier format (e.g., a UUID or a barcode pattern) before the prompt is assembled. Do not rely on the model to enforce evidence ID uniqueness; that constraint belongs in your database.

Wrap the model call in a validation harness that checks the output JSON against a strict schema before the record is accepted. Required fields include evidence_id, handler_id, action, and timestamp. The action field must be validated against a controlled vocabulary (e.g., COLLECTED, TRANSFERRED, ANALYZED, STORED, DISPOSED). If the model returns an action outside this vocabulary, reject the output and retry with a stronger constraint in the prompt, or escalate for human review. The timestamp must parse as ISO 8601 and must not be in the future. Log every validation failure with the raw model output and the validator error for debugging.

For high-stakes forensic workflows, implement a human-in-the-loop approval step before the custody record is committed to the evidence management system. Present the generated log entry alongside the analyst's original notes in a review UI. The reviewer should confirm that the action type, handler identity, and evidence ID are correct. Once approved, write the record to an append-only audit log with a server-generated entry_id and created_at timestamp. Never allow the model to generate the primary key or the server-side timestamp. For model selection, prefer a model with strong JSON mode support and low latency; structured output features (like GPT-4o's response_format or Claude's tool use) reduce parsing errors. Implement retries with exponential backoff for transient failures, but cap at three attempts before surfacing the raw notes to the analyst for manual entry.