#Granted Permission, Exercise, and Non-Prohibition

A.2.8.PER · Stable · Definitional ontic support pattern · Normative unless marked informative · Part A - Kernel Architecture Cluster

#About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a FPF Reference product feature page.

#How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

Type: Definitional ontic support pattern Status: Stable Normativity: Normative unless marked informative

Use this pattern when a policy, approval, permit, system-role rule, boundary claim, readiness check, or later work use needs to distinguish five questions:

#Keywords

• weak non-prohibition finding
• policy-valid strong grant
• matching dated-work exercise
• checked non-violation
• permission or prohibition conflict
• exact policy rule or decision result.

#Relations

#Content

#Use this when

Use this pattern when a policy, approval, permit, system-role rule, boundary claim, readiness check, or later work use needs to distinguish five questions:

• whether a sufficiently complete current frame supports a NonProhibitionFinding@Context;
• whether a valid grant currently obtains as GrantedPermissionRelation@Context;
• whether dated matching work exercises it through PermissionExerciseRelation@Context;
• whether checked actual work supports a NonViolationFinding@Context; and
• whether an incompatible current grant and norm require PermissionNormConflictFinding@Context.

The first useful move is to name the beneficiary reference, permitted-action specification or checked work, current normative-frame edition and policy, ClaimScope, intended use, window, and the exact result needed now. Return exactly the warranted NonProhibitionFinding@Context, GrantedPermissionRelation@Context, PermissionExerciseRelation@Context, NonViolationFinding@Context, or PermissionNormConflictFinding@Context; do not infer one from another.

Not this pattern when. Use A.2.8 for one actual bearer's obligation, recommendation-as-duty, or prohibition; A.2.9 for the communicative work that institutes or revokes a grant; A.6.B for L/A/D/E classification; A.15.5 for work-entry readiness; A.21 for gate decisions; and A.15.1 for the identity and result of performed work.

The primary reader is a policy, boundary, work-planning, assurance, or operations practitioner who must decide exactly what a permission-looking claim can support. The performer of a grant speech act or later Work remains an admitted system under one exact obtaining system-role assignment.

#Problem frame

Permission-looking language often compresses unlike values. “No rule forbids it” may be an incomplete search result. “The permit allows it” may refer to a document, an issuing act, or an enduring relation. “We used the permit” may mean only that a badge was visible, while no matching work occurred. A green gate can also look as if it defeated a current prohibition.

The concern is the smallest exact permission result needed for one beneficiary, action specification, normative-frame edition, ClaimScope, intended use, and window. The act, permit episteme, publication carrier, evidence relation, admissibility predicate, readiness relation, gate decision, actual Work, and work result remain distinct and are handled under their respective subject patterns.

#Problem

How can FPF represent positive permission without turning it into an obligation modality, absence-of-evidence claim, permit document, gate result, readiness label, capability, or performed action?

A conforming account must make weak and strong permission different, keep grant occurrence identity inspectable, connect only eligible matching work to a current grant, keep both exercise and non-exercise from establishing a frame-relative non-violation finding, and expose same-scope normative conflicts instead of resolving them by display or wording.

#Forces

#Solution

#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.

#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 participant meaning is stable: the exact entity designated by the grant as beneficiary. The reference branch changes only the exercise-eligibility test:

• 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.

#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](/generated/patterns/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, not a new beneficiaryPerformanceBinding episteme. Omit the on-behalf-of reference when no such branch is used.

#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.

#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. 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.

No actionMatchFinding or beneficiaryEligibilityFinding is required. 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 binding, 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.

#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; do not require a beneficiaryAndActionMatchFinding wrapper. 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.

#Keep the handshakes narrow

#Archetypal Grounding

Assignment, permission, access, and authority. AdminAssignment is a declared U.SystemRoleAssignment species. Occurrence AdminAssignment-4 has admitted System ServiceOperator-4 as holder and AdminSystemRole as assigned-kind value. That fact alone establishes no grant, access, or decision authority. A policy-valid speech act can separately institute one GrantedPermissionRelation@Context for AdminSystemRole, RestartServiceActionSpec, the declared scope, and the declared window. Matching dated Work exercises that grant only through a separate PermissionExerciseRelation@Context. If service access is claimed, cite its domain access predicate and participants; when no such predicate is available, return A.6.RCD missing-governor[direct service-access relation]. Permission, exercise, access, authority, assignment, and Work therefore remain separate.

Strong grant and exercise. PlantPermissionGrantorAssignment is a declared U.SystemRoleAssignment species. Occurrence MaintenanceCoordinator-A@DayShift has admitted System MaintenanceCoordinator-A as holder, and that System performs a policy-valid grant speech act under the assignment. The act institutes MaintenanceCalibrationGrant-2026-07-19 : GrantedPermissionRelation@Context for MaintenanceTechnicianSystemRole to run CalibrationProcedure-v3 during one service window. Its beneficiary uses beneficiarySystemRoleKindRef.

PlantCalibrationTechnicianAssignment is another declared species. Occurrence Tech-17@Shift-B has admitted technician System Tech-17 as holder and MaintenanceTechnicianSystemRole as assigned-kind value. Tech-17 performs dated CalibrationWork-17B under that assignment. The Work instantiates CalibrationProcedure-v3 within the grant's zone, window, and scope, so the action-match predicate holds. The assignment covers the Work and satisfies the kind branch, so the beneficiary predicate holds.

CalibrationExercise-17B : PermissionExerciseRelation@Context therefore connects CalibrationWork-17B to MaintenanceCalibrationGrant-2026-07-19, cites beneficiarySystemRoleAssignmentRef=Tech-17@Shift-B, and states the Work interval and scope. No auxiliary match or eligibility finding is created. The assignments supply holder and assigned-kind facts for the grant and Work attribution; any required authority relation obtains independently. The grant remains current for the rest of the window because the policy is not single-use. Claims about obligation, readiness, capability, gate passage, a safe result, or successful calibration need their own grounds.

Weak finding. A policy reviewer checks a named, current, sufficiently complete plant-access frame and finds no prohibition applicable to the exact system-role kind, action specification, zone, and window. The result is NonProhibitionFinding@Context(result=nonProhibited), not an instituted grant. If the emergency-policy register cannot be checked, the result is unresolved.

Actual-Work non-violation. After CalibrationWork-17B is performed, CalibrationComplianceEvaluation-17B : U.Work checks that Work against PlantCalibrationNormativeFrame-2026-07-19-e3, whose currentness and sufficient completeness for the technician, procedure, zone, and service-window use are named and whose applicable prohibitions are checked. The result is NonViolationFinding@Context(workRef=CalibrationWork-17B, performerSystemRoleAssignmentRefs={Tech-17@Shift-B}, normativeFrameRef=PlantCalibrationNormativeFrame-2026-07-19-e3, evaluationWorkRef=CalibrationComplianceEvaluation-17B, result=nonViolating). It needs no beneficiary-binding episteme: the covering assignment already relates the performer system to the beneficiary system-role kind. The separate exercise relation shows which grant the Work exercised; exercise alone does not establish non-violation, and non-exercise alone does not establish it either. If the frame is stale or insufficiently complete for this use, the non-violation result is unresolved.

Conflict and non-use. The system-role-kind-level calibration grant remains published while ContaminatedZoneEntryProhibition-7 forbids the same beneficiary and calibration action in Zone 7 during an overlapping interval. In the direct-rule case, EmergencyCalibrationPrecedencePolicy-e5 contains applicable claim CZ7-Prohibition-Overrides-CalGrant. The rule's conditions match, so the finding is settledByApplicableRule, cites that rule, and returns “do not enter Zone 7” for the blocked Work.

In a discretionary Zone 8 case, PlantSafetyDecisionAssignment is a declared U.SystemRoleAssignment species. Occurrence SafetyDirector-3@EmergencyShift has admitted System SafetyDirector-3 as holder, and that System performs CalibrationConflictDecisionWork-8 under the assignment. The separately obtaining PlantEmergencyExceptionAuthority-8 relation authorizes that decision, and current CalibrationConflictResolutionResult-8 selects the prohibition claim for the stated scope and window. Only then is the finding settledByDecisionResult.

A second Zone 8 request that merely names the Safety Director but has no dated decision Work or current result remains unresolved. A visible permit and green readiness tile cannot repair either gap. If no calibration Work occurs, the permission is neither exercised nor violated.

#Bias-Annotation

Lenses: Gov, Arch, Onto/Epist, Prag, Did. Scope: permission-specific support across boundary and work uses.

The chief bias is document-and-display authority: a readable permit, badge, policy response, or green gate looks stronger than its recoverable relation. The repair is exact ground, participants, policy/currentness, scope/window, and separate evidence. A second bias is obligation-shaped deontics; the exercise and non-exercise rules preserve permission as latitude.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

Permission becomes inspectable without being inflated into a universal authorization ontology. Practitioners can distinguish a tentative frame-relative result from an enduring grant and from actual exercise, and can stop on unresolved conflict without letting a gate or permit display choose precedence. The cost is recording enough policy, identity, scope, window, and eligibility detail to support the intended use.

#Rationale

Positive permission has different satisfaction and failure behavior from obligation. A grant can obtain while unused; non-use ordinarily violates nothing; matching action can exercise the grant without discharging a duty. Separating weak findings, strong grants, and exercise preserves these practical consequences while using existing episteme, relation, speech-act, policy, work, and evidence-use patterns.

#SoTA-Echoing

These sources change the practical record and its failure results. They do not license a generic authorization kind, beneficiary kind, permit-as-relation shortcut, or automatic precedence rule.

#Relations

• Coordinates with: A.2.8 for obligations, recommendations-as-duty, and prohibitions; A.2.9 for instituting or revoking speech acts; and A.6.B and A.6.C for deontic claim classification and agreement-like boundary-language unpacking.
• Supplies inputs to: A.15.5 readiness and direct mechanism/gate checks only when their own predicates explicitly consume a current grant, finding, or conflict result.
• Relates to work through: A.15.1 for dated U.Work identity and PermissionExerciseRelation@Context for the separate exercise claim.
• Uses evidence from: A.10 and publication/currentness patterns for claims about the permission relation and its permit carriers.
• Does not replace: system-role kind or assignment, capability, plan, gate, admissibility, policy precedence, evidence, performed Work, result, safety, assurance, responsibility, authority, access, or commitment patterns.

#A.2.8.PER:End

Last Updated: 2026-09-10 — upstream FPF commit a87d0ef4 (github.com/ailev/FPF)