Thanks @WeissCurry and @babyblueviper1, this helps.
On writing verdicts to the ERC-8004 Validation Registry, agreed it fits. 8004 covers who the agent is and its reputation after the fact, and this covers the permission before it acts. I added a VerdictAttestation struct to the reference impl that uses both things @babyblueviper1 pointed out.
The artifactHash is already there. It’s just Verdict.actionCommitment, the canonical PolicyAction hash, which points at the one specific action instead of a class. I only had to surface it in the attestation.
On mechanism, good point. I set a tag to keccak256(“zk-secret-policy”) so a verdict proved against a secret policy doesn’t get mixed up with a self-attested or public-recomputable one when they sit in the same registry.
Code and a handoff test are up here confidential-agent-policy-verdicts/src/IPolicyAttestation.sol at main · zexoverz/confidential-agent-policy-verdicts · GitHub , suite is 19/19. @WeissCurry that struct is the payload schema you asked about, open to changing the field names.
The orthogonal framing you gave, confidential-correct vs public-recomputable, is a good way to put it. I’ll move it into the Rationale since it draws the line of what this claims better than my wording does.
And yes @babyblueviper1, please sketch the composed example. One action gated here with its attestation, next to your public-recomputable verdict on the same action. Would be great to see them side by side.
One thing I want to keep, the Guard stays a minimal primitive. The attestation is the guarded contract’s job, recommended not required, so it never touches the core consume path