A.2.8.PER:4.3 - Record weak permission and non-violation as findings

NonProhibitionFinding@Context <: U.Episteme
  beneficiaryRef: PermissionBeneficiaryRef
  permittedActionSpecificationRef: U.EpistemeRef
  normativeFrameRef: U.EpistemeRef
  frameCurrentnessResultRef: U.EpistemeRef
  frameCompletenessForUseResultRef: U.EpistemeRef
  scope: U.ClaimScope
  intendedUse:
  evaluationWindow: QualificationWindowPolicy
  checkedProhibitionAddresses: set<ClaimAddress>
  result: nonProhibited | unresolved
  evaluationWorkRef: WorkRef

NonViolationFinding@Context <: U.Episteme
  workRef: WorkRef
  performerSystemRoleAssignmentRefs: set<U.RelationRef constrained to U.SystemRoleAssignment>
  onBehalfOfRelationOccurrenceRef?: U.RelationRef constrained to the direct on-behalf-of relation kind
  normativeFrameRef: U.EpistemeRef
  frameCurrentnessResultRef: U.EpistemeRef
  frameCompletenessForUseResultRef: U.EpistemeRef
  scope: U.ClaimScope
  intendedUse:
  evaluationWindow: QualificationWindowPolicy
  checkedProhibitionAddresses: set<ClaimAddress>
  result: nonViolating | unresolved
  evaluationWorkRef: WorkRef

nonProhibited and nonViolating are admissible only when the named frame is current and explicitly sufficiently complete for the intended use. Otherwise the finding is unresolved. Neither finding institutes permission or proves absence outside its frame.

Every ClaimAddress in this pattern means the reusable C.2.1 ClaimAddress: an exact episteme-edition reference plus an intrinsic claim identity declared by that edition’s ClaimGraph. A heading, row number, file location, or printed token is insufficient.

For NonViolationFinding@Context, recover the performer Systems from the named Work and cite each covering assignment occurrence and its declared U.SystemRoleAssignment species. If the checked norm instead turns on Work done for a PartyRef, cite the obtaining on-behalf-of relation defined in its pattern. These are case facts used by the evaluation. Omit the on-behalf-of reference when no such branch is used.