Proof of Process (PoP): A Verifiable Process Transcript Format

Introduction As digital documents evolve through complex workflows involving human authors, automated tools, and AI assistants, stakeholders require a standardized method to record what happened during the document's lifecycle. Existing logs are often proprietary, unstructured, or easily mutated. This document specifies the Proof of Process (PoP) Transcript Format, a standardized data model for recording the evolutionary history of a digital artifact. It defines a canonical set of Semantic Events (Insert, Delete, Replace, Move) and a mechanism for linking these events into a hash-chained Provenance DAG (Directed Acyclic Graph). Designed for interoperability, this format allows disparate editing environments (word processors, code editors, CMS platforms) to produce compatible Process Transcripts. These transcripts can support Tool Receipts, allowing AI agents and automated tools to cryptographically sign and attribute their specific contributions, thereby enabling a "compositional provenance" model where human and machine contributions are clearly demarcated within a single verifiable history.

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 when, and only when, they appear in all capitals, as shown here.

Artifact: A digital object such as a document, code bundle, or media file.
Event: A canonical semantic editing operation applied to an artifact state.
Transcript: An ordered sequence of events representing a process session.
Envelope: A CBOR-encoded container holding transcript commitments, anchors, receipts, and policy hooks.
Anchor: A mechanism that binds transcript state to chronology, such as an external timestamp or sequential-work proof.
Receipt: A signed statement from a tool indicating that content was produced or transformed, referenced by events.
Provenance DAG: A directed acyclic graph constructed from receipts and references between them.
Policy: A verifier-defined configuration for evaluation of process evidence.
Policy Commit: A cryptographic commitment to a policy descriptor, included to identify the applied policy.
Seed Commit: A cryptographic commitment to a seed used to parameterize evaluation functions and/or audits.
Deterministic Encoding: CBOR encoding with a canonical ordering as required for reproducible hashing.

Functional Scope and Protocol Claims This section defines the scope of the transcript format regarding data integrity and provenance visibility.

Transcript Integrity Claims A valid PoP Transcript ensures:

Event Immutability: Once an event is recorded and covered by a subsequent hash, it cannot be altered or removed without invalidating the chain.
Completeness: The final hash of the transcript deterministically reconstructs the final state of the document. Any discrepancy between the transcript-derived state and the actual document content indicates tampering.
Attribution: Every event is associated with a specific Actor ID (Key) or Tool Receipt, allowing precise attribution of who or what performed a specific edit.

Out of Scope

Content Quality or Truth: The transcript records that text was written; it does not verify the factual accuracy or quality of that text.
Intent: The transcript records operations (e.g., "User deleted paragraph A"). It does not record why the operation occurred.
Surveillance: This format is designed for verification, not surveillance. It supports privacy-preserving disclosure modes (e.g., Zero-Knowledge proofs of statistics) where the raw content of the edits remains private, revealing only the metrics of the process.

Architecture Overview PoP is a portable evidence format intended to be produced by an editing environment (the Producer) and consumed by a Verifier. A third party (Anchor Service) MAY provide timestamps or other anchoring evidence. Tools (e.g., language models, grammar checkers, converters) MAY provide signed receipts.

PoP Evidence Flow (Informative) | Verifier | | (Editor) | | (Policy) | +------+------+ +------+------+ | | | | +------+------+ Anchors (optional) | | Anchor +-------------------------------+ | Service | +-------------+ +-------------+ Receipts (optional) +-------------+ | Tools +----------------------->| Producer | | (LLM, etc.) | | / Verifier | +-------------+ +-------------+ ]]> PoP is compatible with RATS/EAT deployments by treating the PoP envelope as evidence that can be conveyed alongside attestation tokens, referenced by claims, or embedded in artifact metadata for later validation. The overall Proof of Process architecture is defined in .

Data Model PoP uses CBOR as the encoding and CDDL for data model definitions. All hashing computations depend on deterministic CBOR encoding; Producers and Verifiers MUST use a deterministic CBOR encoding profile suitable for reproducible hashing.

Ranges and Identifiers Offsets and ranges refer to a canonical byte or character indexing scheme over the logical artifact content. The indexing scheme MUST be specified by the Producer and bound in the envelope so that Verifiers can interpret ranges consistently. This specification defines a generic Range structure. Producers MAY use byte offsets, Unicode scalar offsets, or another deterministic scheme. The chosen scheme MUST be indicated in the envelope.

Canonical Event Types PoP defines canonical semantic event types. Events describe changes to artifact state at a semantic operation level rather than raw keystrokes. Raw keystroke telemetry is OPTIONAL and is not required for PoP verification. The following event types are defined:

INS: insert content at a range/position
DEL: delete content in a range
REP: replace content in a range with new content
MOV: move a range to a destination position
PASTE: insert content with an origin reference (e.g., receipt-bound)
SNAP: checkpoint snapshot of artifact hash and optional cursor state

Events MUST include sufficient information to validate transcript integrity and, when required by policy, to validate that the transcript corresponds to the final artifact (e.g., via checkpoints).

Event Hash Chaining PoP binds transcript events in order using a hash chain. The chain depends on deterministic encoding of each Event structure.

Hash Algorithm Let H be a cryptographic hash function. This specification RECOMMENDS SHA-256. The initial hash value h_0 MUST be defined as the hash of a domain separation string and the session identifier: h_0 = H("PoP-Transcript" || session_id) For each event E_i, the chain value is computed as: h_i = H(h_{i-1} || CBOR_Deterministic(E_i)) The transcript root is defined as root = h_n for the final event E_n.

Requirements

Producers MUST use deterministic CBOR encoding for all hashed structures.
Verifiers MUST recompute the hash chain and compare the derived root to the envelope root.
Mismatch of any chain computation MUST cause verification failure.

PoP supports optional chronology binding via Anchors. Policies MAY require specific anchor types or densities. This document defines two anchor classes: External Anchors and Sequential Work Anchors.

An External Anchor binds the transcript root (or an intermediate chain value) to an externally verifiable time assertion (e.g., a timestamping service, transparency log, or other notary). The specific external anchoring system is out of scope for this document; PoP defines a generic container for including and validating anchor evidence.

A Sequential Work Anchor provides evidence that a specified amount of sequential computation was performed between two transcript states. This can increase the cost of post-hoc backfilling. The concrete VDF or sequential-work scheme is policy-defined. This document defines a container to carry such evidence.

If an envelope includes anchors, verifiers MUST validate each anchor according to its type.
If a policy requires anchors and they are absent or invalid, verification MUST fail.
Anchor validation MUST bind to the relevant transcript state (root or intermediate chain values) as specified by the anchor.

PoP supports compositional provenance via signed tool receipts. Receipts enable producers to explicitly declare and bind tool-generated outputs (including AI assistance) without relying on brittle inference or detection. Receipts MAY be used for any deterministic or non-deterministic tool that emits content, patches, or transformations that contribute to the artifact.

A Receipt is a signed statement that binds tool identity and an output commitment. An input commitment MAY be included to allow stronger binding, but is OPTIONAL to support privacy-preserving tools. Receipts MAY reference other receipts to form a provenance DAG. Policies MAY restrict recursion depth.

Verifiers MUST validate each receipt signature over its canonical encoding.
Receipt public keys MUST be represented in a verifiable format; policies MAY require certificate chains or allow bare keys.
If an event references a receipt (via source_ref), the referenced receipt MUST be present or retrievable under policy.
Policies MAY require validation of the provenance DAG and MAY impose recursion and size limits.

The PoP Envelope is the primary interchange object. It binds transcript commitments, anchors, receipts, and policy hooks. The envelope is CBOR-encoded and SHOULD be embedded into artifact metadata or conveyed alongside artifacts.

PoP defines policy hooks but does not standardize a scoring model. To enable reproducible application of a policy, the envelope includes:

policy_commit: a commitment to a policy descriptor
seed_commit: a commitment to a seed used to parameterize evaluation and/or audits

Commitments support commit-then-reveal workflows where the evaluation surface is unpredictable at capture time but verifiable after reveal under policy.

The envelope MAY include a claims field carrying derived values (e.g., integrity pass/fail, evaluation outputs). Claims MUST NOT be treated as authoritative unless verifiers recompute or validate them under policy. Policies SHOULD treat claims as advisory and derive evaluation from transcript evidence.

The envelope MAY include a zk bundle to support privacy-preserving verification (e.g., threshold proofs for policy-defined evaluations without full transcript disclosure). The specific ZK proof system is policy-defined.

Verifiers MUST perform the following procedure to validate a PoP envelope. Policies MAY impose additional requirements and MAY allow partial disclosure modes.

Parse the envelope as CBOR and validate required fields.
Validate version and supported algorithms.
Validate encoding determinism constraints where applicable.

Obtain the transcript (full disclosure or policy-authorized proofs).
Recompute the hash chain from h_0 through h_n.
Compare derived root to the envelope root.

Mismatch MUST cause verification failure.

Validate all included anchors.
Confirm anchors bind to the intended transcript state (root or specified chain values).
Apply policy requirements for anchor presence, density, or types.

Validate receipt signatures and canonical encodings.
Resolve and validate referenced receipts as required by policy.
Verify any policy constraints on receipt DAG depth or classes.

Policies MAY require validation that the transcript corresponds to the final artifact. This may be performed by verifying SNAP events, checkpoints, or other commitments that bind the transcript to the final artifact hash.

After transcript and anchoring verification, a verifier MAY compute features and apply a policy-defined evaluation. If the envelope includes a ZK bundle and the policy allows it, the verifier MAY validate a ZK proof instead of obtaining the full transcript.

PoP does not standardize any scoring function, threshold, or interpretation. Policies define evaluation inputs, models, and thresholds. PoP provides hooks to identify policies and support reproducible evaluation.

The policy_commit field is a cryptographic commitment to a policy descriptor, e.g.: policy_commit = H(policy_descriptor) The contents and distribution of the policy descriptor are out of scope for this document. Policies MUST be uniquely identifiable by policy_commit.

Policies MAY use seeds to parameterize evaluation functions (e.g., to mitigate adaptive optimization against a static evaluation surface). If used, the envelope includes seed_commit, and verifiers MAY require a reveal of the seed or a ZK proof that incorporates the committed seed.

Any evaluation outputs, including derived claims, are policy-defined and MUST be expressed as assessments of evidence, not assertions of cognitive origin. Policies SHOULD provide outputs that are interpretable and auditable (e.g., quantified import ratios, refinement ratios, or other measurable evidence summaries).

PoP provides tamper-evident transcripts and optional chronology binding. It does not prevent an adversarial producer from performing arbitrary sequences of valid edits. Policies should treat PoP as evidence of recorded process, not proof of mental origin.

Synthetic transcript generation: a producer may attempt to fabricate a transcript consistent with a target artifact.
Receipt forgery: a producer may attempt to forge or replay tool receipts.
Anchor replay or substitution: invalid anchors may be presented or misbound.
Adaptive optimization: if evaluation metrics are static and public, adversaries may optimize transcripts to pass thresholds.
Privacy leakage: transcripts can reveal sensitive drafting history if disclosed improperly.

Hash chaining over deterministic encodings provides tamper evidence.
Anchors (timestamps, sequential work) can raise the cost of post-hoc fabrication and bind chronology.
Receipt signatures and, when used, DAG validation mitigate provenance forgery.
Seeded evaluation can mitigate adaptive optimization (policy-defined; not required by PoP).
Policies should define disclosure requirements and support partial disclosure or ZK proofs.

Producers and verifiers SHOULD support algorithm agility for hash functions and signature schemes. Policies SHOULD specify allowed algorithms and minimum security strengths.

Transcripts can reveal sensitive intermediate drafts, editing patterns, and content that was later removed. PoP supports multiple disclosure modes, but this document does not mandate a particular privacy policy.

Full disclosure: the entire transcript is revealed to a verifier.
Partial disclosure: Merkle proofs or selective event disclosure under policy.
Zero-knowledge: policy-defined threshold proofs without transcript disclosure.

Policies SHOULD minimize disclosure and SHOULD avoid collecting raw keystrokes or invasive telemetry unless explicitly required for a deployment and accompanied by informed consent.

This document requests IANA to register a media type for PoP envelopes encoded in CBOR.

Type name: application Subtype name: pop+cbor Required parameters: none Optional parameters: none Encoding considerations: binary Security considerations: see Interoperability considerations: none Published specification: this document Applications that use this media type: editors, provenance systems, attestation verifiers Fragment identifier considerations: none Additional information: Magic number(s): none File extension(s): .pop Macintosh file type code(s): none Person & email address to contact for further information: David Condrey (david@writerslogic.com) Intended usage: COMMON Restrictions on usage: none Author: Authors of this document Change controller: IETF

Example Verification Flow (Informative) This appendix illustrates a typical verification sequence.

Verifier parses the PoP envelope and checks required fields.
Verifier obtains transcript disclosure (full transcript or policy-approved proofs).
Verifier recomputes the transcript hash chain and validates the root.
Verifier validates all anchors included in the envelope and applies policy requirements.
Verifier validates receipt signatures and resolves any referenced receipts per policy.
Verifier validates binding to the final artifact hash (if required by policy).
Verifier applies policy-defined evaluation; if ZK is provided, verifies threshold proof.
Verifier outputs an evidence summary as policy-defined assessment of process evidence.