A.2.8.PER:4 - Solution

A.2.8.PER:4.1 - Keep the permission objects separate

Use exactly the object warranted by the current claim:

• NonProhibitionFinding@Context is a frame-relative episteme returned before action when a sufficiently complete current normative frame contains no applicable prohibition.
• GrantedPermissionRelation@Context is an enduring strong permission instituted under an exact policy.
• PermissionExerciseRelation@Context connects actual dated work to one obtaining grant occurrence when action and beneficiary eligibility match.
• NonViolationFinding@Context is a frame-relative episteme about actual work that instantiates no applicable prohibition in the checked frame.
• PermissionNormConflictFinding@Context is an episteme exposing an incompatible current grant and prohibition or commitment over matching content, scope, and window.

Absence of any one object does not imply another. In particular, no grant is inferred from a weak finding, no exercise is inferred from a grant, and work outside a grant is not called a violation of that grant.

A.2.8.PER:4.2 - Use the closed beneficiary reference family

PermissionBeneficiaryRef ::=
  exactly one branch is present:
    beneficiarySystemRoleKindRef?: U.KindRef resolving to one exact local system-role kind
    beneficiarySystemRoleAssignmentRef?: U.RelationRef constrained to U.SystemRoleAssignment
    beneficiaryPartyRef?: PartyRef

The entity designated by the grant is its beneficiary. Apply the exercise-eligibility test for its reference branch:

• beneficiarySystemRoleAssignmentRef names one assignment occurrence and its declared species and applies only to that occurrence.
• beneficiarySystemRoleKindRef names one exact local system-role kind; the policy states which current assignments to that kind make an actual performer eligible.
• PartyRef covers work only when its exact performer or on-behalf-of relation satisfies the policy. Shared naming or organizational membership is insufficient.

This is a closed ref union over admitted U.Entity values, not U.PermissionBeneficiary, U.Authorization, or another new U-kind. A materially different beneficiary meaning requires a separate decision under the applicable subject pattern.

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.

A.2.8.PER:4.4 - Declare the strong granted-permission relation

GrantedPermissionRelation@Context <: U.Relation

RelationSignature:
  PermissionBeneficiarySlot:
    SlotKind: PermissionBeneficiarySlot
    ValueKind: U.Entity
    refMode: PermissionBeneficiaryRef
  PermittedActionSpecificationSlot:
    SlotKind: PermittedActionSpecificationSlot
    ValueKind: U.Episteme
    refMode: U.EpistemeRef

semanticDirection: PermissionBeneficiarySlot -> PermittedActionSpecificationSlot

RelationOccurrenceGroundAndQualifiers:
  institutingSpeechActRef: SpeechActRef
  grantorSystemRoleAssignmentRef: U.RelationRef constrained to U.SystemRoleAssignment
  grantValidityPolicyRef: U.EpistemeRef
  scope: U.ClaimScope
  validityWindow: QualificationWindowPolicy
  revocationOrSupersessionRef?: SpeechActRef

The beneficiary and permitted-action specification are participants. The grantor system-role assignment, instituting act, policy, ClaimScope, validity window, and revocation are constructive grounds or qualifiers.

The relation begins only when an admitted holder U.System performs a U.SpeechAct under the exact grantorSystemRoleAssignmentRef, the act satisfies the current policy’s grant-validity predicate, and it institutes permission for the named participants. The assignment’s HolderSystemSlot resolves to that system: the system performs the act, while the assignment supplies only the holder and assigned-kind fact used by the policy. Any authority claim required by the policy obtains independently. The relation obtains while beneficiary applicability, policy continuation, scope, and window hold and no valid revocation or supersession ends it.

One occurrence is identified by the instituting speech-act occurrence, exact beneficiary ref and ref kind, action-specification edition, policy edition, ClaimScope, and effective interval. Beneficiary change, renewal, materially changed action specification, non-carried policy edition, or revocation ends or splits the occurrence. A policy edition preserves it only through an explicit satisfied carry-forward rule.

A.2.8.PER:4.5 - Declare actual exercise

PermissionExerciseRelation@Context <: U.Relation

RelationSignature:
  ExercisingWorkSlot:
    SlotKind: ExercisingWorkSlot
    ValueKind: U.Work
    refMode: WorkRef
  GrantedPermissionOccurrenceSlot:
    SlotKind: GrantedPermissionOccurrenceSlot
    ValueKind: U.Relation
    refMode: U.RelationRef constrained to GrantedPermissionRelation@Context
      // resolves to one exact obtaining grant occurrence

semanticDirection: ExercisingWorkSlot -> GrantedPermissionOccurrenceSlot

RelationOccurrenceQualifiers:
  beneficiarySystemRoleAssignmentRef?: U.RelationRef constrained to U.SystemRoleAssignment
  onBehalfOfRelationOccurrenceRef?: U.RelationRef constrained to the direct on-behalf-of relation kind
  exerciseScope: U.ClaimScope
  exerciseInterval: QualificationWindowPolicy

Decide exercise from two observable questions about the existing objects: did this dated Work instantiate the grant’s permitted-action specification, and did its actual performer satisfy the grant’s beneficiary branch? For a beneficiarySystemRoleAssignmentRef branch, the named assignment must cover the Work and have that performer as holder. For a beneficiarySystemRoleKindRef branch, beneficiarySystemRoleAssignmentRef names the exact covering assignment whose declaration-local kind slot contains that kind and which satisfies the policy’s eligibility rule for that kind. For a beneficiaryPartyRef branch, the performer must be that party or onBehalfOfRelationOccurrenceRef must cite the already obtaining relation whose predicate is defined by its subject pattern and whose use is licensed by the policy. If either question fails, this exercise relation does not obtain.

The match and eligibility are direct obtaining predicates over the Work, grant, action specification, performer, and cited assignment or on-behalf-of relation. If a receiving assurance or audit use needs a separately recorded evaluation or evidence item, identify that item through the applicable evaluation or evidence-use relation; do not mint a placeholder episteme merely to fill this relation.

The exercise relation obtains only when those two predicates hold, the grant obtains throughout the exercise interval, and the work remains in scope. The work is a satisfier of permitted action content. Judge any obligation-satisfaction or discharge claim under the separate evaluation or compliance rule (A.2.8:4.6). The work consumes the grant only when the named policy explicitly makes it single-use or quota-bound.

Non-exercise leaves an obtaining grant unused and ordinarily still obtaining; it does not establish NonViolationFinding@Context. Exercise establishes only the exercise relation and likewise does not establish that finding without the separate checked-frame evaluation. Work outside the action specification, beneficiary eligibility, scope, or window does not exercise the grant; any further consequence is established only by the applicable prohibition, commitment, admissibility, or Work-related predicate. If a decision is required, an admitted system performs the dated decision Work under the relevant Method, covering assignment, and authority relation.

A.2.8.PER:4.6 - Expose conflict without inventing precedence

PermissionConflictResolutionResultRef ::= U.EpistemeRef
  // resolves only to PermissionConflictResolutionResult@Context

PermissionConflictResolutionResult@Context <: U.Episteme
  conflictFindingRef: U.EpistemeRef
  governingPrecedencePolicyRef: U.EpistemeRef
  resolutionWorkRef: WorkRef
  deciderSystemRef: U.EntityRef
  deciderSystemRoleAssignmentRef: U.RelationRef constrained to U.SystemRoleAssignment
  decisionAuthorityRelationOccurrenceRef: U.RelationRef constrained to the direct decision-authority relation kind
  selectedGrantOccurrenceRef?: U.RelationRef constrained to GrantedPermissionRelation@Context
  selectedNormClaimAddress?: ClaimAddress
  effectiveScope: U.ClaimScope
  effectiveWindow: QualificationWindowPolicy
  reopenConditionClaimAddress: ClaimAddress

PermissionNormConflictFinding@Context <: U.Episteme
  grantedPermissionOccurrenceRef: U.RelationRef constrained to GrantedPermissionRelation@Context
  conflictingNormClaimAddress: ClaimAddress
  overlapScope: U.ClaimScope
  overlapWindow: QualificationWindowPolicy
  governingPrecedencePolicyRef: U.EpistemeRef
  applicablePrecedenceRuleAddress?: ClaimAddress
  decisionAuthorityRelationOccurrenceRef?: U.RelationRef constrained to the direct decision-authority relation kind
  resolutionWorkRef?: WorkRef
  resolutionResultRef?: PermissionConflictResolutionResultRef
  blockedWorkOrRelianceRef: U.EntityRef
  disposition: unresolved | settledByApplicableRule | settledByDecisionResult
  reopenConditionClaimAddress: ClaimAddress

Create the finding only when the grant and current prohibition or commitment concern the same beneficiary/action content, overlapping scope/window, and incompatible practical conclusions. Check that match directly from the two claims and their participants. Permission and an obligation to perform the same action are not automatically in conflict.

Resolve the conflict through exactly one of two branches:

1. The current policy already decides. applicablePrecedenceRuleAddress cites the policy claim whose stated conditions match this beneficiary, action, scope, and window. Set settledByApplicableRule only when that rule itself selects which claim governs the blocked use.
2. A decision is required. Name the admitted U.System that decides, the covering assignment under which it performs the dated resolutionWorkRef, and the independently obtaining authority relation whose predicate is defined by its subject pattern and which authorizes this decision. The direct result relation for that decision must connect the Work to a current PermissionConflictResolutionResult@Context selecting either the grant occurrence or the conflicting norm claim for the stated scope/window.

PermissionConflictResolutionResult@Context is the exact decision result for this conflict. Exactly one of selectedGrantOccurrenceRef or selectedNormClaimAddress is filled. Its deciderSystemRoleAssignmentRef must cover resolutionWorkRef and have deciderSystemRef as holder; decisionAuthorityRelationOccurrenceRef must independently authorize that decision. If no policy rule decides and no such current result exists, the disposition remains unresolved, even when a responsible office or system-role kind is named. Permit text, readiness, or a passing gate does not silently defeat the prohibition.

A.2.8.PER:4.7 - Keep the handshakes narrow