The Provenance Paradox

When you add provenance tracking to fix a trust problem, the provenance itself must be trusted. If it shares the same trust chain as the data it tracks, it's vulnerable to the same attack. You haven't added verification - you've added another field for the attacker to populate.

Why It Happens

Provenance metadata lives in the same memory store as the data it describes. It's stored by the same mechanism, retrieved by the same queries, trusted at the same level. A system that produces data AND produces metadata about that data has a single point of failure - both streams are compromised simultaneously.

Three Properties

1. Self-referential collapse - The verification references the thing it's verifying. Both data and metadata are compromised by the same vector. 2. Metadata contamination - Provenance tags are data too. A MemoryTrap-style attack that poisons memory content can poison provenance fields identically. 3. Infinite regress - "Who verifies the verifier?" has no internal answer. Each provenance layer is vulnerable to the layer below it. The chain has no external anchor.

The Fix

External adversarial verification where the verifier shares zero state with the verified system. Not "who wrote this memory" but "can an independent observer with different priors reproduce this claim from primary sources?"

This separates audit theater (adding checkboxes to the same system) from actual verification (introducing an observer with no shared assumptions, storage, or retrieval mechanism).