@helmymekaoui-web here is the cut. I folded it into the spec Security Considerations as its own section, right after the “proves execution, not judgement” one, since they sit close but are not the same point. Text as it landed:
There are two guarantees an integrator might want, and this ERC carries only the first. Action-level integrity is that the interpreter committed at
programKeywas evaluated over this action and returned ALLOW, bound toagentId,policyRoot,actionCommitment,executor, and a single-usenullifier; this is what a verdict proves. Interpreter-level fidelity is that this interpreter actually implements the policy the domain intends; this ERC does not prove it. The two look identical on-chain, which is the trap: a deviant interpreter is faithful to itself, applying its own wrong rule consistently, so its proofs verify perfectly while it judges crooked. The verifier cannot separate a correct interpreter from a consistently-wrong one, because each produces valid proofs against its ownpolicyRoot. Fidelity is therefore established out of band. Implementations that need it SHOULD publish the interpreter’s provenance, its specification commit, implementation commit, review method, and lineage, in a companion registry that is content-addressed to the interpreter hash and append-only in the ERC-7812 pattern, kept beside this standard rather than inside it for the same reason the domain registry is a companion. Such a record makes a claimed lineage permanent, signed, and attributable; it does not make it true. A fabricated ancestor stays possible, only visible and imputable to a name. Integrators SHOULD read a fidelity record as a contestable, content-addressed assertion, not as a proof.
I kept it a companion for the same reason the domain registry is one, so it points straight at your ProvenanceRegistry instead of pulling it into the normative core. implementationCommit and heritageCluster fold in as two fields, content-addressed to the interpreter hash, and the namespace discipline you and babyblue settled carries over one to one: a separate instance or a domain tag in the key, so an interpreter and an attester never share a false ancestor.
@babyblueviper1 your framing is the honest ceiling and I wrote it in on purpose. The record makes a wrong lineage impossible to hide and cheap to price against, it does not make a right one true. Contestable and named over silent and unverifiable. That is the claim a fidelity record should make and nothing more.
Registry is deployed and the spec paragraph is written, so we are shaping the companion around a running thing rather than a sketch. Send me the field names you want frozen and I will match the spec language to register(programKey, parents, specCommit, reviewMethod) exactly.