Back to wiki menu

Platform overview

Verified Reality Appender: Public Provenance & Trust Architecture

Last updated: August 30, 2026 at 23:19

Executive Overview

The Verified Reality Appender is a non-destructive digital editing framework designed to preserve the tamper-evident cryptographic integrity of video records from lens capture to final cut.

In traditional digital media production, editing a video alters its raw pixel arrays, which permanently breaks the original cryptographic signature applied by the camera sensor. The Appender framework solves this. It allows creators to edit, trim, and composite authentic video files—known as Truth Packets—while producing an exported render that carries a cryptographically linked provenance record derived from the original raw footage. Recipients can re-verify integrity checks; this is not a guarantee of admissibility.

The Technical Challenge

When a high-definition digital camera captures a Truth Packet, it embeds a tamper-proof digital signature using an on-sensor private key. If anyone modifies even a single pixel of that video, the signature breaks, alerting downstream observers that the asset is no longer authentic.

However, legitimate video post-production inherently requires modifications:

  • Trimming dead space or pauses.

  • Shortening long recordings to fit specific time allocations.

  • Joining multiple verified clips into a continuous narrative.

Normally, when standard editing software exports these cuts, it compiles a brand-new file. This action destroys the camera's original chain of custody, making the edited video mathematically indistinguishable from a malicious manipulation or an AI-generated deepfake.

The Three-Layer Trust Model: Recipe, Kitchen, and Inspector

To preserve media authenticity without restricting creative capability, the Appender architecture splits the creative editing directives away from the physical rendering process. This is achieved using three isolated conceptual layers:

  • The Recipe (The Local Appender):

    • Responsibility: Records raw timestamps of cuts, crops, and transitions as structured metadata.

    • Security Mechanism: The user's computer never compiles the final video locally. This prevents local asset tampering or frame injections because the client machine has no hand in generating the physical pixels of the final output.

  • The Kitchen (The Licensing Worker):

    • Responsibility: Resolves the original assets from secure storage and compiles them using a secure rendering engine.

    • Security Mechanism: Video compilation takes place within an isolated cloud-based server environment using read-only source files.

  • The Inspector (The Cryptographic Signer):

    • Responsibility: Audits the final compiled output against the input manifest and signs it using dedicated hardware.

    • Security Mechanism: Utilizes an isolated Hardware Security Module (HSM) to apply a tamper-evident digital seal.

The Step-by-Step Security Pipeline

Phase 1: Drafting the Recipe (The Local Appender)

  • Non-Destructive UI: When a creator makes adjustments inside the local Appender application, the program never decodes, modifies, or renders the underlying Truth Packets. No local rendering takes place on the user's machine.

  • Asset Assembly Blueprint: Instead, the Appender generates a Cuts-Only Manifest (built to align with open metadata frameworks like the Coalition for Content Provenance and Authenticity, or C2PA).

  • Structured Metadata: This manifest is a highly structured, lightweight JSON document containing the edit's blueprint. It explicitly dictates the exact frames utilized, for example: "Take frames 0 through 300 from Verified Source A, then frames 600 through 1200 from Verified Source B."

  • Payload Upload: This blueprint is securely transmitted to the cloud platform's registry for assembly.

Phase 2: Clean-Room Rendering (The Licensing Worker)

  • Environment Isolation: Because a local machine's operating system can be subverted or infected with malware to inject counterfeit video frames during rendering, the compilation process is handled entirely inside a secure, cloud-hosted environment.

  • Manifest Retrieval: The cloud worker pulls down the verified Cuts-Only Manifest.

  • Source Resolution: It fetches the pristine, original Truth Packets directly from secure, read-only Cloudflare R2 storage.

  • FFmpeg Compilation: It compiles and watermarks the edited video exactly as described in the blueprint using an automated rendering pipeline (powered by FFmpeg).

  • State Locking: The completed video is safely exported and locked in a state flagged as "ready to sign."

Phase 3: Certification & Sealing (The Asymmetric Signer)

  • Independent Audit: Before the video is made public, it passes to an isolated Cryptographic Signer that operates behind a dedicated security boundary. The signer evaluates the compiled video's digital hash against the origin manifest to ensure they represent an exact, untampered match.

  • Hardware-Bound Signing: If the verification calculations are flawless, the signer calls a Hardware Security Module (HSM) via AWS KMS to apply an asymmetric signature utilizing the secure ECC_NIST_P256 standard (the cryptographic curve widely used for secure electronic identification and hardware-bound keys).

  • DSSE Packaging: The signature is packaged inside a Dead Simple Signing Envelope (DSSE). This industry-standard, tamper-evident envelope binds the verifiable edit history directly to the final video file.

Public Verification: How the World Audits the Video

Once exported and distributed, anyone can verify the video's history instantly without needing access to private company keys, internal server codebases, or proprietary trade secrets:

  • Independent Hash Calculation: The public verification site or integrated viewing player reads the binary data of the video file and calculates its unique cryptographic hash.

  • Signature Verification: The public verification API reads the video's attached DSSE envelope and runs a validation check against the platform's published public keys.

  • Fail-Closed Protection: If a single pixel of the edited video has been modified after export (by an adversary attempting a face-swap, frame-injection, or editing trick), or if the signature itself has been altered, the mathematical validation fails. The verification system immediately labels the video with a strict "NO_MATCH" or "TAMPERED" warning.

 

 

System Requirements & Operational Constraints

To utilize the Verified Reality Appender, users, software states, and underlying video assets must meet the following technical criteria and platform rules.

1. Subscription Tier Requirement

  • Pro Subscription Tier Only: Access to the Appender desktop software, local project synchronization, and the remote cloud rendering pipeline is strictly limited to users and verifiers maintaining an active Pro Subscription.

2. Asset Storage Requirements

  • Hot Storage Tier Mandatory: Source media files must be actively indexed and stored within the platform’s high-availability hot storage network (e.g., Cloudflare R2).

  • Cold Storage Incompatibility: The cloud rendering engine cannot process files archived in cold or deep storage tiers (such as AWS Glacier).

  • Decentralized Storage Boundaries: Assets stored exclusively on permanent or decentralized storage networks (such as Arweave / "our weave") are incompatible with the pipeline unless they are cached or moved to the platform's active hot storage bucket first.

3. Truth Packet Compatibility Restrictions

  • Standard Mode Validation: The Appender can only process standard Truth Packets that contain granular, frame-by-frame metadata and intermediate block hashes.

  • Dark Mode Exclusion: Video files captured or sealed in "Dark Mode" cannot be used in the Appender. Because Dark Mode preserves privacy by saving only a single, monolithic cryptographic hash of the entire file as a whole, it lacks the frame-level hashes required by the cloud worker to verify individual sub-sections and cuts. By design our cloud server also doesn't have a copy of Dark Mode captured truth packets.

4. Local Desktop to Cloud Workflow Execution

  • Authenticated Access: Pro subscribers download, install, and log into the Appender desktop application using their verified platform credentials.

  • Local Reference Media: Creators utilize local copies of their target Truth Packets on their physical hard drives. These files act strictly as lightweight Reference Media to enable smooth, real-time scrubbing, cutting, and timeline editing inside the local user interface.

  • Isolated Cloud Assembly: When an edit is finalized, the Appender desktop application transmits only the cryptographically bound Cuts-Only Manifest to the cloud.

  • Zero Client Ingress: The platform's cloud worker has no access to the user's local hard drive. Instead, it reads the frame instructions from the manifest, retrieves the matching, pristine master Truth Packets directly from the platform’s hot storage, verifies the source integrity, and compiles the final authenticated render.