Checkpoint Integrity Verification Prompt

This prompt is built for agent runtime developers and operators who must verify that a saved checkpoint has not been corrupted or tampered with before resuming execution. The core job-to-be-done is automated integrity gating: you have a serialized agent state stored on disk, in a database, or in an object store, and you need a machine-verifiable guarantee that the state is safe to load back into an active agent loop. The ideal user is an engineer integrating this verification step into a checkpoint loader, a state hydration pipeline, or a pre-resumption validation hook. Required context includes the raw checkpoint payload, an optional cryptographic hash for tamper detection, and a formal schema definition that describes the expected shape of valid state. Without all three, the prompt cannot produce a trustworthy integrity report.

Use this prompt when your system must prevent silent state corruption from propagating into live agent execution. Common triggers include: resuming a long-running workflow after a deployment, reloading state after a model switch, recovering from a storage layer failure, or rehydrating a checkpoint that passed through an untrusted serialization boundary. The prompt is designed to catch three classes of problems: hash mismatches indicating tampering or bit rot, schema violations where required fields are missing or types are wrong, and logical inconsistencies such as a completed step count exceeding the total planned steps. In high-risk environments, pair this prompt's output with a hard gate in your application code—if the integrity report flags any CRITICAL or HIGH severity issues, the system should refuse to load the checkpoint and escalate for human review rather than attempting automatic repair.

Do not use this prompt for creating checkpoints, deciding when to save them, or compressing state for token budget reasons. Those workflows belong to the Agent State Snapshot Prompt Template, Checkpoint Frequency Decision Prompt, or Checkpoint Compression for Token Budget Prompt respectively. Also avoid using this prompt as a substitute for cryptographic verification at the storage layer—the optional hash check here is a defense-in-depth measure, not a replacement for signed payloads or authenticated storage. Finally, this prompt is not designed for reconstructing corrupted state; if integrity checks fail, use the Agent Context Reconstruction Prompt After Failure to rebuild state from logs and partial evidence rather than attempting to repair the damaged checkpoint directly.

This template provides a complete prompt for verifying that a saved agent checkpoint has not been corrupted, tampered with, or logically invalidated before resuming execution. The prompt performs three verification layers: cryptographic hash validation, schema compliance checking, and logical consistency analysis. Use this when your agent runtime must confirm checkpoint integrity after storage, transfer, model switches, or recovery from interruption. Do not use this prompt for lightweight workflows where the cost of replaying a few steps is lower than the verification overhead, or when checkpoints are stored in tamper-proof systems with built-in integrity guarantees.

textCopy
You are a checkpoint integrity verification system. Your job is to validate that an agent checkpoint is complete, uncorrupted, and logically consistent before execution resumes. You must produce a structured integrity report with pass/fail status for each verification layer and specific remediation guidance for any failures.

## INPUT

[CHECKPOINT_DATA]

## VERIFICATION LAYERS

### Layer 1: Cryptographic Integrity
- If a [EXPECTED_HASH] is provided, compute the hash of [CHECKPOINT_DATA] using [HASH_ALGORITHM] and compare.
- If no hash is provided, skip this layer and note that cryptographic verification was not performed.
- Report: hash_match (boolean), computed_hash (string), expected_hash (string if provided).

### Layer 2: Schema Compliance
- Validate that [CHECKPOINT_DATA] contains all required fields per [CHECKPOINT_SCHEMA]:
  - Required top-level fields: checkpoint_id, timestamp, agent_id, plan_state, completed_steps, pending_steps, tool_outputs, context_summary
  - Each completed_step must have: step_id, action, status, output, timestamp
  - Each pending_step must have: step_id, action, dependencies, priority
  - tool_outputs must be a valid array of {tool_name, call_id, output, timestamp} objects
- Report: schema_valid (boolean), missing_fields (array), type_mismatches (array).

### Layer 3: Logical Consistency
- Verify that completed_steps and pending_steps are consistent with plan_state.
- Check that no step appears in both completed_steps and pending_steps.
- Verify that all dependency references in pending_steps resolve to existing step_ids in completed_steps or pending_steps.
- Check that timestamps are monotonically increasing where expected.
- Verify that tool_outputs reference valid tool calls from completed_steps.
- Flag any orphaned references, circular dependencies, or contradictory state.
- Report: logically_consistent (boolean), inconsistencies (array of {type, description, location}).

## OUTPUT FORMAT

Return a JSON object with this exact structure:
{
  "integrity_report": {
    "checkpoint_id": "string",
    "verification_timestamp": "ISO8601",
    "overall_status": "PASS" | "FAIL" | "PARTIAL",
    "cryptographic_verification": {
      "performed": boolean,
      "hash_match": boolean | null,
      "computed_hash": "string",
      "expected_hash": "string | null",
      "algorithm": "string"
    },
    "schema_verification": {
      "schema_valid": boolean,
      "missing_fields": ["string"],
      "type_mismatches": [{"field": "string", "expected": "string", "actual": "string"}]
    },
    "logical_verification": {
      "logically_consistent": boolean,
      "inconsistencies": [{"type": "string", "description": "string", "location": "string"}]
    },
    "remediation": {
      "resumable": boolean,
      "blocking_issues": ["string"],
      "warnings": ["string"],
      "recommended_actions": ["string"]
    }
  }
}

## CONSTRAINTS

- Do not modify or repair the checkpoint data. Only report findings.
- If cryptographic verification fails, set overall_status to FAIL regardless of other layers.
- If schema verification fails with missing required fields, set overall_status to FAIL.
- If only logical inconsistencies are found with no missing data, set overall_status to PARTIAL and flag specific inconsistencies.
- For any FAIL or PARTIAL status, provide specific, actionable remediation steps.
- If [RISK_LEVEL] is "HIGH", require explicit human approval before marking resumable as true.
- Flag any timestamp anomalies that could indicate tampering or clock skew.
- If tool_outputs reference tools not in [AVAILABLE_TOOLS], flag as a compatibility warning.

Adaptation guidance: Replace [CHECKPOINT_DATA] with the serialized checkpoint payload. Provide [EXPECTED_HASH] and [HASH_ALGORITHM] if your system stores cryptographic hashes alongside checkpoints; otherwise the verification layer will self-skip. Define [CHECKPOINT_SCHEMA] to match your actual checkpoint structure—the schema shown is a starting point. Set [RISK_LEVEL] to "HIGH" for production financial, healthcare, or safety-critical workflows to enforce human approval gates. Add [AVAILABLE_TOOLS] as a list of valid tool names to detect tool compatibility issues after model switches. Critical: Always validate the output JSON against the expected schema before acting on the integrity report. A malformed report should be treated as a verification failure and trigger a retry or escalation.

Next steps after verification: If the report returns overall_status: PASS, proceed with resumption using the validated checkpoint. If PARTIAL, review the specific inconsistencies and decide whether to resume with warnings or request a reconstructed checkpoint. If FAIL, do not resume—trigger your checkpoint reconstruction or replay workflow instead. Wire this prompt into your agent runtime's pre-resumption hook so no checkpoint is loaded without verification. For high-risk domains, route all non-PASS reports to a human review queue before any automated resumption decision.

The Checkpoint Integrity Verification Prompt is not a standalone utility; it is a gate that must be integrated into the agent's state-loading lifecycle. Before any agent resumes execution from a saved checkpoint, the runtime should call this prompt with the raw checkpoint data, the expected schema, and any stored cryptographic hashes. The prompt's output—a structured integrity report—should be parsed programmatically. If the report's integrity_pass field is false, the runtime must block resumption and fall back to the last known-good checkpoint or escalate for human review. This prevents silent corruption from propagating into downstream agent actions.

To implement this, wrap the prompt call in a validation harness that performs three checks before the agent runtime ever sees the checkpoint. First, verify that the model's output conforms to the expected integrity report schema using a strict JSON validator. If the model fails to produce valid JSON, retry once with a simplified schema and a stronger constraint instruction. Second, independently recompute any provided hashes (e.g., SHA-256 of the serialized state) and compare them against the hash_match field in the report. Do not trust the model's hash comparison alone; the harness must perform its own cryptographic verification. Third, log the full integrity report, the raw checkpoint, and the model's raw response to an append-only audit store. This log is essential for debugging false positives, diagnosing corruption sources, and providing evidence for governance reviews.

Model choice matters here. Use a model with strong instruction-following and structured output capabilities, such as Claude 3.5 Sonnet or GPT-4o, with response_format set to json_object and the integrity report schema provided as the JSON Schema. Set temperature to 0 to minimize variance in verification logic. For high-security environments where the checkpoint contains sensitive data, run this prompt in a local or private deployment; never send raw checkpoint state to an external API without redacting PII and secrets first. If the checkpoint is too large for a single context window, pre-process it by extracting only the schema-defined fields required for verification and computing hashes externally before calling the prompt. The prompt should receive a digest of the state, not necessarily the full payload.

Common failure modes in the harness include: the model hallucinating a passing result when corruption exists (false negative), the model flagging a valid checkpoint due to schema misunderstanding (false positive), and the harness itself failing to parse the model's output. Mitigate false negatives by combining model-based verification with deterministic schema and hash checks in the harness. Mitigate false positives by maintaining a regression suite of known-valid checkpoints and running this prompt against them on every prompt or model version change. If the harness cannot parse the output after one retry, treat it as an integrity failure and block resumption. Never default to allowing resumption when the verification pipeline itself is uncertain.