pith. sign in

arxiv: 2605.01037 · v3 · pith:CH54UXIDnew · submitted 2026-05-01 · 💻 cs.CR · cs.AI· cs.PL

Certified Purity for Cognitive Workflow Executors: From Static Analysis to Cryptographic Attestation

Alan L. McCann This is my paper

Pith reviewed 2026-05-09 18:44 UTC · model grok-4.3

classification 💻 cs.CR cs.AIcs.PL
keywords certified puritycognitive workflowsWebAssemblycryptographic attestationBEAM virtual machinetrusted computing basegovernance enforcementbypass elimination
0
0 comments X

The pith

Cognitive workflow executors achieve certified structural purity through WebAssembly restrictions and cryptographic attestation.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper shows how to replace runtime checks with a structural boundary that prevents executors from producing side effects. It does this by compiling to a restricted WebAssembly form, issuing signed purity certificates, and adding a runtime gate that rejects anything uncertified. A reader would care because the approach eliminates all five known classes of BEAM virtual-machine bypasses while adding only microseconds of verification cost. The guarantees rest on an explicit trusted computing base rather than on module-import analysis alone. The work therefore turns an earlier governance architecture into something enforceable even under adversarial compilation or execution.

Core claim

By targeting a restricted WebAssembly subset that structurally excludes effect-producing instructions, binding each binary to its import classification via a cryptographically signed purity certificate, and inserting a verification gate before any executor reaches the governance pipeline, the system proves structural purity by construction, elimination of all five BEAM bypass classes, certificate integrity, and gate completeness. The entire guarantee is stated relative to an explicit trusted computing base that includes the compiler, signer, and verifier.

What carries the argument

The purity certificate: a cryptographically signed binding of an executor binary to its static import classification, which the runtime gate checks before allowing entry into the governance pipeline.

If this is right

  • All five documented BEAM bypass classes become impossible under the restricted compilation target.
  • Verification adds 39-42 microseconds of latency and less than 0.4 percent overhead to a 100 ms request.
  • Portable governance credentials enable cross-organizational verification without shared runtime environments.
  • Determinism is preserved across repeated invocations with zero observed divergences.
  • The four theorems hold only relative to the stated trusted computing base.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The same restricted-compilation-plus-certificate pattern could be applied to other managed runtimes that currently rely on import-graph analysis.
  • Remote attestation opens the possibility of verifying executor purity across organizational boundaries without exposing source or full binaries.
  • The low overhead suggests the technique could be used inside high-frequency workflow loops without changing latency budgets.

Load-bearing premise

The pure-module constraint from the prior governance architecture must hold and the trusted computing base containing the compiler, signer, and verifier must remain uncompromised.

What would settle it

A concrete demonstration that a non-pure executor compiled to the restricted WebAssembly target produces an effect or that a forged certificate passes the runtime gate would falsify the theorems.

read the original abstract

We present a certified purity architecture that converts governance enforcement in cognitive workflow systems from a runtime convention into a structural capability boundary. A prior three-layer governance architecture proves governance completeness, provenance completeness, and the impossibility of ungoverned effects, conditional on the pure module constraint: that step executors cannot perform effects. That constraint was enforced by module import graph analysis, which is insufficient against adversarial bypass on the BEAM virtual machine. This paper closes the gap through four mechanisms: (1) a restricted WebAssembly compilation target where effect-producing instructions are structurally absent; (2) purity certificates, cryptographically signed proofs binding executor binaries to their import classifications; (3) a runtime verification gate that rejects uncertified executors before they enter the governance pipeline; and (4) portable governance credentials via remote attestation for cross-organizational verification. We prove four theorems: structural purity by construction, bypass elimination for all five BEAM bypass classes, certificate integrity, and gate completeness. The guarantee holds relative to an explicit Trusted Computing Base. Evaluation on four implemented executors shows verification latency of 39--42 us, full plan cycle under 400 us, runtime overhead under 0.4% of a 100 ms HTTP request, and zero determinism divergences across repeated invocations.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 2 minor

Summary. The paper presents a certified purity architecture for cognitive workflow executors that converts prior runtime governance conventions into structural guarantees. It introduces restricted WebAssembly compilation (absent effect instructions), signed purity certificates binding binaries to import classifications, a pre-pipeline verification gate, and remote attestation for portable credentials. Four theorems are claimed: structural purity by construction, bypass elimination across all five BEAM bypass classes, certificate integrity, and gate completeness, all relative to an explicit Trusted Computing Base. Evaluation on four executors reports verification latency of 39-42 μs, full plan cycles under 400 μs, runtime overhead below 0.4% for 100 ms HTTP requests, and zero determinism divergences.

Significance. If the theorems and evaluation hold, the work meaningfully advances secure cognitive workflow systems by replacing import-graph analysis with a cryptographically attested structural boundary. Strengths include the explicit TCB scoping, the reduction of the pure-module constraint to a compilation invariant, the concrete low-overhead numbers, and the portable attestation mechanism for cross-organizational use. This bridges static analysis limitations with attestation primitives in a way that could support stronger governance in distributed executors.

major comments (2)
  1. [Abstract and theorems section] The abstract and theorem statements claim bypass elimination for all five BEAM bypass classes and structural purity by construction, yet the provided manuscript text supplies no proof sketches, reduction steps, or explicit enumeration of how each bypass class is precluded by the Wasm instruction restrictions. This is load-bearing for the central claim that the architecture closes the gap left by prior static analysis.
  2. [Trusted Computing Base and assumptions] The weakest assumption (pure module constraint from the prior three-layer architecture) is stated to hold, but the manuscript does not demonstrate that the new Wasm restrictions and certificate gate preserve this constraint under adversarial compilation or signing; a concrete argument or counter-example analysis is needed in the TCB section.
minor comments (2)
  1. [Evaluation] The evaluation section reports aggregate latency and overhead figures but does not specify the four executors, the exact measurement methodology for determinism, or the baseline without the gate; adding these details would improve reproducibility.
  2. [Introduction] Notation for purity certificates and the verification gate could be introduced earlier with a small diagram or table summarizing the four mechanisms and their security properties.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We appreciate the referee's thorough review and the recognition of the paper's contributions to secure cognitive workflow systems. We address each major comment in detail below, providing clarifications and indicating the revisions made to strengthen the manuscript.

read point-by-point responses

  1. Referee: [Abstract and theorems section] The abstract and theorem statements claim bypass elimination for all five BEAM bypass classes and structural purity by construction, yet the provided manuscript text supplies no proof sketches, reduction steps, or explicit enumeration of how each bypass class is precluded by the Wasm instruction restrictions. This is load-bearing for the central claim that the architecture closes the gap left by prior static analysis.

    Authors: We agree that including explicit proof sketches and enumerations would improve the clarity and verifiability of our central claims. In the revised version, we have added detailed proof sketches in a new subsection under the theorems section. Specifically, we outline the inductive proof for structural purity by construction, showing that the restricted Wasm compilation target excludes all effect instructions by design. For bypass elimination, we now explicitly map each of the five BEAM bypass classes to the corresponding Wasm restrictions and certificate validations that prevent them. This directly supports the claim that the architecture provides stronger guarantees than prior static analysis approaches. revision: yes

  2. Referee: [Trusted Computing Base and assumptions] The weakest assumption (pure module constraint from the prior three-layer architecture) is stated to hold, but the manuscript does not demonstrate that the new Wasm restrictions and certificate gate preserve this constraint under adversarial compilation or signing; a concrete argument or counter-example analysis is needed in the TCB section.

    Authors: The manuscript's TCB section already scopes the assumptions to include a trusted compiler and signer. However, to address the request for a concrete argument, we have expanded this section with an explicit analysis. We argue that the pure module constraint is preserved because the Wasm restrictions are a compilation invariant enforced by the trusted compiler, and the certificate gate verifies the binding via cryptographic signatures. Under adversarial compilation, any attempt to include bypasses would result in a binary that either fails to compile under restrictions or cannot be signed validly without the trusted key. We include a brief counter-example analysis showing that successful bypass would require compromising the TCB components (e.g., breaking the signature scheme or the attestation protocol), which is outside the threat model. This addition clarifies the preservation of the constraint. revision: yes

Circularity Check

0 steps flagged

Minor self-citation to prior architecture; central claims rest on new mechanisms and explicit theorems

full rationale

The paper cites a prior three-layer governance architecture for conditional results on governance and provenance completeness assuming the pure module constraint, but introduces independent mechanisms (restricted Wasm compilation eliminating effect instructions by construction, signed purity certificates, pre-pipeline verification gate, and remote attestation) to enforce that constraint and prove four new theorems scoped to an enumerated TCB. No fitted parameters, self-definitional reductions, or load-bearing reliance on unverified self-citations appear; the derivation chain remains self-contained against the stated assumptions and evaluation data.

Axiom & Free-Parameter Ledger

0 free parameters · 2 axioms · 1 invented entities

The architecture depends on the pure module constraint carried over from prior work and an uncompromised Trusted Computing Base for the attestation and verification components. No free parameters are introduced or fitted to data.

axioms (2)
  • domain assumption The pure module constraint: that step executors cannot perform effects.
    This is the foundational condition from the prior three-layer governance architecture on which the new mechanisms are built.
  • domain assumption The Trusted Computing Base remains secure and uncompromised.
    The paper states that all guarantees hold relative to an explicit TCB.
invented entities (1)
  • Purity certificates no independent evidence
    purpose: Cryptographically signed proofs that bind executor binaries to their import classifications.
    New construct introduced to enable portable verification and runtime gating.

pith-pipeline@v0.9.0 · 5521 in / 1351 out tokens · 41436 ms · 2026-05-09T18:44:49.404966+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.