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

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 11:52:20 UTC · snapshot created 2026-10-03 11:53:41 UTC · last check 2026-10-03 12:10:10 UTC

A.6.REL:4.1.3 - Reusable declaration episteme
Canonical FPF nameWhat this object isDirect relation to preserveNaming ruleSubject pattern
RelationSignaturea U.Signature declaration episteme whose EntityOfConcern is the direct relation kindits content states a reusable declaration of the relation-participant meanings, obtaining predicate, applicability, occurrence-identity rule, and only the SlotSpecs needed by receiving typed usesname the declaration episteme from its accepted direct relation species, for example the RelationSignature for MaintenanceInspectionAssignment; the name denotes the declaration episteme, not the relation kind or an occurrenceA.6.0
SlotSpeca declaration-content component identified inside one exact RelationSignature by its declaration-local SlotKindcorresponds to one relation-participant meaning and states the actual participant ValueKind plus the receiving-episteme designation modeuse the exact declaration-local name supplied by the subject pattern, such as HolderSystemSlot in the MaintenanceInspectionAssignment signature; refer to the complete component as that SlotSpec in the named RelationSignatureA.6.5

SlotKind, ValueKind, and refMode answer different questions. SlotKind identifies the declaration component locally. ValueKind is the independently governed kind of the actual relation participant. refMode states how a receiving episteme designates that participant. Together they specify one declaration component; world-side entities and occurrences keep their independently governed identities.