Proof as a Reachability Property

Mike Argento

Abstract

Modern computing systems permit durable digital state to be created freely and attempt to establish trust only after that state already exists. This architecture introduces fundamental weaknesses in provenance, AI outputs, sensor data, logs, and media, because authenticity is optional and structurally bypassable. Most widely deployed approaches—signatures, metadata, watermarking, registries, and provenance standards—operate after content has been instantiated and therefore cannot constrain the creation path itself.

This paper introduces a different enforcement model. Provenclave relocates trust to the commit path. Proven durable state is reachable only through enforced finalization via a protected commit interface. An artifact is proven if and only if cryptographic binding and authorization occur inside an atomic execution boundary at the moment durable state is created.

We first present the Trusted Origin Token Architecture, in which proven creation requires consumption of a pre-existing single-use authorization unit at finalization. We then generalize this into Provenclave, in which equivalent origin control is achieved without pre-existing tokens by generating boundary-fresh cryptographic output inside the atomic execution boundary. The enforcement principle that links authorization, binding, and durable commit into a single indivisible event is called Atomic Causality.

We provide a formal model based on labeled transition systems and closure algebras, define a security game capturing the adversarial model, and systematically distinguish this architecture from existing approaches including attested execution, post-hoc provenance, and content credential systems. We show that Provenclave defines a new enforcement primitive: proof as a reachability property of system structure, not a property attached to artifacts after creation.

1 Introduction

Digital systems increasingly mediate information relied upon for scientific, legal, medical, financial, and political decisions. At the same time, synthetic generation, automated manipulation, and adversarial pipelines have become routine. Despite this shift, most computing systems retain an architectural model in which creation is unrestricted and trust is applied only after the fact.

Files are written, messages are emitted, and model outputs are exported without intrinsic proof. Trust is later inferred through signatures, metadata, watermarking, or registry lookups. These mechanisms can indicate that an artifact has not been modified since some point in time, but they cannot prove that the artifact originated from an enforced creation process. Post-hoc trust systems permit syntactically indistinguishable artifacts to exist both with and without provenance guarantees. Downstream systems must therefore rely on voluntary compliance with provenance mechanisms.

Several concurrent developments have made this structural gap acutely consequential. Generative AI systems now produce synthetic artifacts at scale that are indistinguishable from human-authored or sensor-captured content. Regulatory frameworks—including the EU AI Act and evolving compliance mandates—increasingly require that AI-generated and machine-mediated outputs be structurally identifiable, not merely voluntarily labeled. Automated decision pipelines in finance, healthcare, and public administration increasingly consume digital artifacts without human intermediation, removing the informal gatekeeping that previously compensated for weak provenance. These pressures converge on a single architectural deficiency: the absence of structural enforcement at the point where digital state is created.

This paper proposes that the architectural response to this problem is not better verification of existing artifacts, but structural enforcement at the point where digital state becomes durable or externally visible. Trust must be enforced at creation, not inferred afterward.

A corollary of this principle is that enforcement and verification are architecturally distinct: enforcement determines whether proven state exists; verification determines whether that status can be demonstrated to a third party. This separation is developed formally in Section 9.4.

Provenclave is not a replacement for attestation, provenance, or access control. It is a lower-layer enforcement primitive that existing systems can adopt to close the structural gap between trusted code execution and controlled state creation. Systems that already implement TEEs, content credentials, or hardware roots of trust can implement Provenclave to strengthen the enforcement guarantees those mechanisms provide.

Non-Goal. This architecture does not attempt to establish the semantic truth, correctness, or factual validity of content. It enforces only whether content has been admitted into proven durable state through protected finalization semantics.

2 The Problem: Uncontrolled Digital State Creation

In contemporary computing systems, any process capable of reaching commit paths—writes to persistent storage, publications to output channels, exports of artifacts—can create durable digital state. Proof mechanisms are typically external to these creation paths and are applied only if the producing system elects to use them.

This architectural pattern creates several failure modes that no amount of improved verification can resolve:

No enforced origin point.

The first instance of an artifact has no cryptographically constrained birth event. Content enters the world without any structural evidence of how, where, or under what conditions it was created.

Post-hoc wrapping is indistinguishable from legitimate origin.

Synthetic or replayed data can be introduced and later wrapped in authenticity claims—signatures, attestations, metadata—that are structurally indistinguishable from claims attached at genuine creation time.

Trusted pipelines are bypassable.

Even when secure creation paths exist, alternative unproven paths typically remain available. Untrusted components can bypass trusted capture or generation pipelines while still producing durable outputs that appear valid to downstream systems.

Authenticity is optional.

Because creation is unrestricted, authenticity signals are voluntary. Systems degrade into environments where proven and unproven artifacts coexist, and downstream consumers cannot reliably distinguish them by structural properties.

The common thread across these failure modes is that post-hoc provenance secures history but does not constrain birth. The question is not whether we can build better verification after the fact, but whether we can enforce the conditions under which proven digital state is permitted to exist at all.

2.1 A Concrete Example: Why Attestation Is Not Enough

To make these failure modes precise, consider a system that appears to solve the problem using current best practices but does not.

A secure camera device contains a Trusted Execution Environment. The camera pipeline feeds sensor data into the TEE. Inside the TEE, trusted code hashes the image, signs the hash with a hardware-protected key, and emits a signed manifest alongside the image file. A verifier can confirm that the image was processed by trusted code running on authentic hardware. This is a well-designed attestation system.

Now consider the attack. The adversary does not compromise the TEE. Instead, the adversary feeds synthetic frames into the camera pipeline's input buffer—upstream of the TEE, at the sensor interface. The TEE faithfully processes the synthetic data: it hashes the synthetic image, signs the hash, and emits a valid signed manifest. From the verifier's perspective, the attestation is correct. Trusted code did execute on authentic hardware. The signature is valid. But the image is synthetic.

The attestation answered the question it was designed to answer: "Did trusted code produce this signed output?" Yes. But the system failed because attestation does not answer a different question: "Could signed output have been produced for content that did not originate from the intended source?" The attested pipeline was not bypassed—it was correctly traversed with adversarial input, because alternative input paths to the attested process were not closed.

This is not a flaw in the TEE or in the attestation protocol. It is a structural gap in the system architecture. The commit path—the path by which proven state comes into existence—was not exclusively controlled. The TEE enforced the integrity of its own execution but did not enforce that the only way to reach proven output was through a creation path that included genuine sensor capture.

2.2 A Second Example: Provenance Without Enforcement

Consider a parallel failure in provenance systems. A photographer captures an image with a C2PA-enabled camera. The camera attaches a signed content credential manifest describing the capture device, timestamp, and edit history. A news platform verifies the manifest and publishes the image with provenance intact.

A social media platform then ingests the published image, strips the C2PA manifest (as most platforms currently do), and redistributes it. A downstream consumer receives the image without provenance metadata. Under C2PA, the image is now indistinguishable from an unsigned image. The provenance was real but impermanent—it depended on the manifest traveling with the artifact through every intermediary. When the manifest was stripped, the provenance guarantee evaporated.

The underlying issue is the same as the camera example: the system proved an artifact at one point in time but did not structurally constrain how proven state persists or is verified across distribution. Provenance was a property of the packaging, not a property of the artifact's relationship to its genesis event.

2.3 A Third Example: Ledger Registration Without Creation Constraint

Consider a document notarization service backed by a blockchain or append-only ledger. A user submits a document hash to the service. The service records the hash with a consensus-verified timestamp, producing an immutable ledger entry proving that the hash existed at a specific time. A verifier can later confirm that the document's hash was registered and has not been altered since registration.

Now consider the gap. The adversary generates a synthetic document—fabricated financial records, a forged legal instrument, or AI-generated imagery—and submits its hash to the same notarization service. The ledger faithfully records the hash with an accurate timestamp. The notarization is genuine: the hash was indeed registered at the stated time. But the document is fabricated.

The ledger answered the question it was designed to answer: "Did this hash exist at this time?" Yes. But it did not answer a different question: "Was this document produced through an authorized creation process?" The notarization system provides strong history guarantees—immutability, ordering, non-repudiation of registration—but imposes no constraint on how the artifact came into existence before registration. Any content, from any source, produced by any process, can be notarized. The creation path is uncontrolled.

These three examples—in attestation, provenance, and ledger-based notarization—illustrate the same architectural gap from different angles. The security-relevant question is not whether a trusted process ran, whether a manifest was attached, or whether a hash was recorded. It is whether proven state is structurally unreachable except through authorized creation paths, and whether that relationship between artifact and genesis can survive distribution.

3 Definitions and Terminology

Definition 3.1 (Atomic Execution Boundary). A protected execution domain that enforces isolation and ordering constraints for finalization, such that cryptographic computation, authorization, and durable commit occur as one indivisible operation or not at all. If the operation fails, no proven durable artifact is produced.

Definition 3.2 (Protected Commit Interface). The sole interface permitted to finalize proven durable state. Untrusted code cannot produce proven durable state except by invoking this interface, which transfers control into the atomic execution boundary.

Definition 3.3 (Boundary-Held Capability). A capability available only inside the boundary and required to complete proven finalization. Possession of data outside the boundary is insufficient to reproduce or invoke it.

Definition 3.4 (Boundary-Fresh Cryptographic Computation). Cryptographic computation performed inside the boundary using one or more freshness sources (secure randomness, monotonic counters, protected clocks, or boundary-internal state), such that the resulting output was not available before the finalization event and cannot be feasibly reproduced outside the boundary. Freshness may be expressed using logical time (epochs or counters) or protected physical clocks. No global wall-clock synchronization is required.

Definition 3.5 (Candidate Digital State). Transient, internal, mutable representations of content prior to finalization. Candidate state may be created freely and may be adversarial.

Definition 3.6 (Proven Durable State). Externally visible or persistent digital state whose proven form includes verification material evidencing enforced finalization through a protected commit interface.

Definition 3.7 (Binding). A cryptographic construction that combines boundary-fresh output with a content-dependent value (e.g., a hash of the artifact bytes) to produce verification material.

Definition 3.8 (Verification Material). Data bound to content and to boundary-fresh output that enables a verifier to distinguish proven durable state from unproven state using pre-distributed trust anchors, without querying an external registry of artifacts.

Definition 3.9 (Authorization). Successful use of a boundary-held capability via the protected commit interface to complete proven finalization. Authorization here refers to enforced finalization capability, not to post-hoc policy claims attached to content.

Remark (Proof). Throughout this paper, a proof refers to the verification material produced at genesis (Definition 3.8) together with the artifact bytes it binds. It is not used in the mathematical sense of a logical derivation.

4 System Invariants

If Provenclave is correctly implemented, the following invariants hold:

Invariant 4.1 (Proven Reachability). Proven durable state exists if and only if a successful finalization event occurred inside an approved atomic execution boundary.

Invariant 4.2 (Binding Evidence). Every proven artifact has associated verification material—produced at genesis—that binds its content to boundary-fresh cryptographic output and to a specific boundary identity. This material may be co-located with the artifact, held at a reference point, or both. (A reference point stores verification evidence produced at genesis; it does not confer proven status and plays no role in enforcement. See Section 9.5.)

Invariant 4.3 (Policy-Anchored Verification). An artifact verifies if and only if its verification material validates under accepted trust anchors and applicable policy constraints.

Invariant 4.4 (Distinguishability). Durable state not produced via boundary finalization cannot satisfy verification and is therefore distinguishable from proven durable state.

Invariant 4.5 (Provenness as Reachability). Proven durable state is defined by enforced state transitions, not by post-hoc claims, metadata, or byte-level identity.

The significance of Invariant 4.5 deserves emphasis. In conventional systems, authenticity is a label: a property that can be attached to, claimed about, or inferred from an artifact after it exists. Under Provenclave, provenness is a reachability property: a consequence of the state transitions that produced the artifact. An artifact does not become proven by having the right metadata. It is proven because it could only have come into existence through a path that enforced authorization, cryptographic binding, and durable commit as a single indivisible event. The proven state space is closed under authorized genesis—nothing else can produce it.

This is the central claim of the paper: if proven digital state can only come into existence through a controlled creation path, then the existence of a proven artifact is itself proof that the creation path was traversed. Proof becomes a reachability property of system architecture—a consequence of how state transitions are structured—rather than a label applied to artifacts after the fact.

Returning to the camera example from Section 2.1: under Provenclave, the system would not merely attest that trusted code ran. It would enforce that proven image output is structurally unreachable except through a commit path that includes sensor capture within the atomic execution boundary. The adversary's synthetic frames would not produce proven output, because the commit path would require that sensor acquisition, hashing, binding, and durable commit all occur within the same indivisible boundary event. Feeding synthetic data to the input buffer would bypass the authorized creation path entirely, and the protected commit interface would never be invoked through the sensor-capture path for that data. The result: no proven artifact is produced.

Returning to the provenance example from Section 2.2: under Provenclave with reference-based verification (described in Section 9.5), the downstream consumer could still verify the stripped image by computing its content hash and querying a reference point for the verification material produced at genesis. Proof would survive distribution because it was established by the artifact's structural relationship to its creation event, not by metadata co-traveling with the artifact.

5 Trusted Origin Token Architecture

We begin with a concrete model that makes the enforcement principle tangible before generalizing.

The Trusted Origin Token Architecture addresses uncontrolled digital state creation by introducing a pre-creation authorization requirement. Proven creation requires consumption of a pre-existing single-use authorization unit—a Trusted Origin Token—at the moment of finalization. Tokens are generated in advance, tracked as unused or consumed, and cannot be reused.

Under this model, a system may prepare candidate data freely, but finalization into proven durable form is permitted only if a valid unused token is consumed during the same atomic operation that commits the artifact.

The key insight is best understood through analogy. Before digital cameras, a photograph could only exist if film existed first. The film did not merely record the image—it enforced whether the image could exist at all. No film, no photograph, regardless of the camera, the scene, or the photographer's intent. The Trusted Origin Token Architecture enforces the same constraint digitally: no token, no proven artifact.

5.1 Functional Properties

Property 5.1 (Scarcity). Each proven artifact corresponds to exactly one token that existed prior to creation.

Property 5.2 (Non-Replay). Tokens cannot be reused. Each token authorizes exactly one finalization event.

Property 5.3 (Non-Retroactivity). Tokens cannot be applied after durable state already exists. Authorization must occur at the moment of finalization, not afterward.

Property 5.4 (Commit-Path Enforcement). Token consumption and finalization occur within the same indivisible operation.

The Trusted Origin Token Architecture ensures that proven durable state cannot exist unless a pre-authorized unit is irreversibly consumed at birth.

5.2 Limits of Token-Based Enforcement

While the token model provides a clear and intuitive model of origin control, it introduces operational complexity. Tokens must be generated, stored, distributed, tracked, and reconciled across systems. Registries or equivalent state-tracking mechanisms must exist to enforce single-use guarantees. Offline operation requires reconciliation logic, and token provisioning becomes infrastructure-coupled to production systems.

More importantly, tokens are not the fundamental source of trust. What matters is not the consumption of a specific pre-existing object, but that an irreversible, non-repeatable authorization event occurred at the moment of finalization and could not be replayed or forged. This observation motivates a more general enforcement principle.

6 Provenclave and Atomic Causality

The Trusted Origin Token Architecture reveals a structural principle that is more general than tokens. What enforced origin control in TOTA was not the token itself—it was the fact that proven state was structurally unreachable without traversing a protected commit path that combined authorization, binding, and commit into a single indivisible event. Tokens enforced this by requiring consumption of a pre-existing resource. But any mechanism that makes proven state unreachable without an irreversible authorization event at the commit boundary achieves the same enforcement.

Provenclave generalizes this principle. Instead of consuming a pre-generated token, the enforcement component generates a boundary-fresh cryptographic value $N$ during the atomic finalization event. Cryptographic unpredictability and negligible collision probability prevent precomputation, reuse, or accidental duplication.

The reader should note what changed and what did not. What changed is the mechanism: tokens are replaced by boundary-fresh generation. What did not change is the enforcement invariant: proven durable state remains structurally unreachable without an irreversible authorization event inside the atomic execution boundary. The invariant is the primitive. The mechanism is an implementation detail.

This value serves the same functional role as a consumed authorization unit:

It could not have existed prior to the finalization event.
It could not have been predicted or precomputed.
It cannot be recreated after the event.
Its existence constitutes cryptographic evidence that a specific, irreversible finalization event occurred.

TOTA: Token Consumption

Token Pool T₁, T₂, … Tₙ

↓

Consume T_k

↓

Bind (H, T_k)

↓

Commit

↓

Proven
Artifact

1 token → 1 artifact

≡

same injective
genesis

Provenclave: Boundary-Fresh Generation

Freshness Source CSPRNG

↓

Generate N

↓

Bind (H, N)

↓

Commit

↓

Proven
Artifact

1 nonce → 1 artifact

TOTA: Token Consumption

Token Pool T₁, T₂, … Tₙ

↓

Consume T_k

↓

Bind (H, T_k)

↓

Commit

↓

Proven Artifact

1 token → 1 artifact

≡

same injective genesis

Provenclave: Boundary-Fresh Generation

Freshness Source CSPRNG

↓

Generate N

↓

Bind (H, N)

↓

Commit

↓

Proven Artifact

1 nonce → 1 artifact

Figure 1. Token–Nonce duality. TOTA (left) consumes a pre-existing token from a finite pool. Provenclave (right) generates a boundary-fresh value from a cryptographic source. Both enforce the same invariant: each proven artifact corresponds to exactly one irreversible authorization event (injective genesis). Collision resistance makes boundary-fresh generation operationally equivalent to token consumption.

The equivalence shown in Figure 1 is structural, not operational. The reader should resist the interpretation that Provenclave merely replaces physical tokens with virtual ones. The insight is the reverse: TOTA is a special case of Provenclave in which the authorization event happens to be reified as a consumable object. Provenclave reveals that the underlying enforcement primitive is not the token but the structural constraint—that proven state is unreachable without an irreversible authorization event at the commit boundary. Tokens enforce this by depletion; boundary-fresh generation enforces it by cryptographic causality. The primitive is the constraint, not the mechanism.

Similarly, the boundary-fresh value $N$ should not be understood as merely a "nonce for replay protection." In conventional protocols, nonces prevent message replay. In Provenclave, the boundary-fresh value is the authorization event itself—its generation inside the boundary constitutes the irreversible act that gates the creation of proven state. Producing valid verification material is proof that this act occurred, not merely that a unique value was included.

6.1 Atomic Causality

Under Atomic Causality, three operations are linked into a single indivisible event inside an atomic execution boundary, completed only through a protected commit interface requiring a boundary-held capability:

Authorization: A boundary-held capability is exercised.
Cryptographic binding: Boundary-fresh output is bound to a content-dependent value.
Durable commit: The proven artifact is committed to persistent storage or an output channel.

Proven durable state is reachable only if these operations occur together, in order, within the same atomic execution boundary. If any step fails, no proven artifact is produced.

Provenclave: Atomic Causality

1. Authorize

↓

2. Bind

↓

3. Commit

single atomic operation

✓

Non-Provenclave: Separated Steps

1. Authorize

↓ ← observable gap

2. Bind

↓ ← observable gap

3. Commit

✗

Provenclave: Atomic Causality

1. Authorize

↓

2. Bind

↓

3. Commit

single atomic operation ✓

Non-Provenclave: Separated Steps

Authorize

↓ (separate call)

Bind

↓ (separate call)

Commit

gap allows bypass ✗

Figure 2. Atomic Causality versus separated operations. In Provenclave (left), authorization, binding, and commit occur as a single indivisible event inside the boundary with no externally observable intermediate states. In non-Provenclave systems (right), these are separate operations with observable gaps exploitable by adversaries.

6.2 Why This Is Not Attested Execution

This enforcement model is not equivalent to conventional attested execution followed by signing. The distinction is precise and consequential.

Attestation-based systems can demonstrate that particular trusted code executed and produced particular signed outputs. This answers the question: "Was this artifact produced by trusted code?" But attestation does not answer a different and more fundamental question: "Could an artifact not produced by trusted code have entered this trust domain through any available commit path?"

In most attestation-based systems, enforcement is advisory. Trusted processes may produce signed outputs, while untrusted processes may still produce durable state that enters downstream systems through alternative commit paths. The enforcement gap is not in the attested path—it is in the unattested paths that remain open.

Provenclave closes this gap. Proven durable state is reachable only through protected commit paths that enforce atomic binding, authorization, and durable commit at the moment of finalization. Valid verification material implies not merely that trusted code ran, but that no alternative path to proven state exists. This is a structural property of the commit architecture, not a property of any single attested process.

6.3 Token-Equivalence of Boundary-Fresh Generation

Token-equivalence does not arise from uniqueness alone. It arises from atomic, attested finalization that combines several properties: boundary isolation ensures the fresh output is generated only inside the atomic execution boundary; unpredictability prevents adversaries from predicting or precomputing valid values; binding ties the fresh output to a content-dependent value before commit; a boundary-held authorization capability gates finalization; and attestation or signing produces verification material validatable under accepted trust anchors.

Together, these properties ensure that producing valid verification material implies that a specific authorization event occurred inside the boundary at finalization time. The fresh value $N$ functions as a consumed authorization unit whose existence is cryptographic evidence of an irreversible finalization event—not merely a unique identifier. To be precise: the fresh value alone does not constitute authorization. Authorization arises from the indivisible combination of boundary isolation, capability-gated access, atomic binding, and freshness—no single property is sufficient, and removing any one breaks the enforcement guarantee.

Functionally, the space of possible boundary-fresh outputs acts as an effectively inexhaustible universe of unused authorization units, and generating one during finalization constitutes irreversible consumption. Each accepted artifact necessarily corresponds to exactly one irreducible authorization event, making boundary-fresh outputs operationally equivalent to single-use tokens even without explicit allocation or tracking.

7 Formal Model

We formalize Provenclave using a labeled transition system and closure algebra. This formalization captures the essential properties of the architecture and enables precise comparison with existing enforcement models.

7.1 State Space and Transition System

Definition 7.1 (Provenclave System). A Provenclave system is a labeled transition system $(\Sigma, \rightarrow, E)$ where:

$\Sigma$ is the state space, partitioned into $\Sigma_{\text{proof}} \cup \Sigma_{\text{unproof}}$.
$\rightarrow \,\subseteq \Sigma \times E \times \Sigma$ is the transition relation labeled by events $E$.
$E_{\text{proof}} \subseteq E$ is the set of authorization events.
$\mathcal{C} \subseteq \Sigma \times E_{\text{proof}} \times \Sigma_{\text{proof}}$ is the genesis constructor relation.

The genesis constructor relation $\mathcal{C}$ captures the protected commit interface: it is the only relation that produces elements of $\Sigma_{\text{proof}}$. Candidate state in $\Sigma_{\text{unproof}}$ may be created freely by any process.

7.2 Core Invariants

A Provenclave-compliant system enforces three invariants:

Invariant 7.2 (Constructibility — Closure Property). \[\forall\, s' \in \Sigma_{\text{proof}} : s' \in \mathrm{Cl}_{\mathcal{C}}(E_{\text{proof}})\] where $\mathrm{Cl}_{\mathcal{C}}(E_{\text{proof}}) = \{ s' \mid \exists\, s \in \Sigma,\, e \in E_{\text{proof}} : (s, e, s') \in \mathcal{C} \}$.

Every element of the proven state space was produced by a genesis constructor under an authorized event.

Invariant 7.3 (Constructor Completeness — Unforgeability). \[\forall\, s, s', e :\; (s \xrightarrow{e} s' \;\wedge\; s' \in \Sigma_{\text{proof}}) \;\Rightarrow\; (e \in E_{\text{proof}} \;\wedge\; (s, e, s') \in \mathcal{C})\]

All transitions into the proven state space are genesis constructors under authorized events. There is no transition into $\Sigma_{\text{proof}}$ that bypasses $\mathcal{C}$.

Invariant 7.4 (Atomic Causality — Indivisibility). \[\forall\, (s, e, s') \in \mathcal{C} :\; \text{authorize}(e),\; \text{bind}(e),\; \text{commit}(s')\] occur in a single atomic transition with no intermediate states observable outside the protected boundary.

Authorization, cryptographic binding, and durable commit are inseparable within the atomic execution boundary.

7.3 Proven State as Closure Algebra

The proven state space $\Sigma_{\text{proof}}$ forms a closure space generated by authorization events through genesis constructors. Formally, define the closure operator: \[\mathrm{Auth} : \mathcal{P}(\Sigma) \rightarrow \mathcal{P}(\Sigma), \quad \mathrm{Auth}(S) = \{ s' \mid \exists\, e \in E_{\text{proof}},\; s \in S : (s, e, s') \in \mathcal{C} \}\]

The invariant $\Sigma_{\text{proof}} = \mathrm{Cl}_{\mathcal{C}}(E_{\text{proof}})$ states that the proven state space is exactly the closure under authorized genesis. This makes proof a topological property of the system's state space rather than a local property of individual artifacts.

This formulation connects to existing mathematical structures:

Order theory: $\Sigma_{\text{proof}}$ forms a Moore family (closed under arbitrary intersections of compliant subsets).
Type theory: Genesis constructors are the sole constructors of an abstract data type; $\Sigma_{\text{proof}}$ has private constructors.
Provenance: Unlike provenance semirings [8], which annotate data with origin information, Provenclave enforces that proven state can only exist if it has authorized genesis—enforcement, not annotation.

7.4 Token–Nonce Duality

The Trusted Origin Token Architecture and Provenclave enforce the same injective genesis invariant through dual mechanisms:

Definition 7.5 (Injective Genesis). A system enforces injective genesis if and only if the map $\varphi : E_{\text{proof}} \rightarrow \Sigma_{\text{proof}}$ defined by $\varphi(e) = s'$ where $(s, e, s') \in \mathcal{C}$ is an injection. Each authorization event produces at most one proven artifact, and each proven artifact corresponds to exactly one authorization event.

Token Conservation (TOTA). Authorization events are reified as consumable tokens. Consumption tracking enforces $|\text{tokens consumed}| = |\Sigma_{\text{proof}}|$. This is a depletable resource model analogous to affine types in linear logic.

Boundary-Fresh Uniqueness (Provenclave). Authorization events are boundary-generated values whose cryptographic freshness ensures uniqueness. Each value appears in exactly one proven artifact. This is a unique generator model analogous to existential types with freshness guarantees.

Under perfect cryptography and uncompromised boundary assumptions, these mechanisms are cryptographic duals: they enforce the same cardinality constraint $|E_{\text{proof}}| = |\Sigma_{\text{proof}}|$ through isomorphic algebraic structures—consumable resources versus generative uniqueness. The token model makes injectivity definitional; the boundary-fresh model makes injectivity derived from collision resistance and freshness guarantees.

Remark 7.6 (Structural Non-Reusability). Injective genesis ensures that no authorization event can contribute to more than one proven artifact, and no proven artifact can exist without a unique authorization event. Authorization events are irreversible state transitions—once an event has produced a proven artifact, it is permanently consumed by that production and cannot be replayed, redirected, or shared. This is a structural property of the genesis constructor, not a bookkeeping constraint enforced by external tracking.

Readers familiar with distributed ledger systems may recognize an analogy to double-spend prevention. The invariant is similar—$|E_{\text{proof}}| = |\Sigma_{\text{proof}}|$ ensures one-to-one correspondence—but the enforcement mechanism is fundamentally different. In ledger systems, double-spend prevention requires global consensus over a shared transaction history. In Provenclave, non-reusability is enforced locally by the atomic execution boundary: boundary-fresh generation produces a value that is cryptographically bound to exactly one artifact at exactly one finalization event, with no external coordination required.

8 Adversarial Model and Security Game

We define a security game that captures the adversarial setting in which Provenclave operates.

8.1 Threat Model

The adversary $\mathcal{A}$ is assumed to possess:

Full control of application code executing outside the atomic execution boundary.
Control of storage systems and network transport.
The ability to replay, substitute, or synthesize candidate data.
Access to all previously produced proven artifacts and their verification material.

The adversary does not possess:

The ability to execute code inside the atomic execution boundary.
Access to boundary-held capabilities (signing keys, capability tokens).
The ability to predict or reproduce boundary-fresh cryptographic output.

8.2 Security Game: Origin Forgery

Definition 8.1 (Origin Forgery Game). The game $\mathrm{Forge}_{\mathcal{A}}^{\mathrm{Pret}}(\lambda)$ proceeds as follows, where $\lambda$ is the security parameter:

Setup. The challenger initializes a Provenclave system with boundary identity $\mathit{id}$, trust anchors $\mathit{TA}$, and security parameter $\lambda$.
Query phase. The adversary $\mathcal{A}$ may submit candidate data to the protected commit interface and observe the resulting proven artifacts and verification material. The adversary may make polynomially many such queries.
Forgery. The adversary outputs a candidate artifact $a^*$ and verification material $v^*$.
Win condition. $\mathcal{A}$ wins if:
- $(a^*, v^*)$ verifies under trust anchors $\mathit{TA}$, and
- $(a^*, v^*)$ was not produced by any query to the protected commit interface.

Definition 8.2 (Provenclave Security). A Provenclave system is secure if for all probabilistic polynomial-time adversaries $\mathcal{A}$: \[\Pr[\mathrm{Forge}_{\mathcal{A}}^{\mathrm{Pret}}(\lambda) = 1] \leq \mathrm{negl}(\lambda)\]

Proposition 8.3 (Security Reduction). If the signature scheme is existentially unforgeable under chosen-message attack (EUF-CMA) and the freshness source is collision-resistant, then the Provenclave system is secure under Definition 8.1.

Proof sketch. Suppose adversary $\mathcal{A}$ wins the Origin Forgery Game with non-negligible probability. Then $\mathcal{A}$ has produced verification material $(a^*, v^*)$ that validates under trust anchors $\mathit{TA}$ without invoking the protected commit interface. The verification material includes a signature over a binding of boundary-fresh output $N^*$ and a content-dependent value $H^*$. Since $\mathcal{A}$ did not invoke the boundary, either: (a) $\mathcal{A}$ forged the signature, contradicting EUF-CMA security; or (b) $\mathcal{A}$ reused a boundary-fresh value $N$ from a previous query with different content, contradicting binding integrity; or (c) $\mathcal{A}$ replayed an exact $(a, v)$ pair from a previous query, which fails the win condition. Therefore no PPT adversary wins with non-negligible probability.

This reduction relies on two distinct classes of assumption: cryptographic assumptions (EUF-CMA signature security, collision resistance of the freshness source) and architectural assumptions (boundary isolation, non-extractability of signing keys, atomicity of the commit operation). The cryptographic assumptions are standard and reducible to well-studied hardness problems. The architectural assumptions define the trusted computing base and must be enforced by the boundary implementation; they are not modeled cryptographically but are explicit preconditions of the threat model defined in Section 8.

8.3 Falsifiable Distinctions

The following tests distinguish Provenclave-compliant systems from systems that appear similar but fail to enforce origin control.

F1: Post-hoc Annotation.

If there exists a function $f: \Sigma_{\text{unproof}} \rightarrow \Sigma_{\text{proof}}$ that promotes unproven state to proven state while preserving content, the system is not Provenclave-compliant. This test fails for any system where content is created first and proof is applied afterward—signing, blockchain registration, provenance database entry, or metadata attachment. These are annotation systems, not origin enforcement.

F2: Unconfined Constructor.

If the genesis constructor can be invoked from contexts outside the protected boundary, the system violates constructor completeness. This test fails when signing keys are accessible to application code, when the commit interface is a public API without boundary isolation, or when trusted and untrusted code share execution context.

F3: Authorization Forgery.

If an adversary without boundary access can produce events $e$ satisfying $\mathrm{authorized}(e) = \mathrm{true}$, the system violates unforgeability. This test fails when signing keys are extractable, when tokens can be synthesized without authority, or when capabilities can be delegated outside the boundary.

F4: Observable Atomicity Break.

If the genesis transition can be decomposed into externally observable intermediate steps—authorization at time $t_1$, binding at $t_2 > t_1$, commit at $t_3 > t_2$—the system violates Atomic Causality. This test fails for systems where authorization checking, signing, and storage commit are separate API calls, creating time-of-check-to-time-of-use vulnerabilities.

F5: Retroactive Proof.

If durable state can be created first and then promoted to proven form by any post-hoc operation that preserves content, the system is implementing annotation, not origin control. This is the most direct test: if the content bytes can exist before the authorization event, the system does not enforce Provenclave.

9 Architecture

9.1 State Transition Model

Provenclave distinguishes between candidate digital state and proven durable state. Candidate state may exist anywhere and may be adversarial. Proven durable state consists of externally visible or persistent artifacts whose proven form includes verification material produced by enforced finalization.

The transition from candidate to proven occurs at commit paths: file writes, storage uploads, message publication, model output export, sensor data release, and log entry creation.

This transition is mediated by four architectural components: an atomic execution boundary, boundary-fresh cryptographic computation, a protected commit interface, and a boundary-held capability. Outside the boundary, systems may generate arbitrary data. The proven durable form is unreachable without successful finalization.

Candidate
Digital State

(created freely)

submit

→

ATOMIC EXECUTION BOUNDARY

Protected Commit
Interface

finalize

→

Proven
Durable State

(includes verification material)

✗ no direct path from candidate state to proven state

Candidate Digital State
(created freely)

submit ↓

ATOMIC EXECUTION BOUNDARY

Protected Commit Interface

finalize ↓

Proven Durable State
(includes verification material)

✗ no direct path from candidate to proven state

Figure 3. State transition model. Proven durable state is reachable only through the protected commit interface inside the atomic execution boundary. No direct path from candidate state to proven state exists.

9.2 Atomic Finalization Protocol

Atomic finalization proceeds as a single ordered operation:

Candidate state is prepared outside the boundary.
The request enters the protected commit interface and crosses into the atomic execution boundary.
Boundary-fresh cryptographic output $N$ is generated.
A content-dependent value $H$ is computed (e.g., a cryptographic hash of the artifact).
Binding material is produced over $(H, N)$.
Authorization is performed using a boundary-held capability.
Proven durable state and verification material are committed.

If any step fails, no proven durable state is produced. The system is fail-closed: failures prevent proven creation rather than producing ambiguous or partially proven outputs.

9.3 Verification Model

Verification relies on cryptographic attestation produced by the atomic execution boundary over the binding between content and boundary-fresh output. Concretely, the boundary produces verification material covering: the content-dependent value $H$, the boundary-fresh output $N$, and optional policy or context metadata. This material is signed or attested using boundary-held cryptographic keys.

Verifiers accept artifacts only if the verification material validates under approved trust anchors, which may include pinned boundary public keys, manufacturer or platform roots certifying boundary identities, or signed domain policy manifests specifying acceptable boundary identities, epochs, and validity windows.

No registry of artifacts is required. Verifiers need not identify the producing application—only that the artifact could not have been finalized outside an approved boundary under accepted policy.

9.4 Enforcement and Verification Are Separate Architectural Layers

A distinction fundamental to Provenclave must be stated explicitly. Enforcement determines whether proven durable state exists. Verification determines whether a third party can demonstrate that proven durable state exists. These are different properties operating at different architectural layers.

Enforcement is irrevocable. Once candidate state has been finalized through the protected commit interface—once authorization, binding, and durable commit have occurred as a single atomic event inside the boundary—the resulting artifact is proven. This is a historical fact about the artifact's genesis, not a claim that depends on the continued availability of any proof material.

Verification is operationally contingent. A verifier can confirm an artifact's proven status only if verification material is accessible—either co-traveling with the artifact or retrievable from a reference point. If all copies of verification material are lost, the artifact becomes unverifiable but does not become unproven. The genesis event still occurred. The enforcement invariants still held at the moment of creation. The artifact's proven status is a property of its creation path, not a property of currently available evidence.

This separation is what distinguishes Provenclave from verification systems, provenance frameworks, and attestation protocols. Those systems define authenticity in terms of what can currently be checked. Provenclave defines provenness in terms of what was structurally enforced at creation. Verification is one mechanism for observing the consequences of enforcement, but it is not the enforcement itself.

9.5 Verification Independence from Proof Transport

A critical architectural property of Provenclave is that the enforcement invariants described in Section 4 hold at genesis and are not contingent on any subsequent verification event, proof transport mechanism, or reference infrastructure availability. Verification is a mechanism for demonstrating that enforcement occurred. It is not a component of enforcement.

The verification model is therefore independent of how verification material reaches the verifier. Provenclave supports multiple verification models, and the choice among them is a deployment decision, not an architectural constraint. No verification model choice affects whether the enforcement invariants hold.

Portable proof.

Verification material travels with the artifact—embedded in file metadata, carried in a sidecar file, or included in a manifest bundle. This is compatible with existing provenance formats such as C2PA and enables self-contained verification without external dependencies.

Reference-based verification.

Verification material is held at one or more canonical reference points operated by the producing boundary, a trusted third party, or a federated network. When a verifier encounters an artifact without co-traveling proof, the verifier computes the artifact's content hash and queries the reference point to obtain the verification material produced at genesis. The artifact carries nothing. Its content hash is its lookup key.

Hybrid verification.

Artifacts carry verification material when the distribution channel preserves it. Reference points serve as authoritative fallback for stripped, reformatted, or re-distributed artifacts. Both modes validate against the same trust anchors and enforce the same invariants.

Verification Independence from Proof Transport

Provenclave Boundary
(genesis)

store proof

↓

Reference Point
(H, N, σ)

finalize

↓

Artifact
(content bytes)

distribute

→

Copy (with proof)

→

Verify
(portable proof)

Copy (stripped)

→

Verify
(reference lookup)

Provenclave Boundary
(genesis)

store proof

↓

Reference Point
(H, N, σ)

finalize

↓

Artifact
(content bytes)

↓ distribute

Copy (with proof)

→

Verify ✓
(portable)

Copy (stripped)

→

Verify ✓
(ref lookup)

Figure 4. Verification independence from proof transport. Artifacts may carry verification material (top path) or be verified by reference lookup using the content hash (bottom path). Both paths validate against the same trust anchors. Proof survives metadata stripping, format conversion, and redistribution.

This property has significant practical consequences. Provenclave-proven artifacts can be freely copied, reformatted, compressed, transcoded, or distributed through channels that strip metadata—and their proven status is permanent regardless of what happens to metadata during distribution. Verifiability—the ability for a third party to confirm proven status—requires that either co-traveling proof or a reference point is available and that the content-preserving hash can be recomputed. But the artifact's proven status, as defined by the enforcement invariants, is an irrevocable consequence of its genesis and does not depend on proof availability. This is a structural advantage over systems that embed provenance in format-specific metadata, which is routinely stripped by social media platforms, content delivery networks, messaging applications, and file conversion tools.

This property is particularly consequential in delay-tolerant and interplanetary networks, where verification material must travel with the data and no return channel to the origin may exist at verification time.

A clarification regarding content transforms is warranted. Verification depends on recomputing a content-dependent hash that matches the hash bound at genesis. Lossless operations that preserve byte-identical content—copying, re-hosting, metadata stripping, container rewrapping—leave this hash intact and verification proceeds directly. Lossy transforms—recompression, transcoding, cropping, resolution scaling—alter the content bytes and therefore invalidate the original binding. Under Provenclave, a lossy transform produces new candidate state. If the transformed output must itself be proven, it requires a new finalization event at a protected transform boundary, producing fresh verification material for the new content. This is not a limitation but a correct application of the enforcement model: the transformed artifact is a different artifact with a different origin. Systems requiring verification across lossy transforms may define robust or perceptual digest schemes as the content-dependent value $H$, but such schemes introduce their own security trade-offs and are a deployment choice, not an architectural requirement. The enforcement invariant is the same regardless of digest construction.

A reference point is not an artifact registry. A registry implies centralized control over all proven artifacts and creates a single point of failure for the entire system. A reference point is a service that holds verification material produced by a specific boundary and can be replicated, federated, or operated by the producing boundary itself. Multiple reference points can hold verification material for the same artifact. The trust model does not change: verifiers validate against trust anchors, not against the reference point's authority. Reference points play no role in the enforcement layer. They do not participate in genesis, do not confer proven status, and their unavailability does not retroactively affect the proven status of any artifact. They are verification infrastructure, not enforcement infrastructure.

Proven Artifact

content bytes

Verification Material

H = hash(content)

N = boundary-fresh value

boundary_id, epoch, policy

σ = Signsk(H, N, metadata)

→

Verifier

1. Recompute hash of content

2. Verify H matches recomputed hash

3. Validate signature under trusted key

4. Check policy constraints

↓

Accept / Reject

Proven Artifact

content bytes

Verification Material

H = hash(content)

N = boundary-fresh value

boundary_id, epoch, policy

σ = Signsk(H, N, metadata)

↓ verify

Verifier

1. Recompute hash of content

2. Verify H matches recomputed hash

3. Validate signature under trusted key

4. Check policy constraints

Accept / Reject

Figure 5. Verification structure (portable proof model). In this depiction, a proven artifact carries its verification material. In the reference-based model (Figure 4), verification material is held separately and retrieved by content hash. The verification checks are identical in both cases.

9.6 Boundary Compromise and Recovery

If the atomic execution boundary or its signing keys are compromised, the system cannot distinguish forged proven artifacts from legitimate ones under that boundary identity. Trust collapses to the compromised boundary, not to the entire system. Recovery is handled operationally by revoking or rotating trust anchors, introducing new boundary identities, and enforcing epoch or policy constraints on acceptable verification material. No artifact registry or retroactive correction mechanism is required.

The critical architectural property is that enforcement strength scales with key isolation strength. Software boundaries provide enforcement convenience and deployment accessibility but are inherently weaker against key extraction. Hardware-backed boundaries—secure enclaves, HSMs, trusted execution environments—provide structural guarantees by enforcing both key non-extractability and constrained usage semantics.

9.7 Security Properties

Property 9.1 (Non-Retroactivity). Proven durable state cannot be produced after the fact for pre-existing data.

Property 9.2 (Creation-Path Exclusivity). Proven durable state is structurally reachable only through the protected commit interface and cannot be produced by any alternative code path or post-hoc process.

Property 9.3 (Content Integrity). Verification material binds proven state to specific content bytes.

Property 9.4 (Replay Resistance). Boundary-fresh cryptographic output prevents reuse of prior authorization events.

10 Related Work

Provenclave intersects with several established areas of security and systems research. This section distinguishes Provenclave from the most closely related approaches and identifies the specific enforcement gap each leaves open.

10.1 Attested Execution and Trusted Execution Environments

Trusted Execution Environments (TEEs) such as Intel SGX, Intel TDX, and ARM Confidential Compute Architecture (CCA) provide hardware-isolated execution with remote attestation. The DICE (Device Identifier Composition Engine) architecture establishes device identity through layered measurements. The IETF RATS (Remote ATtestation procedureS) framework standardizes attestation evidence formats and verification workflows.

These systems answer the question: "Did specific trusted code execute?" Provenclave asks a different question: "Is proven durable state reachable only through enforced commit paths?" Attestation authenticates a pipeline. Provenclave constrains the commit architecture so that alternative pipelines cannot produce proven state. TEEs are one possible implementation substrate for Provenclave boundaries, but attestation alone does not close unprotected commit paths that exist alongside the attested process.

10.2 Content Provenance and Credential Systems

The Coalition for Content Provenance and Authenticity (C2PA) and related provenance standards define how to represent claims about an artifact's origin, edits, and attribution, and how to transport that information across tools and platforms. When a signed artifact is present, these standards make integrity and lineage verifiable and interoperable.

Provenclave targets a different architectural layer. Provenance standards are a packaging and disclosure layer: they define what claims look like and how to verify them. Provenclave is an enforcement layer: it determines whether proven durable state can be finalized at all unless creation-time conditions were met. The distinction matters because provenance ecosystems are voluntary at the edges. A signed artifact can be verified, but an unsigned artifact can still be created, circulated, and injected into downstream systems that do not strictly require provenance at every boundary. Provenance improves traceability without guaranteeing exclusion.

Provenclave and provenance are complementary. Provenclave strengthens provenance by making provenance verifiability a prerequisite for admission into protected domains. Provenance remains the interoperability layer that carries claims across ecosystems; Provenclave supplies the mechanism by which systems enforce that only proven artifacts become trusted durable state. Under Provenclave with reference-based verification, provenance survives even when manifests are stripped during distribution (see the provenance example in Section 2.2 and the verification model in Section 9.5).

10.3 Reference Monitors and Access Control

The classical reference monitor concept (Anderson, 1972) mediates all operations on existing objects: every access is checked against a policy before it is permitted. Provenclave is strictly stronger in one dimension: it controls not merely which operations on objects are permitted, but which objects are permitted to exist in proven form. Classical access control assumes object creation is uncontrolled and focuses on subsequent access. Provenclave constrains creation itself.

Formally, a reference monitor enforces: \[\forall\, \mathit{op} \in \mathit{Operations},\; \forall\, \mathit{obj} \in \mathit{Objects} : \mathit{execute}(\mathit{op}, \mathit{obj}) \Rightarrow \mathit{authorized}(\mathit{subject}, \mathit{op}, \mathit{obj})\] A genesis monitor (Provenclave) enforces: \[\forall\, \mathit{obj} \in \Sigma_{\text{proof}} : \mathit{obj} \in \Sigma \Rightarrow \exists\, e \in E_{\text{proof}} : \mathit{genesis}(\mathit{obj}) = \mathcal{C}(e, \mathit{data})\] The key difference: a reference monitor assumes objects exist and mediates access. A genesis monitor constrains which proven objects can exist at all. This is mandatory constructor security, analogous to mandatory access control but applied to object generation rather than object access.

10.4 Capability-Based Security

Object-capability models (Dennis & Van Horn, 1966; Miller, 2006) enforce that access to objects requires possession of an unforgeable capability. Membrane patterns in capability systems create revocable boundaries around object graphs.

Provenclave shares the emphasis on structural enforcement through unforgeable references but applies it at a different layer. Capabilities control reachability of existing objects. Provenclave controls constructibility of new proven state. The boundary-held capability in Provenclave is a capability-security mechanism, but the enforcement target—preventing existence rather than preventing access—distinguishes Provenclave from classical capability models.

10.5 Information Flow Control

Mandatory information flow control (Goguen & Meseguer, 1982; Myers & Liskov, 1997) constrains how information propagates through a system. Provenclave enforces a related but distinct property: it constrains how proven state is generated, not how information flows between existing states. In information flow terms, Provenclave enforces a mandatory creation policy: proven state can only be generated through specific channels (the protected commit interface), analogous to noninterference applied to creation rather than observation.

10.6 Blockchain and Distributed Consensus

Blockchain systems enforce that state changes require consensus among distributed participants. The architectural parallel to Provenclave is real: both create structural bottlenecks through which state transitions must pass. However, blockchain achieves consensus through economic coordination among mutually distrustful parties, while Provenclave achieves origin enforcement through boundary isolation and cryptographic causality at a single enforcement point. Provenclave generalizes the structural bottleneck principle to arbitrary protected boundaries without requiring distributed consensus, economic incentives, or global coordination.

10.7 Delay-Tolerant Networking and Interplanetary Protocols

The Bundle Protocol (RFC 9171) and DTN architecture provide store-and-forward transport for environments with extreme latency and intermittent connectivity. Bundle security (BPSec, RFC 9172) provides integrity and confidentiality at the bundle layer but does not constrain how proven payloads are created—it secures transport, not genesis. Provenclave complements DTN by enforcing that bundle payloads finalized through a protected commit interface carry portable verification material validatable offline against pre-distributed trust anchors, with no return path to the origin required. Provenclave proofs map onto BP extension blocks, enabling proven bundles to traverse existing DTN infrastructure without routing modifications.

10.8 Summary of Structural Distinctions

Table 1 summarizes the structural properties that distinguish Provenclave from related approaches. Each property is defined by the system invariants and falsifiability tests in Sections 4 and 8.3. Entries reflect architectural constraints, not implementation quality.

Table 1: Structural property comparison across enforcement paradigms.
Property	Digital Signing	TEE / Attested Exec.	Provenance (C2PA)	Blockchain / Ledger	Provenclave
Enforces creation-path exclusivity	No	No^a	No	No	Yes
Prevents post-hoc auth. wrapping	No	No	No	No	Yes
Binds authorization to commit atomically	No	Partial^b	No	Partial^c	Yes
Proof survives metadata stripping	No	No	No	Yes^d	Yes^e
Requires registry or ledger infrastructure	No	No	No	Yes	No
Enforces admission control (not traceability)	No	No	No	No	Yes

^a TEEs attest that trusted code executed but do not close alternative commit paths to durable state (Section 2.1).
^b Authorization and execution are attested, but binding and durable commit are typically separate operations.
^c Consensus binds state transitions but does not constrain artifact genesis prior to ledger submission.
^d Ledger entries persist independently, but the artifact-to-ledger binding is established post-creation.
^e Under reference-based verification (Section 9.5).

11 Worked Examples

We present two worked examples demonstrating Provenclave in distinct domains. In each case, the same architectural pattern applies: candidate data is prepared freely; proven durable state is produced only through the protected commit interface; and any artifact not finalized through the boundary is rejected as unproven.

11.1 Secure Media Capture

Consider a device capturing photos or video for evidentiary or provenance-sensitive use.

Candidate image or video data is produced by the camera sensor and image processing pipeline. This data may exist in memory or temporary buffers. It is not proven.

When a capture is to be finalized, the device invokes the protected commit interface for media output. Inside the atomic execution boundary:

A boundary-fresh value $N$ is generated.
A hash $H$ of the media content is computed.
Verification material is produced by signing over $(H, N)$ together with device identity and capture metadata.
Authorization is performed using a boundary-held capability.
The media file and verification material are committed to durable storage.

Downstream verifiers validate the content hash against the received media, check verification material under approved device or platform trust anchors, and enforce any applicable policy constraints on capture devices or environments.

Any media not finalized through this boundary cannot produce valid verification material and is rejected as unproven—even if it is visually or byte-identical to a proven capture. Critically, the system architecture ensures that no other code path—including the application layer, the operating system, or the storage subsystem—can produce artifacts that satisfy verification. The boundary is not merely the preferred creation path; it is the only creation path for proven media.

11.2 AI Output Export Pipeline

Consider an AI inference service exporting model outputs to downstream consumers.

Candidate outputs are produced by model execution and may exist in memory or temporary buffers. They are not proven.

When an output is to be released, the system invokes the protected commit interface for output export. Inside the atomic execution boundary:

A boundary-fresh value $N$ is generated.
A hash $H$ of the output is computed.
Verification material is produced by signing over $(H, N)$ together with model identity and policy metadata.
Authorization is performed using a boundary-held capability.
The output and verification material are committed.

Downstream verifiers validate the content hash, check verification material under approved trust anchors, and enforce policy constraints on acceptable model identities and metadata.

Any AI output not finalized through this boundary cannot produce valid verification material and is rejected as unproven—even if it is byte-identical to a proven output. The system architecture ensures that no alternative export path—including direct database writes, API bypasses, or file system access—can produce outputs that satisfy verification. This is particularly relevant for regulatory compliance frameworks such as the EU AI Act, which require AI-generated content to be identifiable. Provenclave provides an enforcement mechanism rather than a voluntary labeling scheme.

12 Instantiations of the Atomic Boundary

The atomic execution boundary is an architectural abstraction. Concrete implementations vary by platform, deployment environment, and assurance requirements. Possible instantiations include:

Device-level TEEs or secure enclaves gating camera output, sensor release, or local file creation.
Kernel-mediated commit paths controlling writes to protected namespaces.
HSM-backed services finalizing logs, media, or datasets in backend systems.
Operating system services that mediate all protected commit paths, centralizing admission policy and proof generation.
Gateway or pipeline enforcement at ingestion points where data enters trusted domains.
Secure pipeline stages in CI/CD or regulated data ingestion workflows.

These mechanisms differ in construction, but the enforcement invariant is the same: proven durable state can be finalized only through a protected commit interface that performs boundary-fresh cryptographic binding and authorization inside an atomic execution boundary.

What is required is not a particular trust anchor or hardware feature, but structural enforcement of finalization ordering and exclusivity. The architecture does not prescribe implementations—it defines the invariant that implementations must satisfy.

In practical terms, the protected commit interface presents a narrow surface: the caller submits candidate content and policy metadata; the boundary performs hashing, binding, authorization, and signing internally; and the caller receives the proven artifact and its verification material (or a confirmation that verification material has been stored at a reference point keyed by content hash). The caller never handles signing keys, never observes intermediate cryptographic state, and cannot influence the boundary-fresh value. Whether this interface is realized as a system call, a hardware enclave entry point, an HSM API, or a cloud service endpoint, the enforcement properties are identical.

Provenclave does not prevent the construction of unauthorized boundaries. Any party can build a boundary and produce verification material. However, artifacts produced by unauthorized boundaries fail verification under accepted trust anchors, because those boundaries' identities are not in the approved set. Trust is mediated by trust anchor policy, not by preventing the existence of alternative boundaries.

In practice, layered deployment is common. A device may generate creation-time verification material, while a gateway enforces admission policy and rejects unproven artifacts. Both layers implement the same enforcement principle at different points in the system.

12.1 Enforcement Tier Semantics

Concrete instantiations of the atomic execution boundary differ in the strength of the enforcement guarantee they provide. Not all boundaries are equivalent: a software boundary running in process memory and a hardware enclave with remote attestation both produce cryptographically valid verification material, but they provide fundamentally different assurance that the enforcement invariants actually held. This distinction must be made explicit in the proof structure itself.

Provenclave proofs carry two orthogonal attestations. The first is a cryptographic attestation: the signature and public key establish who signed and that the signed content was unaltered. This is machine-checkable by any party with the public key and is unconditionally verifiable offline. The second is an enforcement attestation: the boundary's identity measurement and optional platform attestation report establish under what conditions signing was permitted — whether the commit gate, key management, nonce generation, and signing occurred inside a verified hardware boundary or merely inside a software process. Atomic causality lives in the second attestation, not the first. A signature proves who signed; the enforcement context proves whether the creation-time constraints of Provenclave actually held.

Three enforcement tiers capture the practically relevant points in this assurance space:

Definition 12.1 (Enforcement Tiers). Let $B$ be a boundary implementation. The enforcement tier of $B$ is a declaration of the structural properties of its atomic execution boundary:

Software-only ($\tau_\text{sw}$). The commit gate, signing key, nonce source, and counter are all held in ordinary process memory. No hardware isolation separates them from application code. The signing key may be extractable by any code with sufficient privilege. Verification material is cryptographically valid but provides no hardware boundary guarantee. Suitable for development and integration testing; does not satisfy the Boundary Isolation invariant (Definition 4.1) against a privileged-process adversary.
Hardware-bound key ($\tau_\text{hw}$). The signing key is held in a hardware security boundary (Secure Enclave, TPM, HSM) and is non-exportable. However, the commit gate — the logic that decides which candidate data is eligible for signing — runs outside the measured boundary. The host process feeds content digests to the hardware for signing; the hardware signs whatever it is asked. This provides hardware-bound identity: the signing key cannot be extracted, so signatures are unforgeable. But it does not provide causal enforcement: a compromised host can submit arbitrary digests and receive valid signatures without passing through the protected commit interface. The enforcement invariant holds for key security but not for commit-path exclusivity.
Measured TEE ($\tau_\text{tee}$). The commit gate, key management, nonce generation, monotonic counter, and signing all execute inside the attested enclave boundary. The host is treated as untrusted and cannot influence the commit decision or observe intermediate cryptographic state. The enclave's identity is a hardware-measured value — a cryptographic hash of the enclave binary computed by the hardware boot chain — that cannot be forged by user-space code or produced by a different binary. A verifier who pins acceptable measurements to a known-good enclave image and validates the attestation report is guaranteed, under the hardware trust model, that the enforcement invariants held at genesis.

A critical subtlety distinguishes tamper-evidence from self-proof. The enforcement tier is included in the signed body of every Provenclave proof, making it tamper-evident in transit: an adversary who intercepts a proof and attempts to substitute a higher-assurance tier will break the signature. However, the tier field is self-reported by the boundary adapter. A malicious or misconfigured adapter can declare any tier. The signed field prevents downgrade attacks during transmission; it does not prevent a lying producer.

Actual trust in a declared tier therefore requires independent corroboration. For $\tau_\text{tee}$, this means: (1) pinning acceptable measurements to a known-good enclave image hash published by the boundary operator or auditor, and (2) validating a hardware attestation report — a vendor-signed document generated by the hardware itself, bound to the specific commit, that certifies the enclave measurement matches a known image. Signature verification establishes cryptographic integrity. Measurement pinning establishes identity. Attestation report validation establishes that the identity was produced by real hardware under the declared conditions. All three are necessary; any two leave a gap. A verifier who checks the signature and trusts the self-reported tier without verifying measurement and attestation has verified fact (A) — who signed — but not fact (B) — whether the Provenclave invariants actually held.

Remark 12.2 (Hardware-Bound Key is Not Causal Enforcement). The $\tau_\text{hw}$ tier corresponds to devices such as mobile Secure Enclaves, TPMs, or HSMs where the signing key is hardware-protected but the commit gate runs in application code. Such systems provide meaningful security against key extraction — an adversary cannot steal the private key — but do not satisfy commit-path exclusivity. Application code feeding arbitrary digests to the hardware signer can produce valid signatures for any content without traversal of the protected commit interface. This is useful as an identity anchor and may be sufficient for some deployment contexts, but it is architecturally distinct from $\tau_\text{tee}$ and does not satisfy Provenclave's Atomic Causality invariant (Definition 6.1) against a compromised-host adversary.

This taxonomy is not a quality ranking among implementations — a $\tau_\text{sw}$ boundary is fully correct for development environments where the adversary model does not include privileged process access. It is a structural classification that makes the adversary model explicit in the proof itself. Verifiers select the tier they require based on their own threat model. A local development tool may accept $\tau_\text{sw}$. A regulated ingestion gateway may require $\tau_\text{tee}$ with measurement pinning and attestation validation. The same proof format and verification protocol supports all three, with enforcement strength determined by verifier policy rather than proof format version.

13 Admission of Pre-Existing Data

Provenclave defines provenness in terms of enforced finalization events, not in terms of historical existence of content bytes.

Candidate data may exist prior to proven finalization and may be externally sourced, duplicated, replayed, or synthesized. Such prior existence is outside the trust model and carries no authenticity semantics.

Proven durable state is created only when candidate data is finalized through the protected commit interface and bound to boundary-fresh cryptographic output produced inside the atomic execution boundary. Without this enforced finalization event, no artifact can enter proven state, regardless of its prior history or method of creation.

The same content may be finalized multiple times in separate authorization events, each producing distinct verification material. Each such event constitutes an independent origin—a distinct enforced admission into proven durable state.

Provenness therefore reflects structural reachability through enforced commit paths, not claims about when or how content bytes first came into existence.

13.1 Enforced Provenance Chains

When content traverses multiple Provenclave-enforced boundaries, each boundary produces independent verification material for the same content. The result is a structurally enforced provenance chain: an ordered sequence of admission events, each cryptographically bound to the content at its respective boundary. Unlike voluntary provenance annotations, each link in this chain is the product of an enforced finalization event and could not have been produced without traversing the corresponding boundary.

Pre-existing
content

(unproven)

→

Boundary A

Ingest

↓

(H, N₁, σ₁)

origin₁

→

Boundary B

Process

↓

(H′, N₂, σ₂)

origin₂

→

Boundary C

Publish

↓

(H″, N₃, σ₃)

origin₃

→

Proven
artifact

(3 enforced origins)

enforced provenance chain — each link is an independent Provenclave finalization

Pre-existing content
(unproven)

↓

Boundary A → Ingest

(H, N₁, σ₁)

origin₁

↓

Boundary B → Process

(H′, N₂, σ₂)

origin₂

↓

Boundary C → Publish

(H″, N₃, σ₃)

origin₃

↓

Proven artifact
(3 enforced origins)

enforced provenance chain

Figure 6. Enforced provenance chains. Pre-existing content traverses multiple Provenclave boundaries, each producing independent verification material. Each admission is a separate enforced finalization event. The resulting chain is structurally guaranteed—not voluntarily annotated—because each link requires traversal of a protected commit interface.

14 Implementation Considerations

Latency.

Creation-time enforcement must be fast enough to run on capture and export paths without degrading user experience or pipeline throughput. Efficient proof generation and verification are engineering constraints, not architectural limitations. Modern signing operations (Ed25519, ECDSA P-256) complete in microseconds on current hardware.

Offline operation.

Environments requiring offline creation can generate proofs locally and defer admission into trusted domains until connectivity is available. Trusted domains then enforce verification at ingestion. This provides bounded issuance guarantees rather than continuous supervision—analogous to how physical secure instruments (e.g., pre-signed checks) operate with deferred clearing. In extreme cases—interplanetary missions, remote sensor networks, or disconnected autonomous systems—offline operation may span hours to days, with proofs verified only upon eventual receipt at a ground station or gateway operating under the same trust anchors.

Failure handling.

Systems must define failure behavior. For high-assurance domains, fail-closed behavior is required: if proof generation fails, finalization is blocked. For consumer deployments, staged enforcement may begin with fail-open at selected boundaries and evolve toward fail-closed as operational confidence increases.

Verification material formats and transport.

Verification material may be embedded within the artifact, carried in a sidecar file, included in a bundle manifest, transmitted as a proven envelope, or held at a reference point for query-based verification (see Section 9.5). The key requirement is that verification material is bound to the artifact in a way that can be validated independently and cannot be retroactively attached without detection. The choice of transport mechanism is a deployment decision; the enforcement invariant is the same regardless of how verification material reaches the verifier.

Key rotation and revocation.

Operational deployments require key rotation policies and revocation mechanisms. When a boundary is compromised, trust anchors can be revoked or rotated, new boundary identities introduced, and epoch constraints enforced on acceptable verification material. No artifact registry is required for rotation or recovery.

Interoperability with provenance systems.

Provenclave coexists with provenance and credentialing systems that focus on post-creation traceability. Provenance chains can be attached to artifacts finalized under Provenclave, providing richer downstream traceability. The admission decision remains anchored in enforced finalization, while provenance provides the interoperability layer for distribution and audit.

15 Deployment and Adoption

Provenclave is best understood as an enforcement primitive that can be introduced incrementally. Most environments cannot transition from fully permissive creation to strict admissibility in a single step.

Phased rollout.

A practical deployment begins with visibility: attaching verification material when available and surfacing proven versus unproven status. The next phase requires proven finalization for selected high-assurance workflows while allowing unproven outputs in a separate untrusted lane. Over time, enforcement expands to additional repositories, export paths, and regulated domains. Each phase requires engineering integration with existing commit paths, and the phased model is designed to contain this cost by limiting initial enforcement to high-value boundaries.

Policy-driven boundaries.

The decisive question in most deployments is not whether an artifact can be produced, but whether it can be admitted into a domain that confers legitimacy, downstream impact, or compliance standing. Provenclave can be applied selectively at these boundaries: ingestion into training corpora, publication to official channels, archival in compliance systems, or persistence into audit-grade logs.

Institutional adoption incentives.

Adoption is accelerated when benefits are concrete: reduced downstream moderation burden, improved auditability, clearer liability boundaries, and the ability to define and enforce admissible content policies. In high-volume environments, the ability to reject unproven artifacts at ingestion is more valuable than attempting to detect or classify them after the fact. Organizations already subject to compliance mandates—regulated data processors, evidentiary systems, and entities operating under frameworks such as the EU AI Act—are natural early adopters, as they face the strongest immediate demand for structural authenticity guarantees.

End state.

The end state is not universal prevention of unproven creation, but reliable exclusion of unproven durable state from the systems and pipelines where legitimacy, compliance, and downstream impact are determined.

16 Applications

Provenclave applies wherever systems must distinguish admissible durable outputs from arbitrary durable outputs produced outside trusted pipelines. The common architectural pattern is a protected commit path that gates admission into proven durable state. The pattern arises across domains:

AI training and inference pipelines, where only proven outputs may be admitted into datasets or downstream automation.
Media capture and evidentiary systems, where admissibility depends on verified creation conditions.
Compliance logging and telemetry, where audit records must resist post-hoc fabrication.
Scientific instruments and simulations, where experimental results must be traceable to controlled execution environments.
Regulated data processing in finance, healthcare, safety monitoring, and government systems.
Digital identity and credential issuance, where credentials must be structurally unforgeable.
Supply chain verification, where provenance must be enforced at each handoff rather than reconstructed afterward.
Authorization transfer and ledger-independent scarcity, where transfer of digital value or authority is enforced by a single atomic transition that both irreversibly de-authorizes the sender capability and generates the receiver capability within a protected execution boundary. This is a direct application of the birth–death semantics described in Section 17: the prior authority undergoes verifiable death, and the successor undergoes verifiable birth, within a single atomic event. This preserves scarcity invariants structurally and implies double-spend resistance without global ledgers, distributed consensus, or registry-based settlement infrastructure. The settlement and monetary implications are substantial and are explored separately.
Interplanetary and delay-tolerant systems, where proof must be non-interactive, verification must occur offline, and proofs must travel with data across store-and-forward networks with minutes-to-hours latency. Provenclave's non-interactive finalization, compact portable proofs, and hardware-rooted trust align with the operational constraints of DTN/Bundle Protocol environments, where real-time protocols, centralized registries, and consensus mechanisms are infeasible.

Across these domains, trust derives from enforced admission into proven state at commit time, not from retrospective provenance reconstruction. When admissibility matters, origin enforcement necessarily moves into the creation and finalization paths of the system.

17 Birth–Death Semantics

Provenclave (Provenclave) enforces what we term birth–death semantics for digital state. Under this model, every authoritative state transition has exactly one verifiable moment of creation (birth), and every transfer or succession requires cryptographic evidence that the prior authority has been irreversibly consumed (death).

Traditional provenance systems operate in a detect-after model: artifacts are produced freely, and conflicts such as replay, duplication, or double-spend are identified retrospectively through logs, ledgers, or consensus. Provenclave instead constrains the execution path such that invalid successor states are structurally unreachable within the enforcing boundary.

Detect-After Model

Authority S₀

↙

↘

S₁ valid

S₁′ valid

↓

Conflict detected
retrospective resolution

fork now, detect later

→

Provenclave
enforces

Birth–Death Semantics

Authority S₀

↓

Death

S₀ consumed

↓

Birth

S₁ committed

↓

S₁ valid

↓

S₁′

fork structurally unreachable

Detect-After Model

Authority S₀

↙

↘

S₁ valid

S₁′ valid

↓

Conflict detected

fork now, detect later

↓

Provenclave enforces

Birth–Death Semantics

Authority S₀

↓

Death — S₀ consumed

↓

Birth — S₁ committed

↓

S₁ valid

↓

S₁′

fork structurally unreachable

Figure 7. Detect-after vs. birth–death enforcement. Traditional systems (left) permit both successor states to be produced and detect conflicts retrospectively. Under birth–death semantics (right), the prior authority is irreversibly consumed within the atomic boundary, and exactly one successor is committed. The alternative fork is not merely unlikely—it is structurally unreachable within the enforcing boundary.

17.1 Construction

Within a verifier-accepted measured boundary (e.g., a Trusted Execution Environment or equivalent protected constructor), a valid Provenclave commit requires the atomic execution of the following steps:

Policy authorization of the requested operation
Generation and atomic consumption of a fresh, non-replayable commitment value (either an unpredictable nonce or a strictly monotonic counter)
Collision-resistant binding of the artifact digest to the consumed value
Durable commit of the resulting signed proof

No intermediate state is externally observable, and partial completion yields no valid proof. The consumed value establishes a forward-only lineage: any valid successor must reference a strictly later state within the boundary's monotonic domain.

17.2 Single-Successor Property

Given correct enforcement of measurement and monotonicity within the boundary, Provenclave guarantees:

Property (Single-Successor). At most one valid successor can be produced from any given parent authority within the verifier-accepted measurement and monotonicity domain of the enforcing boundary.

If two purported successors are observed downstream, at least one of the following must hold:

The enforcing boundary was compromised or misconfigured
Monotonic state or anti-rollback guarantees were violated
The verifier accepted an out-of-policy measurement
The usage context exceeded the declared trust model

This reframes failure analysis from probabilistic conflict resolution to deterministic boundary integrity verification.

17.3 Relationship to Double-Spend

Birth–death semantics targets the core primitive underlying double-spend failures: the ability to produce multiple valid successor states from a single authority. By making such forks structurally unreachable at commit time within the stated trust envelope, Provenclave reduces reliance on global ordering for single-holder and provenance-sensitive workflows.

Provenclave does not claim global uniqueness across mutually distrustful, permissionless environments without additional coordination. Instead, it provides strong local authority guarantees that higher-level systems may compose with federation or consensus where global agreement is required.

17.4 Trust Envelope

The guarantees above hold only within the verifier-accepted measurement and monotonicity domain of the enforcing boundary. In particular:

A protected execution boundary is required for enforcement
Monotonic state must be resistant to rollback within that boundary
Verifiers must enforce measurement policy and counter monotonicity
Provenclave does not prevent byte-level copying of artifacts outside the authority model

Within this envelope, birth–death semantics converts post-facto detection problems into construction-time exclusion properties.

18 Single-Transfer Value Without Consensus

Provenclave (Provenclave) enables single-transfer digital value by binding authority to a consumptive, cryptographically enforced state transition rather than to a ledger entry. This is a concrete instantiation of the birth–death semantics described in Section 17: each transfer atomically consumes (kills) the prior holder's authority and produces (births) a new verifiable successor. Each artifact carries a proof that can only be produced through a protected commit path, where authorization, binding, and durable commit occur atomically inside a trusted execution boundary. When value is transferred, the prior holder's permission is provably consumed and the new state is independently verifiable offline using public keys and hash lineage. The bytes themselves may be copied, but the authoritative right cannot be duplicated, because the single-successor property guarantees that only one unspent lineage can exist at a time within the enforcing boundary. In this model, uniqueness and transfer integrity come from enforced execution semantics instead of global consensus, allowing blockchain-free, verifiable digital handoff.

19 Conclusion

The Trusted Origin Token Architecture demonstrates that origin control can be enforced by consuming authorization units at finalization. Provenclave generalizes this result by showing that equivalent enforcement is achieved using boundary-fresh cryptographic computation and protected commit paths, without requiring tracked tokens.

Atomic Causality links authorization, cryptographic binding, and durable commit into a single indivisible event. Proven durable state is defined by structural reachability—by the state transitions that produced it—not by historical claims, metadata, or post-hoc annotation.

The formal model presented here shows that Provenclave defines a new enforcement primitive: a genesis access control mechanism that constrains which proven objects are permitted to exist, rather than mediating operations on objects that already exist. This is strictly stronger than classical reference monitors and formally distinct from attested execution, information flow control, and capability-based security.

By securing creation rather than history, Provenclave establishes an architectural primitive for trustworthy digital systems. It does not replace provenance, verification, or access control. It provides the structural foundation that makes those mechanisms enforceable at the boundaries where legitimacy is conferred.

References

[1] J. P. Anderson, "Computer security technology planning study," Tech. Rep. ESD-TR-73-51, Electronic Systems Division, AFSC, 1972.

[2] W. Y. Arms, "Digital libraries," MIT Press, 2000.

[3] Coalition for Content Provenance and Authenticity (C2PA), "C2PA Technical Specification v2.1," 2024.

[4] V. Costan and S. Devadas, "Intel SGX explained," IACR Cryptology ePrint Archive, Report 2016/086, 2016.

[5] J. B. Dennis and E. C. Van Horn, "Programming semantics for multiprogrammed computations," Communications of the ACM, vol. 9, no. 3, pp. 143–155, 1966.

[6] Trusted Computing Group, "DICE Layered Architecture," 2020.

[7] J. A. Goguen and J. Meseguer, "Security policies and security models," in Proc. IEEE Symposium on Security and Privacy, pp. 11–20, 1982.

[8] T. J. Green, G. Karvounarakis, and V. Tannen, "Provenance semirings," in Proc. ACM SIGMOD-SIGACT-SIGART Symposium on Principles of Database Systems (PODS), pp. 31–40, 2007.

[9] IETF, "Remote ATtestation procedureS (RATS) Architecture," RFC 9334, 2023.

[10] C. B. Jones, "Tentative steps toward a development method for interfering programs," ACM Transactions on Programming Languages and Systems, vol. 5, no. 4, pp. 596–619, 1983.

[11] B. W. Lampson, "Protection," in Proc. 5th Princeton Symposium on Information Sciences and Systems, pp. 437–443, 1971.

[12] M. S. Miller, "Robust composition: Towards a unified approach to access control and concurrency control," Ph.D. dissertation, Johns Hopkins University, 2006.

[13] A. C. Myers and B. Liskov, "A decentralized model for information flow control," in Proc. 16th ACM Symposium on Operating Systems Principles (SOSP), pp. 129–142, 1997.

[14] G. C. Necula, "Proof-carrying code," in Proc. 24th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL), pp. 106–119, 1997.

[15] S. Burleigh, K. Fall, and V. Cerf, "Delay-Tolerant Networking Architecture," RFC 4838, 2007.

[16] K. Scott, S. Burleigh, et al., "Bundle Protocol Version 7," RFC 9171, 2022.

[17] E. Birrane III and K. McKeever, "Bundle Protocol Security (BPSec)," RFC 9172, 2022.