#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, 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 requires PermissionNormConflictFinding@Context.

#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, 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 requires PermissionNormConflictFinding@Context.

The first useful move is to name the beneficiary reference, permitted-action specification or checked work, policy and bounded context, scope, 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 an accountable 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. This support pattern is not a method, gate, permit carrier, work plan, or generic authorization object.

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 a current role assignment; the reader position does not perform those acts.

#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 governed concern is the smallest exact permission result needed for one beneficiary, action specification, context, scope, and window. The act, permit episteme, publication carrier, evidence relation, admissibility predicate, readiness relation, gate decision, actual work, and work result keep their direct owners.

#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 ::= RoleRef | RoleAssignmentRef | PartyRef

The participant meaning is stable: the exact entity designated by the grant as beneficiary. The reference branch changes only the exercise-eligibility test:

• RoleAssignmentRef covers that exact current assignment.
• RoleRef covers current assignments that instantiate the role in the declared context under the grant policy; the role value itself does not perform work.
• 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 direct-owner decision.

#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
  boundedContextRef: U.BoundedContextRef
  scope: U.ClaimScope
  evaluationWindow: QualificationWindowPolicy
  checkedProhibitionRefs: set<ClaimIdRef>
  result: nonProhibited | unresolved
  evaluationWorkRef: WorkRef

NonViolationFinding@Context <: U.Episteme
  workRef: WorkRef
  performerAssignmentRefs: set<RoleAssignmentRef>
  onBehalfOfRelationOccurrenceRef?: U.EntityRef
  normativeFrameRef: U.EpistemeRef
  frameCurrentnessResultRef: U.EpistemeRef
  frameCompletenessForUseResultRef: U.EpistemeRef
  boundedContextRef: U.BoundedContextRef
  scope: U.ClaimScope
  evaluationWindow: QualificationWindowPolicy
  checkedProhibitionRefs: set<ClaimIdRef>
  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, proves absence outside its frame, or becomes a world-side relation.

For NonViolationFinding@Context, recover the actual performer systems from the named Work and cite their exact covering U.RoleAssignment occurrences. If the checked norm instead turns on work done for a PartyRef, cite the already obtaining subject-owned on-behalf-of relation occurrence. These are direct 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
  grantorAssignmentRef: RoleAssignmentRef
  grantValidityPolicyRef: U.EpistemeRef
  boundedContextRef: U.BoundedContextRef
  scope: U.ClaimScope
  validityWindow: QualificationWindowPolicy
  revocationOrSupersessionRef?: SpeechActRef

The beneficiary and permitted-action specification are participants. Grantor assignment, instituting act, policy, context, scope/window, and revocation are constructive ground or qualifiers, not collapsed participants.

The relation begins only when an admitted holder U.System performs a U.SpeechAct under the exact grantorAssignmentRef, the act satisfies the current policy's grant-validity predicate, and it institutes permission for the named participants. The assignment's HolderSystemSlot must resolve to that system: the system performs the act, while the assignment supplies its role and authority ground and never acts. 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/context, 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.EntityRef
      // resolves to one GrantedPermissionRelation@Context occurrence

semanticDirection: ExercisingWorkSlot -> GrantedPermissionOccurrenceSlot

RelationOccurrenceQualifiers:
  beneficiaryAssignmentRef?: RoleAssignmentRef
  onBehalfOfRelationOccurrenceRef?: U.EntityRef
  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 RoleAssignmentRef beneficiary, the grant's assignment must cover the Work and have that performer as its holder. For a RoleRef, beneficiaryAssignmentRef names the covering assignment that instantiates the role. For a PartyRef, the performer must be that party or onBehalfOfRelationOccurrenceRef must cite the already obtaining subject-owned relation 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, cite that item through its direct owner; 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. It does not satisfy or discharge an obligation and does not consume the grant unless 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; a separate prohibition, commitment, admissibility, or work owner decides any further consequence.

#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
  deciderAssignmentRef: RoleAssignmentRef
  decisionAuthorityRelationOccurrenceRef: U.EntityRef
  selectedGrantOccurrenceRef?: U.EntityRef
  selectedNormClaimRef?: ClaimIdRef
  effectiveScope: U.ClaimScope
  effectiveWindow: QualificationWindowPolicy
  reopenConditionRef: ClaimIdRef

PermissionNormConflictFinding@Context <: U.Episteme
  grantedPermissionOccurrenceRef: U.EntityRef
  conflictingNormClaimRef: ClaimIdRef
  overlapScope: U.ClaimScope
  overlapWindow: QualificationWindowPolicy
  governingPrecedencePolicyRef: U.EpistemeRef
  applicablePrecedenceRuleRef?: ClaimIdRef
  decisionAuthorityRelationOccurrenceRef?: U.EntityRef
  resolutionWorkRef?: WorkRef
  resolutionResultRef?: PermissionConflictResolutionResultRef
  blockedWorkOrRelianceRef: U.EntityRef
  disposition: unresolved | settledByApplicableRule | settledByDecisionResult
  reopenConditionRef: ClaimIdRef

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. applicablePrecedenceRuleRef 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 subject-owned authority relation that 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. The system decides; neither its assignment, authority relation, policy, nor organizational label performs the work.

PermissionConflictResolutionResult@Context is the exact decision result for this conflict, not a generic owner record. Exactly one of selectedGrantOccurrenceRef or selectedNormClaimRef is filled. Its deciderAssignmentRef 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 role is named. Permit text, readiness, or a passing gate does not silently defeat the prohibition.

#Keep the handshakes narrow

#Archetypal Grounding

Strong grant and exercise. Admitted system MaintenanceCoordinator-A performs a policy-valid grant speech act under MaintenanceCoordinator-A@DayShift, the exact grantor assignment whose holder is that system. The act institutes MaintenanceCalibrationGrant-2026-07-19 : GrantedPermissionRelation@Context for MaintenanceTechnicianRole to run CalibrationProcedure-v3 during one service window. Its beneficiary is a RoleRef. Beneficiary assignment Tech-17@Shift-B instantiates that role for admitted technician system Tech-17; 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; Tech-17@Shift-B covers the Work and instantiates the beneficiary role, so the beneficiary predicate holds. CalibrationExercise-17B : PermissionExerciseRelation@Context therefore connects CalibrationWork-17B to MaintenanceCalibrationGrant-2026-07-19, cites beneficiaryAssignmentRef=Tech-17@Shift-B, and states the work interval and scope. No auxiliary match or eligibility finding is created. The assignments ground the grant and work attribution but perform neither act. The grant remains current for the rest of the window because the policy is not single-use. No obligation, readiness, capability, gate passage, safe result, or successful calibration is inferred.

Weak finding. A policy reviewer checks a named, current, sufficiently complete plant-access frame and finds no prohibition applicable to the role, 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, performerAssignmentRefs={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 role. 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 role-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, admitted system SafetyDirector-3 performs CalibrationConflictDecisionWork-8 under SafetyDirector-3@EmergencyShift; the separately obtaining PlantEmergencyExceptionAuthority-8 relation authorizes that decision, and current CalibrationConflictResolutionResult-8 selects the prohibition claim for the stated scope/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 tested: 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 owners.

#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/revoking speech acts; A.6.B and A.6.C for deontic claim classification and contract 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 owners without turning evidence or a permit carrier into the permission relation.
• Does not replace: role assignment, capability, plan, gate, admissibility, policy precedence, evidence, performed work, result, safety, assurance, or commitment owners.

#A.2.8.PER:End

Last Updated: 2026-07-20 — this section last modified in upstream FPF commit d6af871b (github.com/ailev/FPF)