fpf.tools
Library / First Principles Framework (FPF) - Core Conceptual Specification
Jump to passage
In this reading
Source · lines 13986–14004

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 14:36:52 UTC · snapshot created 2026-10-03 14:38:14 UTC · last check 2026-10-03 15:30:10 UTC

A.6.0:4.4 - Declare participant meanings and operation parameters under different specializations

For each world-side participant meaning whose reusable declaration is current, a RelationSignature declares one A.6.5 SlotSpec. The following code sketch is a compact representation of that declaration:

SlotSpec := <SlotKind, ValueKind, refMode>
refMode := ByValue | RefKind
ComponentMeaning in a RelationSignature
SlotKindThe declaration-local name by which this RelationSignature distinguishes one participant meaning of its EntityOfConcern relation kind. It is not a participant, system-role kind, or mathematical operand.
ValueKindThe exact world-side kind admitted for the relation participant.
refModeHow a receiving episteme, such as an assertion, description, or occurrence record, carries a participant designation: by value or through one exact governed RefKind. That designation denotes the actual participant. The occurrence record and the relation occurrence are distinct.

Use A.6.5 to declare these participant meanings. In the simple MaintenanceInspectionAssignment species, use HolderSystemSlot and one declaration-local AssignedSystemRoleKindSlot with MaintenanceSystemRoleKindDomain as its ValueKind and ByValue as its refMode. In InspectionAssignment-17, InspectorSystemRole is the assigned-kind participant value. A stronger species adds only a real participant that changes its predicate or occurrence identity. Taxonomy episteme, reference scheme, interval description, and generic context may interpret an assertion but are not generic world-side assignment participants. Do not force SlotSpecs into a one-off assertion that has no receiving typed use.

A formal or mechanism declaration may instead need named operation arguments and a result. A.6.1 governs that OperationAlgebra. A representation may use a mathematical operand order, product, function, or tuple. A.6.3.RT governs a same-EntityOfConcern representation-scheme transition; C.29 governs only a mathematical-lens use. Those operation parameters do not become RelationSignature SlotSpecs or SlotKinds merely because the same notation uses angle brackets or numbered arguments. When a relation claim consumes a mathematical representation, state an explicit correspondence between the representation’s operands and the independently declared SlotSpecs.