The outstanding issue on interpreter fidelity is one I keep hitting from a completely different corner, so let me offer a view on your “own ERC vs. inline” question — with the caveat that I work on the control/containment side, not the ZK side, so please treat the cryptographic specifics as deference.
What you name — a proof attests the program executed, not that it faithfully implements the policy; an always-ALLOW interpreter verifies identically — is the general shape of the verifier itself has to be verified. A guardrail no one has ever watched fail is indistinguishable from a promise. I ran into the exact same wall building inheritable agent mandates: an external gate that decides whether a spawned child is in-bounds is only worth something if the gate itself is checkable by someone who doesn’t trust the operator — otherwise you’ve moved the trust, not removed it.
Because it’s the same shape in several places at once — your interpreter, ERC-8274’s proof verifiers, ERC-8004’s validators, a spawn-gate in my case — my instinct is that fidelity-attestation wants to be a separate, reusable primitive (its own ERC, or a shared convention this one requires), not inline. Inline means every standard re-solves “prove the checker faithfully implements its spec,” and each re-solution is one more thing to trust. A shared “equivalence-to-a-readable-reference, bound to the program key” primitive would let the whole agent cluster point at one checkable answer instead of N bespoke ones. The cost is the one you already flag — a dependency on another Draft to reach Final.
A genuine question back, since you’ve thought about this far more than I have: can the fidelity attestation ever be fully on-chain-checkable, or does it bottom out in a human reading the “readable reference definition” and trusting that the equivalence proof targets the right reference? If it’s the latter, that isn’t a flaw — but it’s worth naming as the irreducible trust root, the same way genesis trust always has to start somewhere.