Proof of Process: Worked Examples

Introduction This document provides worked examples of Proof of Process (PoP) Evidence packets and Attestation Results as defined in . All examples use CBOR diagnostic notation Section G, with comments (/ ... /) to annotate fields. Integer keys are used as defined in the companion CDDL schema. These examples are informative. The normative schema is defined in the CDDL schema document. Implementers SHOULD validate their implementations against test vectors derived from these examples.

Requirements Language 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.

Minimal Evidence Packet (Basic Tier) This example demonstrates a minimal Basic tier Evidence packet with a single checkpoint. The document is approximately 500 characters, representing a short paragraph written in a single authoring session. Scenario: An author writes a brief memo over approximately 3 minutes. The Attesting Environment captures one checkpoint at the end of the session. Key observations:

The Basic tier contains only the required checkpoint chain. No optional sections (presence, forensics, etc.) are included.
The genesis checkpoint has prev-hash of 32 zero bytes.
The VDF proves at least 180 seconds elapsed (1.53B iterations at calibrated 8.5M iterations/second).
Jitter binding shows 423 timing samples with realistic distribution peaking in the 100-200ms range.
Estimated entropy is 2.78 bits, below the recommended 32-bit threshold for Standard tier but acceptable for Basic tier.

Multi-Checkpoint Evidence (Standard Tier) This example demonstrates a Standard tier Evidence packet with three checkpoints showing document evolution. The document grows from 100 to 500 to 1200 characters across the checkpoints, representing a typical drafting process with revisions. Scenario: An author writes a short essay over 45 minutes with two natural breaks where checkpoints are captured. The evidence includes presence challenges. VDF entanglement across checkpoints: | VDF_output{1} |---->| VDF_output{2} | +---------------+ +---------------+ +---------------+ To backdate checkpoint 1, adversary must: (1) Compute content that hashes to content-hash{1} (2) Generate jitter that commits to jitter-commitment{1} (3) Recompute VDF_output{1} from new VDF_input{1} (4) Recompute VDF_output{2} (depends on output{1}) (5) Complete steps 3-4 before external anchor confirms state ]]>

Jitter Seal Verification Example This example shows the complete jitter seal verification process, including histogram data, entropy calculation, and binding MAC computation.

Sample Histogram Data

Entropy Calculation Walkthrough Shannon entropy is calculated from the histogram distribution:

Binding MAC Computation

Verifier Checks A Verifier performs the following checks on the jitter seal: = 1 # (2) Recompute entropy-commitment (if raw-intervals disclosed) if jitter_binding.raw_intervals is not None: expected_commitment = sha256( concat_as_uint32_le(jitter_binding.raw_intervals) ) commitment = jitter_binding.entropy_commitment assert commitment == expected_commitment # (3) Recompute histogram (if raw-intervals disclosed) if jitter_binding.raw_intervals is not None: computed_histogram = bucket_intervals( jitter_binding.raw_intervals, boundaries=(0, 50, 100, 200, 500, 1000, 2000, 5000) ) assert histograms_consistent( computed_histogram, jitter_binding.summary.timing_histogram ) # (4) Verify binding MAC expected_mac = hmac_sha256( key=chain_key, message=jitter_binding.entropy_commitment.value + cbor_encode(jitter_binding.sources) + cbor_encode(jitter_binding.summary) + prev_hash ) assert jitter_binding.binding_mac == expected_mac # (5) Entropy threshold check assert jitter_binding.summary.entropy_bits >= MIN_THRESHOLD # (6) Sample count plausibility assert jitter_binding.summary.sample_count >= 10 return VERIFIED ]]>

VDF Causality Example This example demonstrates VDF input computation and why backdating requires recomputation of the entire subsequent chain.

VDF Input Computation for Checkpoint N

Why Backdating Requires Recomputation

Calibration Cross-Check (min_duration * 10): return WARNING("Claimed duration suspiciously long") return VALID # Example: # iterations = 10,200,000,000 # calibration_rate = 8,500,000 / second # min_duration = 10.2B / 8.5M = 1200 seconds # claimed_duration = 1200 seconds: VALID ]]>

Absence Claim Example This example demonstrates both chain-verifiable and monitoring- dependent absence claims, showing how verifiers prove claims from checkpoint data.

Chain-Verifiable Claim: max-single-delta-chars Claim: No single checkpoint added more than 500 characters. Verifier proof procedure:

Monitoring-Dependent Claim: max-paste-event-chars Claim: No paste event inserted more than 200 characters. Trust chain for monitoring-dependent claim:

Attestation Result Example (.war) This example shows a Verifier's Attestation Result after appraising the multi-checkpoint Evidence packet from . Key aspects of the Attestation Result:

Verdict: likely-human (2) Based on: checkpoint chain integrity, realistic jitter distribution, presence challenges passed, no anomalies.
Confidence: 0.78 (high range) Factors increasing: chain integrity proven, presence verified. Factors limiting: no hardware attestation, self-reported calibration.
Caveats document limitations: Relying Parties can assess whether the caveats are acceptable for their use case. Academic submission may accept; legal proceeding may require additional evidence.
Verifier signature enables trust chain: Relying Party trusts WritersLogic Verification Service. Signature proves Attestation Result came from that Verifier.

Salt Mode Examples This example demonstrates the three salt modes and their verification flow differences. The same document is shown with each salt mode.

Unsalted Mode (Default) Verification flow (unsalted):

Author-Salted Mode Verification flow (author-salted):

Third-Party Escrowed Mode Verification flow (escrowed):

Salt Mode Comparison

Aspect	Unsalted	Author-Salted	Escrowed
Who can verify	Anyone with doc	Author's choice	Conditions-based
Privacy	None (hash public)	High (author controls)	Medium (escrow policy)
Typical use	Published works	Unpublished drafts	Legal/regulatory
Salt storage	N/A	Author responsibility	Third party
Lost salt impact	N/A	Cannot verify	Escrow backup

Security Considerations This document provides examples for the Proof of Process format. Security considerations for the format itself are specified in the main architecture document . Example data in this document is illustrative. Implementations MUST NOT use example values as actual cryptographic material. All hash values, keys, and signatures shown are placeholders.

IANA Considerations This document has no IANA actions. All registrations are specified in the main architecture document.