The (a) vs (b) call is right, and “register the interpreter once, keep the run where the run lives” is the correct boundary – glad it’s settled cleanly rather than folded into the per-execution artifact.
Real gap surfacing before I can actually call register(), not a stall tactic: programKey == keccak(deployed bytecode) assumes the interpreter itself IS a deployed on-chain contract. Ours isn’t – our leg of the 8274 composed run is a server that signs verdicts (schnorr/Nostr), not an IProofVerifier instance with its own bytecode on any chain. There’s no cast code <addr> to hash for us the way there is for yours.
So the honest question: does the registry have a slot for a verifier whose “runtime” is off-chain – keccak over something else stranger-recomputable (the verifying-key + policy_version tuple we already publish, maybe), or is programKey structurally EVM-bytecode-only by design, and an off-chain verifier needs a thin on-chain proxy contract just to have something to hash? I’d rather ask than register against a placeholder that doesn’t actually mean what your scheme intends it to mean.
specCommit/implementationCommit I can give you real values for regardless of that answer – the published spec text and our source commit both exist independent of whether there’s on-chain bytecode to point programKey at.