OpenCheckpoint Specification v0.1

Status: Draft. This version is open for review and may change incompatibly before 1.0.

Machine-readable schema: spec/schema/v0.1/checkpoint.schema.json (JSON Schema Draft 2020-12). Where the schema and this document disagree, this document governs, and the disagreement is a defect to be reported.

1. Introduction

An AI-assisted task often outlives the session, agent, model, or application that started it. When work moves, the usual options are to replay the whole conversation, which is expensive, runtime-specific, and often impossible across vendors, or to write a prose summary, which loses provenance and blurs what was decided with what was guessed.

OpenCheckpoint defines a checkpoint: a JSON document that records the state of the work at a well-defined boundary. A checkpoint says what the task is, what has been done, what is known and how it is known, what was decided and by whom, which resources and application objects are involved, which operations are unfinished, and what must be checked before anyone continues.

A different agent, runtime, or person can read a checkpoint, check it, and act on it with their own tools and their own permissions. A checkpoint is not a transcript, a model’s internal state, a memory store (§1.3), or a grant of authority.

1.1 Goals

Let a consumer understand the objective, the progress, the evidence, the decisions, the open questions, the pending operations, and the next steps of a task without the original conversation.
Keep the provenance of every claim, so instructions, decisions, observations, hypotheses, and third-party content stay distinguishable through capture, transfer, and compaction.
Make unsafe continuation detectable: unknown side effects, unverified approvals, stale evidence, and missing capabilities are explicit.
Be independent of model, provider, runtime, framework, language, application, and domain.

1.2 Non-goals

Version 0.1 does not standardize model KV caches or hidden model state; private chain-of-thought; prompt formats; full conversation transcripts; long-term memory; in-flight process migration; distributed transaction recovery; credentials or authentication tokens; transfer of authorization; complete UI document models; or runtime internals. A checkpoint can reference a transcript or session log kept elsewhere (§5.2), but it does not contain or replace one.

1.3 Checkpoints and memory

A checkpoint is not memory, and an implementation keeps the two separate.

Scope. A checkpoint covers one task. Memory covers what an assistant retains about a user, project, or domain across many tasks.
Shape. A checkpoint is a snapshot of state at a boundary, with a capture time. Memory accumulates facts and preferences over time.
Use. A checkpoint is read whole, at a handoff. Memory is retrieved piecemeal, by relevance, whenever it seems useful.
Lifetime. A checkpoint is superseded by the next checkpoint and finished when the task ends. Memory persists until it is edited or forgotten.
What it carries. A checkpoint carries what memory usually lacks: the provenance and verification of each statement, evidence that may have gone stale, pending side effects, and what to check before continuing.

The two meet at the edges. A producer may draw on memory when it writes a checkpoint, and a consumer may save lessons from a finished task to memory. Both are outside this specification. A checkpoint SHOULD NOT be used as a long-lived store that is updated across tasks; when the same starting state is reused over time, it SHOULD be captured afresh, so its capture time and verification states stay true (§10.4).

2. Conventions and terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 [RFC 2119] [RFC 8174] when, and only when, they appear in all capitals, as shown here.

Checkpoint: a JSON document that conforms to this specification.
Producer: software that creates a checkpoint.
Consumer: software that reads a checkpoint, whether to display, transform, or continue it.
Destination: a consumer that intends to continue the task.
Source: the system whose work the checkpoint records.
Boundary: a point in the work at which no operation is mid-write from the producer’s point of view; anything started and not confirmed is recorded as uncertain (§6.6).
Local object: an object in the document that carries an id and can be referenced from elsewhere in the same document (§4.1).
System of record: the system that authoritatively holds a resource or decision, such as a repository host, a ticketing system, or an ERP.

3. Document format

A checkpoint is a single JSON object [RFC 8259] encoded as UTF-8. It MUST also be an I-JSON message [RFC 7493]: no duplicate member names, no unpaired surrogates, and numbers within IEEE 754 double precision.

The proposed media type is application/vnd.opencheckpoint+json and the RECOMMENDED file extension is .ocp.json. Neither is registered.

Producers SHOULD keep checkpoints small enough to load whole into a model’s context alongside the destination’s own instructions. Large content (logs, datasets, tool output, documents) belongs in resources that the checkpoint references (§6.4), not inline.

4. Common conventions

4.1 Identifiers and references

id at the top level identifies the checkpoint globally. It MUST be unique across all checkpoints the producer emits and SHOULD be a urn:uuid: URN with a UUID [RFC 9562]. Version 7 UUIDs are RECOMMENDED because they sort by creation time.
Every local object has an id matching ^[A-Za-z0-9][A-Za-z0-9._:-]{0,127}$. Local ids MUST be unique across the whole document, not merely within one array. One namespace keeps references unambiguous: blocked_by can name a statement, an operation, a resource, or a requirement without a type tag.
A field that references a local object holds its local id. Every reference MUST resolve to a local object of an allowed type (§8.2, OCP-S002 and OCP-S003).
Two reference fields accept any local object. refs appears on progress.focus, next steps, requirements, preconditions, stop conditions, and recovery steps, and names the objects that entry concerns. affected appears on a derivation transformation and names the objects that carry the condensed or rewritten content.
Local ids have no meaning outside the document. A consumer that derives a new checkpoint SHOULD keep local ids stable when it carries an object forward, so lineage can be traced.

4.2 Timestamps

Every timestamp is an RFC 3339 date-time with an explicit offset (Z or ±hh:mm). Timestamps that record a past event (completed_at, recorded_at, checked_at, observed_at, requested_at, last_attempt_at, decided_at) MUST NOT be later than the checkpoint’s created_at. expires_at MAY be later.

4.3 Text

Text fields are plain Unicode text for people and models to read. Consumers MUST NOT interpret any text field as markup, code, or instructions to execute. §10 gives the reasons.

4.4 Defaults and absent fields

An absent optional field means “not recorded”, not “false” or “none”. The only defaulted field is statement.status, which defaults to active. Consumers MUST NOT add defaulted values when they re-serialize a document they did not otherwise change.

5. Versioning and compatibility

5.1 The version field

opencheckpoint holds the specification version as MAJOR.MINOR. This document defines "0.1".

Before 1.0, any minor version MAY change the format incompatibly. A consumer MUST reject a 0.x document whose version it does not implement, and MUST NOT report such a document as valid.
From 1.0, minor versions will only add optional fields, enum values in fields documented as extensible, and new semantic warnings. A consumer that implements 1.m and receives 1.n with n > m MAY process it, MUST preserve fields it does not recognize when re-serializing, and MUST report that it processed the document at reduced understanding. A consumer MUST reject a document with an unknown major version.

Each published version has an immutable schema at a stable URL. Fixing a defect in a published schema produces a new version, not an edit.

5.2 Relationship to session history

source.session_refs points into session or task records kept by other protocols: an A2A contextId or task id, an ACP session id, an Agent Session Protocol session and event id, an Open Responses response id, or a runtime’s own thread id. protocol names the scheme and id and event locate the record. These references let a consumer that can read the original history do so. A consumer MUST NOT require them in order to understand the checkpoint.

6. The checkpoint object

The top level is an object with these members. opencheckpoint, id, created_at, source, and task are REQUIRED. Undefined members are not allowed in any core object; extension data goes in extensions (§7).

Member	Purpose
`opencheckpoint`	Specification version (§5).
`id`	Global checkpoint identifier (§4.1).
`created_at`	When the checkpoint was captured.
`parent`	The checkpoint this one derives from, with an optional digest of its bytes.
`source`	Producer, agent, model, and session references. Informational (§6.1).
`task`	Objective, desired outcome, status, success criteria, and scope (§6.2).
`progress`	Completed steps, current focus, and next steps (§6.3).
`statements`	Instructions, constraints, decisions, observations, hypotheses, questions, and external content, each with provenance (§6.5).
`resources`	References to files, records, documents, artifacts, and other objects (§6.4).
`application_context`	Application state relevant to the task (§6.7).
`operations`	Unfinished approvals, requests for input, external actions, and waits (§6.6).
`continuation`	Requirements, preconditions, stop conditions, recovery actions, and incompatibilities (§6.8).
`derivation`	How the checkpoint was produced and what was left out (§6.9).
`extensions`	Namespaced extension data (§7).

6.1 Source

source.producer names the software that wrote the checkpoint. source.agent and source.model MAY name the agent and model that did the work. All of source is informational: it helps a person or consumer interpret the document and confers no trust, identity, or authority (§10.1).

6.2 Task

objective (REQUIRED) states what the user or system is trying to accomplish, in terms a new agent can act on.
outcome describes what a finished result looks like.
status (REQUIRED) is one of active, blocked, awaiting_input, paused, completed, or abandoned. A completed task MUST NOT have operations that are planned, awaiting, or uncertain (OCP-S006). A blocked task SHOULD say what blocks it, through a next step’s blocked_by or an awaiting operation (OCP-W001).
success_criteria lists criteria, each met, unmet, or unknown, with optional evidence.
scope.includes and scope.excludes state what is in and out of bounds. A constraint that came from a specific party SHOULD be recorded as a constraint statement, which carries provenance.

6.3 Progress

completed lists work already done, oldest first, each with an optional completed_at and evidence. A destination MUST NOT redo a completed step unless evidence shows it must be redone.
focus describes what was being worked on at the boundary.
next lists recommended next steps in suggested order. blocked_by names what prevents a step: an open question, an awaiting operation, an unavailable resource, or an unmet requirement. Version 0.1 has no separate blocker object; a blocker is always one of these. A step blocked by an operation stays blocked until the operation is completed or, for an approval, approved, as the destination verifies in the system of record (§10.3). requires names continuation requirements the step depends on.

Next steps are recommendations from the source, not instructions (§10.2).

6.4 Resources

A resource is anything the task involves that lives outside the checkpoint: a file, a repository, a document, a database record, a business object, a web page, a generated artifact, a tool’s output, a dataset, or a message.

A resource MUST have a uri, a locator, or both. uri MAY use any scheme, including private schemes and URIs that only the source can resolve. locator identifies an object that has no URI by system, type, and key, such as an invoice in an ERP.
revision records the version, commit, ETag, or equivalent that the source observed, and digest records a hash of the content. A consumer uses them to detect that a resource has changed since the checkpoint was captured.
observed_at records when the source last observed the resource; availability records whether it could access it then.
resolver hints at how to retrieve the resource (for example an MCP server name or a repository host). It MUST NOT contain credentials.
excerpt MAY carry a short excerpt, at most 4096 characters. Larger content MUST be referenced, not embedded.
sensitivity lets a producer flag content that needs care (§11).

A URI MUST NOT contain credentials, including userinfo such as user:password@ (OCP-S008), tokens in query strings, or signed URLs whose signature grants access.

6.5 Statements

Statements carry what the work knows and what governs it. Every statement has a kind, a text, and an origin. Keeping the kinds separate is the core of the format: a summary that merges them cannot be continued safely.

Kind	Meaning	Rules
`instruction`	A directive from the user or the operating system.	`origin.type` MUST be `user` or `system`.
`constraint`	A boundary the work must respect.
`decision`	A choice already made.	MUST have a `rationale`.
`observation`	Something found to be the case.	SHOULD cite `evidence` when the origin is `agent` (OCP-W002).
`hypothesis`	Something believed and not established.	MUST NOT be `verified`.
`question`	Something unresolved.	Only questions can be `resolved`, and a resolved question MUST have a `resolution`.
`external`	Content quoted from a third party.	`origin.type` MUST NOT be `user` or `system`. Carries no instruction authority.

origin.type is one of:

user: the person the work is for.
system: the operator or deploying platform, speaking through its configuration or policy.
agent: an AI agent working on the task.
tool: the output of a tool call.
application: an application the user works in.
external: a third party, such as the author of an email, web page, or document.

origin.name MAY name the specific actor or tool and origin.ref MAY reference the resource the statement was taken from.

status is active (the default), superseded, retracted, or resolved. A superseded statement MUST name its replacement in superseded_by, which MUST be a different statement of the same kind, or an observation that confirms a hypothesis (OCP-S007). Only superseded statements carry superseded_by.

verification records whether the source checked the statement:

state is verified (checked against evidence), unverified, disputed (evidence conflicts), or stale (verified once, and the evidence may have changed).
checked_at records when; method records how.
revalidate tells a consumer when it MUST re-check: before_use, before_action, or never.

A producer MUST NOT change a statement’s kind in place. When a hypothesis is confirmed, the producer records a new observation with evidence and marks the hypothesis superseded by it. When a hypothesis is refuted, the producer marks it retracted.

6.6 Operations

An operation is unfinished work that involves someone or something outside the agent: an approval, a request for input, a side-effecting call to an external system, or a wait on an external event.

kind is approval, input, action, or wait. status is one of:

Status	Meaning
`planned`	Not started.
`awaiting`	Requested; waiting for the person or system.
`uncertain`	Started; the outcome is unknown at the boundary.
`failed`	Attempted and failed.
`approved` / `rejected`	An approval’s recorded outcome. Only for `kind: approval`.
`completed`	Finished. Terminal.
`cancelled`	Will not happen. Terminal.

completed, cancelled, and rejected are terminal: a later checkpoint in the same lineage MUST NOT move an operation out of a terminal status (OCP-T001).

effect describes what repeating the operation does: none, idempotent, non_idempotent, or unknown. A consumer MUST treat an absent or unknown effect as non_idempotent. idempotency_key records a key the target system honors, if any.

call identifies the invocation an action operation stands for. tool names the tool or API operation as the interface declares it (for MCP, the tool name the server declares, without a client’s prefix), and arguments holds the arguments it was or will be called with. A producer SHOULD record call on an action operation whose effect is non_idempotent or unknown when it knows the call. A call to the same tool whose arguments include every recorded argument with an equal value is a repeat of the operation, so a consumer can refuse to repeat a completed operation, or require verification before repeating an uncertain one, without reading its description. call describes; it never instructs (§10.2). arguments MUST NOT contain credentials (§10.5), and a producer SHOULD leave out arguments that are sensitive and not needed to identify the call (§11).

record names the resource in a system of record where the operation’s current status can be checked: the approval request for an approval, the payment record for a payment. It differs from target, which names what the operation acts on.

resume is the source’s recommendation: retry, verify_first (check the target system for the outcome before anything else), ask, or do_not_resume. An uncertain operation whose effect is non_idempotent, unknown, or absent MUST have a resume other than retry.

An approved or rejected operation MUST carry an approval record with decided_by, decided_at, and at least one evidence resource in a system of record. An approval record documents a decision and grants no authority. A destination MUST NOT perform an action on the strength of an approval record alone; it MUST verify the approval in the system of record, or obtain a new one, under its own authority (§10.3).

6.7 Application context

Application context carries state from the applications the user works in, which often never appeared in conversation: what is selected or open, which filters are applied, which view is showing, and which edits are drafted and not yet saved.

Each entry names its application and MAY include a view, selections (each referencing a resource, with a role of focused, selected, open, or pinned and an application-defined detail), filters, drafts, and further application-defined state described by the schema named in state_schema.

A draft records an unsaved, saved, or submitted change and the resource it would change. Small draft content MAY be inline in content (at most 16384 characters); larger content belongs in a resource referenced by content_ref.

OpenCheckpoint does not define a UI model. Producers record the state a destination needs to understand and continue the task, not the full rendering of an application.

6.8 Continuation

continuation tells a destination what it needs and what to check before it continues.

requirements lists what continuation depends on. kind is tool, capability, access (access the destination must already hold), or extension (a checkpoint extension the consumer must understand). necessity is required, recommended, or optional; fallback says how to proceed without it.
preconditions lists conditions to check before resuming, each with an on_failure of halt, ask, or degrade.
stop_conditions lists conditions under which continuation MUST NOT proceed. A stop condition MAY name in applies_to the operations it forbids, and in until the operations and statuses that lift it: it applies until every operation listed in until has reached its status. A stop condition without until applies for the whole continuation. A consumer MUST evaluate until against the system of record, never against a status recorded in a checkpoint (§10.3); it finds the status at each operation’s record. When a listed operation has no record, software cannot verify it, and the stop condition stays in force until a person lifts it. These fields let software enforce a stop condition without reading its description; when they and the description differ, a consumer follows the more restrictive.
recovery lists recommended first actions, in order.
incompatibilities lists environments or conditions in which the checkpoint cannot be continued faithfully.

A requirement of kind access describes access the destination needs; it never conveys that access.

6.9 Derivation

derivation.method records how the checkpoint was produced: captured from a live session, compacted from earlier checkpoints or history, merged from several inputs, converted from another format, authored by hand, or forked from a parent alongside possible siblings (§9.3). inputs lists the checkpoints and sessions it was derived from.

omissions records information deliberately left out, with a reason (size, irrelevant, superseded, sensitive, or unavailable) and, where possible, a resource it can be recovered from. transformations records content that was condensed or rewritten and which objects carry the result (affected). A compacting producer MUST record omissions and transformations (§9.2).

7. Extensions

Every core object that can carry domain-specific data has an extensions member: the top level, source, task, progress, statement, resource, application_context entries, operation, and continuation. Its keys are namespaced identifiers: a lowercase reverse-DNS name of a domain the extension author controls, optionally followed by a /-separated path, for example com.example.crm or org.example.finance/v2. The io.opencheckpoint prefix is reserved for this project.

A consumer MUST ignore extension keys it does not understand.
A consumer that re-serializes a document, or carries an object forward into a derived checkpoint, MUST preserve extension data it does not understand, unless it records the removal in derivation.omissions.
An extension MUST NOT change the meaning of a core field. A consumer that ignores every extension MUST still interpret the core fields correctly.
An extension MUST NOT carry instructions that bypass the statement model (§10.2) or credentials (§10.5).
If a document cannot be interpreted faithfully without an extension, the producer SHOULD list it as a continuation requirement of kind extension, naming the key in name. A consumer that does not implement a required extension MUST NOT claim full understanding of the document.

8. Validation

8.1 Levels of assurance

The table separates five properties that are easy to conflate. A different party establishes each one.

Level	Question	Established by
1. Syntactic validity	Does the document conform to the JSON Schema?	Any validator.
2. Semantic consistency	Do references resolve, ids stay unique, and the rules in §8.2 hold?	Any conforming validator.
3. Resource availability	Can the destination resolve the referenced resources, at the recorded revisions?	The destination, at restore time.
4. Authorization	Is the destination permitted to take the next actions?	The destination’s own policy and systems of record. Never the checkpoint.
5. Continuation success	Did the destination actually continue the task correctly?	Behavioral evaluation (`tests/scenarios`).

Schema format keywords (date-time, uri) are annotations, as JSON Schema Draft 2020-12 specifies by default: a conforming validator MUST NOT reject a document solely because a value fails a format. Where the format matters, the schema also states a pattern, which every validator enforces. This keeps validators in different languages in agreement.

A conforming validator reports levels 1 and 2. It MUST NOT describe a document that passes them as “safe to resume”, “authorized”, or “resumable”; passing levels 1 and 2 means only that the document is well-formed and internally consistent.

8.2 Semantic rules

Errors make a document invalid. Warnings do not, and validators SHOULD report them.

Code	Level	Rule
OCP-S001	error	Local ids are unique across the document.
OCP-S002	error	Every local reference resolves to a local object.
OCP-S003	error	Every reference points to an allowed type: `evidence`, `origin.ref`, `target`, `content_ref`, selection `resource`, approval `evidence`, operation `record`, and omission `recoverable_from` point to resources; `superseded_by` to a statement; `depends_on` to operations; `requires` to requirements; `blocked_by` to statements, operations, resources, or requirements. `applies_to` and an `until` entry’s `operation` to operations. `refs` and `affected` may point to any local object.
OCP-S004	error	`parent.id` differs from `id`.
OCP-S005	error	No past-event timestamp is later than `created_at` (§4.2).
OCP-S006	error	A `completed` task has no `planned`, `awaiting`, or `uncertain` operations.
OCP-S007	error	`superseded_by` names a different statement of the same kind, or an observation that confirms a hypothesis.
OCP-S008	error	No resource URI contains userinfo.
OCP-S009	error	An `until` entry whose status is `approved` or `rejected` names an operation of kind `approval`.
OCP-W001	warning	A `blocked` task names what blocks it.
OCP-W002	warning	An `observation` whose origin is `agent` cites evidence.
OCP-W003	warning	An `awaiting` operation has not expired before `created_at`.
OCP-W004	warning	A `forked` checkpoint has no non-terminal `action` operation whose `effect` is not `none` unless a stop condition references it in `refs` or `applies_to` (§9.3).

When a consumer has both a checkpoint and its parent, these rules also apply:

Code	Level	Rule
OCP-T001	error	An operation that is terminal (`completed`, `cancelled`, `rejected`) in the parent has the same status in the child, if present.
OCP-T002	error	The child’s `parent.id` names the parent, and the child’s `created_at` is not earlier than the parent’s.

Schema-level rules (for example, that an instruction’s origin is user or system) are part of level 1 and are listed with the schema.

9. Producer requirements

9.1 Capturing a checkpoint

A producer:

MUST capture at a boundary. Any operation started and not confirmed MUST be recorded as uncertain, with its effect and a safe resume.
MUST record each statement with the kind and origin it actually had. Text that arrived in a tool result, document, web page, email, or another agent’s output MUST be recorded as external (or as an observation about that content), never as an instruction, however it is phrased.
MUST NOT record a hypothesis as an observation, or an observation as verified, unless it was checked.
MUST NOT include credentials, access tokens, API keys, session cookies, signed URLs, or private keys anywhere in the document, including extensions and excerpts.
SHOULD reference large content as resources rather than embedding it.
SHOULD record revision or digest for resources whose content the work depends on, so that staleness can be detected.
SHOULD include the minimum personal and confidential data the destination needs (§11).

9.2 Compacting a checkpoint

Compaction produces a smaller checkpoint from larger history or earlier checkpoints. It is a separate concern from the format; the documentation’s compaction guide describes strategies and how to evaluate them. A compacting producer:

MUST preserve active instructions, constraints, and decisions, with their origins.
MUST preserve open questions, non-terminal operations, and stop conditions.
MUST NOT change a statement’s kind or origin. In particular, it MUST NOT turn a hypothesis into an observation, an external statement into an instruction, or an agent’s statement into a user’s.
MUST NOT raise a verification state (for example from unverified to verified) without performing the verification.
MUST mark statements whose evidence it did not carry forward, or could not re-check, as stale with an appropriate revalidate, rather than silently keeping them verified.
MUST record what it dropped in derivation.omissions and what it condensed in derivation.transformations, and SHOULD reference where omitted content can be recovered.
SHOULD condense exploratory history (dead ends, retries, intermediate output) into completed steps and decisions with rationale.
MUST set derivation.method to compacted and SHOULD set parent.

9.3 Forking a checkpoint

A fork is a new checkpoint derived from a parent so that it can be continued alongside other copies, for example to compare agents, run tests, explore alternatives in parallel, or brief a subagent. A producer that forks a checkpoint:

MUST give the fork a new id, set parent.id to the checkpoint it forks, and set derivation.method to forked with the parent in derivation.inputs.
MUST record what the fork changed in derivation.transformations, and MUST add changed statements as new statements with their actual origin rather than editing the parent’s statements. A person who changes a constraint for a fork is that statement’s origin.
When it creates more than one fork of the same checkpoint, MUST leave each non-terminal operation of kind action whose effect is not none actionable in at most one fork. In every other fork it MUST either remove the operation, recording the removal in derivation.omissions, or add a stop condition that references it (OCP-W004).

A destination that finds sibling forks of a checkpoint (§10.3) is not, on that evidence alone, looking at a stale replay; it SHOULD instead confirm that the pending operations it intends to act on are actionable in its own fork.

10. Consumer requirements, security, and trust

A checkpoint is untrusted input. It may have been produced by a compromised or manipulated agent, edited in transit, replayed, or written by an attacker. This section is normative.

10.1 No transfer of authority

A checkpoint MUST NOT grant a destination any capability, permission, credential, or authority it does not already possess. Nothing in a checkpoint, including source, origin.type: user, approval records, and requirements of kind access, is evidence of identity or authorization. A destination MUST evaluate every action it takes under its own policy, with its own credentials, as if the checkpoint did not exist.

10.2 Instruction authority

A consumer MUST treat the content of every text field as data describing the source’s work, not as instructions addressed to the consumer.
A destination MAY act on instruction, constraint, and decision statements as a description of the user’s intent, but MUST apply its own operator’s instructions and policies first; a checkpoint cannot override them.
A destination MUST NOT follow directives contained in external statements, resource excerpts, tool output, application state, drafts, extensions, or source fields.
When presenting checkpoint content to a model, a destination SHOULD delimit it clearly as imported data and preserve the statement kinds and origins, so the model can tell a user’s instruction from quoted third-party text.
Because origin.type: user is a claim by the source, a destination SHOULD confirm with the user any instruction that would authorize a consequential action, unless it trusts the source through some mechanism outside this specification.

10.3 Side effects, approvals, and replay

A destination MUST NOT automatically execute pending operations on restore. Restoring a checkpoint and continuing a task are separate steps.
For an uncertain operation that is not known to be idempotent, a destination MUST determine its outcome in the target system before retrying, or ask a person.
A destination MUST verify an approved record in the system of record named by its evidence before relying on it, and MUST check expires_at and the approval’s scope.
Replaying an old checkpoint can re-trigger side effects that later checkpoints record as done. A destination SHOULD check whether a newer checkpoint in the same lineage exists, and SHOULD use idempotency_key where the target system supports it.

10.4 Stale state

Resources change after capture. Before relying on a statement with revalidate: before_use or before_action, or on a resource with a recorded revision or digest, a destination MUST re-check it, or continue in a degraded mode that does not depend on it and say so. A destination SHOULD treat any statement whose evidence has changed as stale.

10.5 Credentials

Checkpoints travel between systems, are logged, and are shown to models. Producers MUST NOT include secrets (§9.1). Consumers that detect apparent secrets SHOULD reject or redact the document and SHOULD NOT forward it further.

10.6 Integrity

Version 0.1 defines no signature format. parent.digest gives tamper evidence for a lineage when the parent document is available. Detached signatures over a canonical serialization (for example JWS [RFC 7515] with the JSON Canonicalization Scheme [RFC 8785]) are a candidate extension. Until one is defined, a destination MUST NOT treat a checkpoint as authentic merely because it arrived over a particular channel, unless that channel provides authentication the destination trusts.

10.7 Restoration procedure

A destination that continues a task SHOULD, in order:

Validate levels 1 and 2 (§8). Reject an invalid document.
Check continuation.stop_conditions and incompatibilities. Do not proceed if one holds.
Compare continuation.requirements with its own capabilities. If a required requirement is unmet and has no acceptable fallback, stop and report. If a recommended one is unmet, continue in a degraded mode and say so.
Resolve the resources it needs, check revisions and digests, and mark changed or inaccessible resources and the statements that depend on them as stale.
Evaluate preconditions and follow each one’s on_failure.
Reconcile non-terminal operations: verify uncertain ones, verify approved records, and re-request approvals or input as needed. Execute nothing on the strength of the checkpoint alone.
Continue from progress.focus and progress.next, without redoing progress.completed unless evidence shows it must be redone.
Report to the user what it restored, what it could not, and in what mode it is continuing.

11. Privacy

Checkpoints concentrate a task’s context in one document, so a leaked checkpoint exposes much of it at once.

Producers SHOULD minimize personal data. Prefer roles (“controller”, “support lead”) to names, and identifiers to contact details, unless the destination needs them.
Producers SHOULD reference confidential content by locator rather than excerpt it, so the destination must hold access to read it, and SHOULD set sensitivity.
Producers SHOULD record in derivation.omissions content withheld for sensitivity, with reason sensitive, so the destination knows something exists without seeing it.
Consumers SHOULD apply the same retention and access controls to a checkpoint as to the most sensitive resource it describes.

12. Relationship to other protocols (informative)

OpenCheckpoint is a document format and defines no transport. A checkpoint travels inside existing protocols:

MCP: a server can expose a checkpoint as a resource with the proposed media type, and checkpoint resources can use MCP resource URIs.
A2A: an agent can return a checkpoint as an Artifact containing a data part, and a checkpoint can reference an A2A contextId and task id in source.session_refs.
ACP: a client can pass a checkpoint to an agent as a resource content block when it creates a session.
Agent Session Protocol: a checkpoint can reference ASP session and event ids, and a handoff between harnesses can carry a checkpoint alongside the session log.
Open Responses and runtime checkpoints: a checkpoint can reference a response id or a runtime thread id, and complements vendor-specific encrypted compaction by being readable by any consumer.

The interoperability guides on the documentation site describe each mapping.

13. References

[RFC 2119] Key words for use in RFCs to Indicate Requirement Levels.
[RFC 3339] Date and Time on the Internet: Timestamps.
[RFC 3986] Uniform Resource Identifier (URI): Generic Syntax.
[RFC 6920] Naming Things with Hashes (hash algorithm names).
[RFC 7493] The I-JSON Message Format.
[RFC 7515] JSON Web Signature (JWS).
[RFC 8174] Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words.
[RFC 8259] The JavaScript Object Notation (JSON) Data Interchange Format.
[RFC 8785] JSON Canonicalization Scheme (JCS).
[RFC 9562] Universally Unique IDentifiers (UUIDs).
JSON Schema Draft 2020-12.

Generated from spec/versions/v0.1.md. Edit it there.