Consent Logs, Provenance, and C2PA: Building an Audit-Ready Data Pipeline

A signed file does not prove you have permission to use it. I’d build an audit-ready pipeline around 3 linked checks: approved use, file history, and signature validation. If any check fails or remains unresolved, block the release.

In this proposed framework, I explain how to:

• Record permissions: Keep consent scope, restrictions, expiration dates, and withdrawals linked to each asset.
• Trace changes: Use W3C PROV to connect source files, processing steps, people, systems, and outputs.
• Check release files: Use C2PA to verify signatures and file bindings - not to establish consent.
• Control delivery: Check permissions, hashes, privacy reviews, and validation results before each export.
• Handle later changes: Trace withdrawals through files and deliveries, record the response, and flag unresolved effects on trained models.

My guiding rule: <u>keep permission checks separate from signature checks</u>. Link both to a read-only audit record so you can explain what was released, who approved it, and why.

Beyond the origin - secure media provenance with C2PA - Charlie Halford - NDC Manchester 2025

Step 1: Record Consent and Withdrawals

Create the permissions register before recording anything that may include people, bystanders, or workplace audio. Record the legal-review outcome and jurisdiction assumptions in the campaign configuration. Each collection event should generate a consent_id that can be checked at release. Link each consent record to the capture_id and asset_id defined above.

Define Required Consent Fields

Require these fields before approving collection. Keep notice, consent, authorization, and eligibility separate. Receiving a notice or passing an eligibility check does not establish permission.

Field group	Required fields
Identity and context	consent_id, pseudonymous contributor_id, campaign, organization, site, jurisdiction, device/session ID, source asset references
Capture and disclosure	Capture start/end, time zone, notice and consent-form versions, language, notice_delivered_at, consent_recorded_at, consent method
Permission scope	Purposes, permitted dataset uses, prohibitions, media and derivative types, customer/recipient restrictions, geography, retention end date
Evidence and review	Evidence reference, cryptographic hash, verification result, eligibility result, reviewer, approval timestamp, legal-review reference
Payment and lifecycle	Compensation amount in USD, payment status and any compensation terms, current status, effective-from time, expiration or retention-end date

Use structured, versioned scope values - not free-text permission notes. List each media type, permitted use, and restriction separately. Unspecified scope is not granted unless an approved legal policy says otherwise.

Store signatures, contact details, and identity evidence in restricted, encrypted storage with role-based access. Ordinary dataset records should reference that evidence rather than contain it. Payment does not establish consent.

Track Permission Changes Without Overwriting Records

Support under_review, granted, expired, and withdrawn. Check permission for each purpose, media type, customer, geography, and retention period - not just the overall status.

For each withdrawal or restriction, append a change_id, request-received and effective timestamps, affected scope, reason code, requester-verification method, reviewer, evidence reference, and notice/response status. State whether the change affects future capture, existing footage, derivatives, or prior deliveries.

When consent is the chosen basis, provide a withdrawal channel comparable to the original consent path. Verify requests without collecting excessive identity information, and send confirmation. California law requires revocation to be available as easily as consent was provided through that mechanism.

Make pending requests and effective restrictions searchable before export, licensing, training, or delivery. Block unresolved permissions and route affected assets for review. Record whether withdrawal triggers deletion, redaction, a retention exception, or suppression of future use.

Consent records must pass review before source footage moves to provenance tracking and signing. Use this review as the gate before lineage mapping and C2PA signing.

Step 2: Track Lineage and Sign Release Assets

Map Sources and Derivatives With W3C PROV

Once consent is approved, create lineage records for the asset and prepare its release snapshot.

In PROV, treat source files, processed clips, annotation sets, and delivery packages as entities. Processing steps are activities; services, people, and organizations are agents. Connect these records with used, wasGeneratedBy, wasAssociatedWith, and wasDerivedFrom. Keep originals intact. When content changes, add new entities and version the metadata.

Each entity should record the IDs defined above, asset type, parent IDs, consent-record references, storage URI or object key, cryptographic hash and hashing algorithm, media properties, capture and ingestion timestamps, creation or invalidation status, transformation activity ID, and retention or deletion date.

Each activity should record input and output hashes, start and end times, tool name and version, parameters or configuration hash, responsible agent, job-log reference, approval status, and exception details. Parent IDs alone do not prove which bytes were processed.

Record type	Purpose	Retention	Mutability	Audit use
Event log	Records actions, times, actors, and results	Policy-defined audit/legal period	Append-only; corrections add events	Checks execution, approvals, and failures
Lineage graph	Connects sources, activities, agents, and outputs	Life of linked assets and deliveries	Preserve old links; append corrections	Traces delivery back to source
Asset metadata	Describes an artifact’s identity and properties	While usable or discoverable	Versioned; preserve prior values	Supports lookup, hash checks, and release review

Create C2PA Manifests at Review Points

Use PROV for internal tracing and C2PA for the release package. Sign assets only when they match the approved consent scope and pass lineage checks.

Create signed manifests at review gates: ingestion, privacy processing, annotation review, and final packaging or export. You don’t need a manifest after every internal operation. Assertions describe provenance facts, the claim references those assertions, and the claim signature authenticates the claim. A content binding connects the manifest to the asset; ingredient references link source assets.

At ingestion, record the source identity and time. For normalization, trimming, redaction, and audio removal, record the relevant actions and link to detailed parameters. For annotation and quality review, link schema versions, decisions, checks, and exceptions. At packaging and export, link component hashes and the delivery ID.

Use supported assertions or labeled custom assertions, and keep detailed job records outside the manifest. Leave out raw contributor identities and consent documents; use controlled references instead. C2PA holds the release snapshot, while PROV holds detailed lineage and responsibility records.

Show a Sample Manifest and Verification Checks

Illustrative only; not production-ready C2PA syntax. This represents the release snapshot derived from the PROV graph.

{
  "manifest_id": "manifest-clip-a91c-v3",
  "asset_id": "clip-a91c",
  "claim_generator": "dataset-pipeline/4.2.1",
  "created": "2026-02-14T16:32:10Z",
  "ingredients": [{
    "asset_id": "source-8f31",
    "relationship": "parent",
    "hash_ref": "sha256:SOURCE_HASH"
  }],
  "assertions": [{
    "action": "privacy.redaction",
    "tool": "redaction-service/2.8.0",
    "timestamp": "2026-02-14T16:30:44Z"
  }, {
    "action": "annotation.completed",
    "schema": "physical-ai-labels/1.3"
  }],
  "content_binding": {
    "type": "hard-binding",
    "hash_ref": "sha256:DERIVATIVE_HASH"
  },
  "claim_signature": {
    "algorithm": "illustrative-signature-algorithm",
    "signature_ref": "sig-clip-a91c-v3",
    "certificate_ref": "cert-pipeline-signing-07"
  }
}

Before accepting an asset, check its manifest structure, claim signature, content binding, certificate-chain trust, revocation status, and credential validity at signing time. A certificate that has since expired does not automatically fail validation. Check signing-time evidence and preserve unresolved results.

Resolve ingredients, compare actions and hashes with the lineage graph and job logs, and flag unexpected changes or missing links. Save each validation outcome separately, along with the validator version, validation time, trust-list or ruleset version, warnings, and exceptions.

Feed these validation results into the release gate in Step 3.

Step 3: Check Releases and Handle Withdrawals

This workflow connects consent, provenance, and C2PA at release time.

Link Records From Collection to Delivery

Use the validated manifest from Step 2 as the release gate for each delivery.

Illustrative warehouse workflow:

1. Register and ingest

Register consent-00421, link it to the collection event, and record the permitted purpose, recipient class, geography, expiration, and withdrawal channel. Ingest src-warehouse-2025-0017 and record its SHA-256 hash, storage location, capture device, ingestion timestamp, and ingesting service identity. Link src-warehouse-2025-0017 to consent-00421 and record the approved scope. This establishes the consent record for later checks.

2. Process and verify

Record redaction-service@v3.4.1, code version, configuration, input and output hashes, timestamp, and operator or service identity. Create clip-warehouse-2025-0017-r1 and link it to the source with the selected time range, redaction operation, and processing result. Perform privacy-sensitive exposure checks and record the reviewer and evidence reference. Sign the approved clip with a C2PA manifest identifying the source ingredient, redaction action, processing tool, output hash, signing certificate, and timestamp. This creates the signed derivative for release review.

Carry the same IDs forward so the release decision links consent, lineage, manifest, and delivery.

3. Approve and monitor

Before release, verify consent scope, lineage, hashes, privacy checks, and C2PA validation. Create delivery-2025-0088 for the approved export package and manifest, recording their hashes, recipient, approved purpose, license terms, access expiration, and release reviewer. Connect these records in the audit index and monitor withdrawals, corrections, expiration, processing defects, and signing-key events. This creates the delivery record used for audit and withdrawal tracking.

Give recipients a delivery-specific audit summary, not participant records. Include the export hash, dataset ID, manifest ID, consent status, privacy result, validation result, and audit contact. Redact direct identifiers and sensitive footage unless disclosure is necessary and separately authorized. Keep the validation timestamp in the audit index so reviewers can reconstruct the release decision.

Block Releases That Fail Audit Checks

Use the audit index to enforce a fail-closed release gate. Block consent-based releases when consent is missing, unverifiable, expired, withdrawn, or outside the approved scope. Also block releases with missing parents, mismatched hashes, incomplete or unverified privacy processing, unapproved export contents, or failed C2PA validation.

Record machine-readable outcomes such as BLOCKED_CONSENT and BLOCKED_PRIVACY. Route consent issues to privacy or legal, lineage issues to the dataset owner, and credential failures to security. Preserve the failed check, evidence, named approver, decision time, and any exception deadline. Never overwrite the original failure. A valid C2PA signature does not prove lawful permission.

Apply Withdrawals to Linked Assets and Deliveries

When consent changes, carry that event through every linked record. If consent-00421 is withdrawn, block new consent-based processing and deliveries. Then trace the links through sources, clips, shards, indexes, and exports.

Revoke access and append an event for each quarantine, deletion, reprocessing, replacement, or retention exception. Link every remediation event to the original consent ID and delivery ID. Review prior deliveries for notification, deletion, replacement, or access suspension duties. Where available, link affected training-run IDs, dataset versions, and run dates.

Deleting footage does not establish that its influence has been removed from trained models. Document unresolved downstream effects in the audit index. Have legal reviewers map retention and remediation decisions to applicable U.S. privacy, labor, biometric, and contractual requirements.

Conclusion: Keep Audit Records Ready

Link consent, provenance, and C2PA so each release can be traced from permission to delivery. Check permission separately from signature validity. Keep that trail intact through consent collection, processing, signing, release approval, withdrawal handling, and post-release review.

Assign one owner and one backup for each record type: legal operations for consent, data governance for lineage and retention, engineering for processing records, security for access, and the release owner for C2PA evidence. Review withdrawals immediately, access and exceptions monthly, source-to-delivery samples quarterly, and retention rules, notices, and signing certificates annually.

Use the Minimum Audit Checklist

Keep enough evidence to reconstruct every release package without searching across systems. Treat the following as required linked records:

• [ ] Notice version, language, and acknowledgment method; consent ID, subject or representative reference, approved scope, expiration, restrictions, and authenticated permission-change and withdrawal history.
• [ ] Capture-session, site, device or operator, and asset IDs; standardized timestamps; source and derivative hashes; parent-child links; and W3C PROV-style lineage.
• [ ] Processing steps, parameters, software and model versions, and operator or service identity.
• [ ] Safety, quality, and legal-review decisions, approver IDs, and approval conditions.
• [ ] C2PA manifest IDs, signing identity, certificate status, content-binding result, ingredient references, verification-tool version, and verification outcome.
• [ ] Delivery manifest, dataset or release version, recipient, access-grant ID, delivery timestamp, and transfer checksum.
• [ ] Exceptions, failed checks, quarantine decisions, deletions, redactions, replacement assets, withdrawal outcomes, and unresolved issues.

For every record category, document the retention period, owner, permitted roles, storage location, legal-hold rules, and disposal method. Apply least-privilege access and keep proof of disposal. Store sensitive identity records separately from processing lineage wherever possible.

Maintain a read-only audit bundle with a human-readable summary and structured records. Include successful and failed verification results so reviewers can reconstruct each decision. Update the bundle after each material change to keep withdrawal, delivery, and verification histories aligned.

FAQs

How should we handle consent for incidental bystanders?

Set clear privacy and safety rules before recording, and identify anyone likely to appear. Get written permission from everyone recorded. A participant’s release does not cover coworkers or bystanders.

If bystanders are recorded without explicit consent, use automatic redaction before delivery. Then have a person check that no personal information remains exposed. Blurring does not replace formal permission.

How can we detect gaps in our audit trail?

Use stable sample IDs to connect source footage or sessions with consent records, processing steps, derived clips, and delivery checksums. Automatically check every delivered episode or file against its recorded history and manifest.

Log unmatched, changed, or missing files, along with any missing consent or provenance fields. Quarantine affected episodes until authorization and permitted-use checks are restored.

Check coverage for each required condition - not just overall totals - to find groups whose accepted counts fall below minimums.

What if withdrawn data already trained a model?

Treat the affected data as restricted. Deleting source files doesn’t prove that the model has deleted or unlearned the data. Handle model removal or retraining as a separate decision, and document it.

Keep an auditable record of the withdrawal, the action taken, and the removal date so each step can be traced. For future use, release a new, versioned dataset that excludes the withdrawn content and meets the updated requirements.

Related Blog Posts

• Error Auditing for Egocentric Task Datasets
• What Is Egocentric Data Collection?
• How to Run an Egocentric Data Collection Program
• Rights-Cleared vs Scraped Training Data: What Actually Holds Up in an Audit