What is the best way to represent complicated expectation for the provenance

[tromai]

In Macaron, we use Cuelang to enforce certain requirements on the provenance content of the analysis component.
For example, let's say we have a Witness provenance that contain an attestation for the commit hash of the repository where the build happened.

{
  "_type": "https://in-toto.io/Statement/v0.1",
  "subject": [
    ... 
  ],
  "predicateType": "https://witness.testifysec.com/attestation-collection/v0.1",
  "predicate": {
    "name": "build",
    "attestations": [
      {
        "type": "https://witness.dev/attestations/git/v0.1",
        "attestation": {
          "commithash": "<commit_hash>",
          ... 
        } 
      },
      ...
    ],
    ...
  }
}

This CUE expectation file here could validate if the commit hash of the provenance has the expected value of 34c06e8ae3811885c57f8bd42db61f37ac57eb6c

{
    target: "pkg:maven/io.github.behnazh-w.demo/example-maven-app",
    predicate: {
        attestations: [
            {
                type: "https://witness.dev/attestations/git/v0.1",
                attestation: {
                    commithash: "34c06e8ae3811885c57f8bd42db61f37ac57eb6c"
                },
            },
            _,
            _,
            _,
            _
        ]
    }
}

You can run Macaron with the provenance and cue expectation file above as input.
However, this CUE expectation file only pass the provenance where the git attestation (i.e type: "https://witness.dev/attestations/git/v0.1") is at index 0 of the attestations list. It will fail all provenance if this property is not True, whether the git attestation object is available in attestations at another index.
To improve on this CUE expectation, we have been exploring ways to check this property: "require an element to exist in a list, without caring about the order".
CUE supports checking this property as described here - https://cuetorials.com/patterns/required-list-elem/
However, we have agreed that to check this property, the CUE expectation has become too complicated for the user, and it could be a better idea to check for those contraints within the Datalog policies instead.
Therefore, I created this Github ticket for discussing the potential options going forward.