#Relation-Declaration Slot Discipline - SlotKind, ValueKind, RefKind, and participant-designation discipline

A.6.5 · Stable · Architectural (A) · 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: Architectural (A) Status: Stable Normativity: Normative unless marked informative

Plain name. Relation-declaration slot discipline.

#Relations

#Content

#Problem frame

Plain name. Relation-declaration slot discipline.

Use this when. Use this pattern after the direct relation kind has been recovered and a reusable typed declaration of its participants is current for another assertion, comparison, substitution, or reference use. Typical triggers are one relation declaration reused across patterns, another relation referring to an explicitly individuated occurrence, or an engineer checking a proposed replacement participant against the declared ValueKind.

Primary working reader and concern. The intended reader is an engineer making one relation declaration reusable while keeping actual relation participants, the RelationSignature episteme, relation-participant designations in assertions or descriptions, relation obtaining, and relation occurrence identity distinct.

Primary EntityOfConcern. One SlotSpec declaration in one exact RelationSignature.

First useful move. Write the readable relation sentence, identify the relation kind and relation-participant meanings, and name where its predicate, applicability, and identity rule are defined. For every relation-participant meaning whose reusable typed declaration is current, add one SlotSpec to the RelationSignature, using the compact declaration notation SlotSpec = <SlotKind, ValueKind, refMode>. refMode states how an assertion or relation-occurrence description episteme carrying a relation-participant designation denotes the actual participant. When a reference is used, it retains its RefKind and its referent retains the declared ValueKind; the SlotSpec remains declaration content. If the direct relation or its relation obtaining predicate is still unclear, stop and use A.6.P or A.6.RSIR; declaration notation cannot recover a missing ontology.

First-minute result. For Robot_7 is assigned to InspectorSystemRole for this inspection shift, declare a species under U.SystemRoleAssignment, such as InspectionShiftAssignment, and state one occurrence for the shift. When reusable participant typing is needed, give HolderSystemSlot the value kind U.System and entity-reference mode; give AssignedSystemRoleKindSlot the value domain InspectorSystemRoleKindDomain and by-value reference mode. Add another participant only when it changes the predicate or occurrence identity. An assertion designates the occurrence's participants and states its assignmentInterval separately. Stop there unless later work must substitute a participant, distinguish this assignment episode from another, or test an A.2.5 state condition.

What goes wrong if missed. In the readable sentence Robot_7 is assigned to InspectorSystemRole, the holder system, the exact system-role kind, each declaration-local SlotKind, and each participant designation carried by an assertion episteme can collapse into one word such as role or holder. A later claim then cannot tell what may be substituted, what retains identity, or whether it refers to a system, a system-role kind, an assignment occurrence, an assignment-state relation, or an assertion about either occurrence.

What this buys. Engineers retain a readable relation sentence while its load-bearing uses gain exact participant typing, unambiguous reference use, and a clear route to the definitions or constraints for predicate truth and occurrence identity.

Not this pattern when. Use A.6.P or A.6.RSIR first while the relation kind or its participants remain unresolved. Use A.6.REL for relation-occurrence identity, A.6.0 for the containing U.Signature, C.2.1 for an assertion or description, and C.3 for a local kind needed by typed quantification. In every other case, find the direct relation's accepted definition before applying this slot discipline.

Select A.6.5 by the engineering use, not by a domain catalogue: one already recovered direct relation needs reusable participant typing in assertions or occurrence descriptions. Its RelationSignature contains one SlotSpec for each participant meaning actually reused, with a declaration-local SlotKind, the participant's exact ValueKind, and one designation mode. The worked cases below are contrasts only; none supplies another relation's predicate or definition.

The following objects meet at this boundary and remain distinct:

1. an obtaining relation occurrence in the world;
2. the direct relation kind and its predicate;
3. a RelationSignature episteme whose content includes SlotSpecs corresponding to the direct relation's relation-participant meanings and restates its predicate, applicability, and identity rule for reuse;
4. a SlotSpec containing the declaration-local SlotKind name for one relation-participant meaning, its actual-participant ValueKind, and its designation mode;
5. an assertion or other episteme claiming that the relation obtains.

Use the A.6.REL relation-object architecture. A relation-participant meaning is the relation-local semantic content specifying one domain contribution to the obtaining predicate. An actual relation participant is the concrete entity participating in an obtaining occurrence under that meaning while retaining its intrinsic kind. A SlotSpec is declaration content corresponding to the relation-participant meaning. A relation-participant designation is the value or reference of a declared RefKind carried by an assertion or relation-occurrence description episteme to denote the actual participant. Source-specific vocabulary keeps its meaning inside the source representation or ontology until an explicit correspondence relates it to the named FPF object.

The RelationSignature and SlotSpecs are declaration content about reusable relation semantics. The world-side relation obtains under its direct predicate and identity rule independently of those epistemes. In Tech register, SlotKind is the declaration-local kind by which one RelationSignature distinguishes a relation-participant meaning. World-side relation prose names the meaning and actual participant directly; the relation occurrence contains no SlotKind. In an assertion or relation-occurrence description episteme, the corresponding SlotSpec distinguishes a relation-participant designation carried by value or by a reference of the declared RefKind. External representation elements retain their source-specific names. A declared correspondence must relate such an element to a named SlotSpec before an FPF relation claim can reuse it.

#Problem

The engineering problem appears when the same relation declaration is used in another claim, substitution, or comparison. A ValueKind that covers participants for which the predicate has different meanings makes typed reuse unsound. A reference value leaves its referent kind unstated. A designator for an actual participant is promoted into a U-kind. A role value is confused with the system that holds it. A verb-shaped predicate is read as proof that the relation is work, a method, a transformation, or an acting holon.

These errors do more than blur terminology. They change which substitutions are valid, which object a later claim may reference, what makes the relation obtain, and which definition or constraint the repair must preserve.

#Forces

#Solution

Apply relation-declaration slot discipline only after the direct relation and its relation-participant meanings have been recovered. Give every relation-participant meaning needed by the current typed use one complete SlotSpec in the RelationSignature. Let the direct-relation definition supply the obtaining predicate and occurrence-identity rule. Follow the A.6.REL minimum-current-object rule: a later use adds only its current object and the direct relation to an already recoverable object rather than restating the complete relation-object architecture.

#Ontological status of the discipline

Relation-declaration slot discipline is a rule set, not a durable U-kind. This pattern reuses RelationSignature, SlotSpec, SlotKind, ValueKind, and RefKind from the existing signature and relation vocabulary; it introduces no U-kind. The notation U.RelationSlotDiscipline is not admitted: it has no separate instances, identity rule, grounding rule, constructive assembly, or ontic settlement. A.6.5 constrains one SlotSpec declaration belonging to one exact RelationSignature. Operation argument and result declarations remain under A.6.1; mathematical operands and their order remain representation elements under C.29.

A.15.3 may cite one exact SlotSpec as the target of a planned participant designation inside a U.WorkPlan. That citation does not fill the SlotSpec, extend SlotSpec to another description family, make the planned designation an actual participant, or make the direct relation obtain. Planned operation arguments and results instead cite their exact A.6.1 declarations. Only a declaration-local participant specification inside one exact RelationSignature is a SlotSpec. Method-description, plan, work, evaluation, card, schema, and record fields retain the kinds and declaration rules supplied by their defining patterns. A field that receives relation semantics follows the applicable declaration or C.29 correspondence route in §4.2; the field, SlotSpec, designation, and actual participant remain distinct.

#Keep pattern scope exact

None of these objects gets its identity or truth condition from A.6.5. A.6.5 supplies the participant-declaration and designation-typing discipline at their shared boundary.

#Declare one complete SlotSpec for each relation-participant meaning needed by typed reuse

The following code block is a compact representation of a declaration under C.29. Its assignment mark, angle brackets, order, and alternatives are notation elements; the prose below states their FPF meaning.

SlotSpec := <SlotKind, ValueKind, refMode>
refMode := ByValue | RefKind

SlotKind is the declaration-local kind by which one exact RelationSignature distinguishes one relation-participant meaning. HolderSystemSlot and AssignedSystemRoleKindSlot are different SlotKinds inside the InspectionShiftAssignment declaration even when a receiving assertion designates the holder by reference and the assigned system-role kind by value. A receiving semantic field is covered by an explicit declaration against one exact SlotSpec. An external or independently named representation field keeps its source name and requires an explicit C.29 correspondence. Neither route makes the field a SlotSpec or the designation an actual participant. A mathematical operand or numbered argument belongs to its mathematical representation, not to the relation declaration.

ValueKind is the exact world-side kind admitted for the actual participant corresponding to the declared participant meaning. Recover it from the accepted declaration that defines that kind. The declaration may settle a durable U-kind, a current C.3 kind, a Concept-Set entry, or an imported sort whose bridge states the corresponding FPF kind. If one proposed ValueKind hides several kinds for which the predicate has different meaning, recover their real common kind or split the relation kind. A prose list of alternatives does neither.

RefKind is the kind of reference used when a named-use assertion or relation-occurrence description episteme carries a relation-participant designation by reference. A system applying the declared resolution Method obtains a participant of the declared ValueKind as referent. U.EntityRef, U.HolonRef, U.EpistemeRef, and U.StructureRef are examples only where their exact RefKind declarations and admission predicates apply. The shorthand byRef is usable in a compact local sketch only when the exact RefKind is declared next to that sketch; it is not a complete refMode by itself.

ByValue means that an assertion or relation-occurrence description episteme carries a value as its relation-participant designation. By reference means that it carries a reference value of the declared RefKind as that designation. In both cases, the designation denotes the world-side actual participant. The reference value retains its RefKind, its referent retains the declared ValueKind, the SlotSpec remains declaration content, and the relation occurrence retains its direct identity.

Naming and source-token repair. Use ...Slot only for one declaration-local SlotKind inside one exact RelationSignature. Use ...Ref only for an admitted RefKind or for a reference value or designator of that kind; never use it for the actual participant or the SlotKind. Keep the participant's ValueKind name free of both suffixes. Thus HolderSystemSlot is the SlotKind, U.System is the participant ValueKind, and Robot_7_Ref : U.EntityRef is a reference designation whose referent is Robot_7 : U.System. If a source token such as holder conflates those objects, split them rather than cosmetically renaming the token. A concrete source field keeps its source name and is related to HolderSystemSlot only through an explicit declaration or C.29 correspondence.

#Apply the well-formedness constraints

The following labelled block presents seven rules for reviewing a declaration episteme; its labels and indentation organize those rules.

A6.5-S1 CompleteSlotSpec:
  every relation-participant meaning needed by reusable typed use has one SlotSpec
  with exactly one SlotKind, one ValueKind, and one refMode.

A6.5-S2 LocalSlotKind:
  SlotKind is interpreted only inside the exact RelationSignature that
  contains the corresponding SlotSpec.

A6.5-S3 ExactParticipantKind:
  each actual participant corresponding to the declared relation-participant meaning
  has the declared ValueKind; each receiving-episteme designation denotes such a participant.
  A C.3 kind ordered by an explicit U.SubkindOf relation may narrow
  that range only when typed membership or substitution is current.

A6.5-S4 HonestReference:
  when refMode is a RefKind, the receiving assertion or description carries
  a reference of that RefKind whose resolution denotes a participant
  of the declared ValueKind. The relation itself does not store it.

A6.5-S5 DirectPredicateDefinition:
  the identified direct-relation definition states the predicate,
  applicability, and any relation occurrence-identity rule.

A6.5-S6 NoHiddenUnion:
  one ValueKind does not hide participant kinds for which the direct
  predicate has different semantics. Recover one real common ValueKind or split the relation kind.

A6.5-S7 RepresentationBoundary:
  a representation or publication form does not become the
  world-side participant or relation occurrence by form.

A system performing typed substitution keeps the SlotSpec fixed and checks a proposed relation-participant designation against the exact ValueKind. A system performing retargeting changes a reference value in an assertion or description while preserving SlotKind, ValueKind, and RefKind. Neither operation changes a world-side participant or makes the direct predicate true. The identified direct-relation definition supplies that predicate and identity rule; the current case must supply the relevant facts or constituting history. A system applies the direct obtaining test to those facts or constituting history, and a claim-bearing episteme records affirmative or negative polarity. Only when an explicit reliance judgment is current does [A.10](/generated/patterns/A.10) or the receiving evaluation separately record supported, refuted, or unresolved reliance. Type compatibility, assertion polarity, evidence, and reliance establish neither obtaining nor occurrence identity.

#Distinguish predicate grammar from holonhood and agency

A relation predicate is often written as a verb phrase: a system is assigned to a system-role kind, a part belongs to a whole, one claim supports another, or one occurrence results from Work. The grammatical verb only helps express the predicate. It does not settle the ontological kind of what the expression denotes.

Use the following definitions for that distinction:

• A.15.1 and A.3.1 supply the constructive assembly, composition, identity, and meta-holon-transition conditions that admit U.Work and U.Method as holon kinds. U.Transformation is instead a root U-kind under A.3.4 for one independently grounded actual bounded change. Verb-shaped wording proves neither classification.
• One context-local system-role kind is admitted under C.3 and described through A.2; it is neither a holon nor an assignment. An admitted U.System participates as holder in an assignment occurrence whose species is declared under U.SystemRoleAssignment.
• U.Relation is an individuable obtaining relation occurrence under A.6.REL. A SlotSpec does not give it constructive parthood or meta-holon transition and does not admit it as a holon.
• Only an admitted U.System acts. A system may be classified by an exact local system-role kind and may participate as holder in an obtaining U.SystemRoleAssignment; neither the kind nor the assignment acts. Work is performed, a Method is applied in Work, and a transformation occurs or is carried out.

When one word could denote a relation predicate or a holon occurrence, first ground the participants and ask what obtaining or occurrence identity rule the receiving claim needs. Then find its definition. Do not decide by part of speech.

Predicate grammar also decides neither claim polarity nor reliance. An ordinary relational assertion states affirmative or negative polarity for the exact direct predicate; a forecast, scenario, counterfactual, permission, or other claim family retains the rules that define that claim family. Only when an explicit reliance judgment is current for the declared use does A.10 or the receiving evaluation separately state supported, refuted, or unresolved reliance. None of those claim-side distinctions makes the world-side relation obtain.

#Keep ordinary predicate parameters outside SlotSpec

A reusable predicate definition may be an ordinary A.6.0 U.Signature without being a RelationSignature. Its semantic parameters are not SlotSpecs unless an independently admitted direct relation kind has world-side participant meanings that a typed receiver must reuse. In particular, the dependentContent and baseContent parameters of RuleContentBasisFindingDefinition@R7 are U.ClaimGraph values in a predicate declaration. They do not name relation participants, SlotKinds, occurrence positions, or a new relation kind.

A C.2.1 assertion of derivedUsingRuleContent or evaluatedAgainstRuleContent designates those exact values and its exact derivation or criterion-selection claim. A record or formula may represent the parameters under C.29, but table shape does not turn them into SlotSpecs. If later work proposes a relation kind, it must independently pass A.6.RCD and E.24/E.24.UK with participant meanings, obtaining, applicability, and occurrence identity; the predicate declaration supplies none by implication.

#Use progressive elaboration

Start with the lightest object that supports the named engineering use. The branch diagram maps three independent receiving-use thresholds that share one recovered direct relation; none is a prerequisite for either of the others:

readable assertion of the recovered direct relation
  +-- reusable RelationSignature with SlotSpecs, when several uses need the same participant typing
  +-- explicit occurrence individuation, when a named claim or direct relation relies on occurrence identity
      +-- relation-occurrence description episteme, when a receiving episteme describes the occurrence
      +-- stable relation-occurrence reference, when a receiving episteme contains a designation of it
  +-- local C.3 kind with an extent rule, when typed quantification over corresponding participants is current

The branch marks are [C.29](/generated/patterns/C.29) representation edges showing which additional object each named use consumes. The branches are independent thresholds; explicit occurrence individuation does not require a RelationSignature. The direct-relation definition supplies the obtaining predicate and direct occurrence-identity rule, while current case facts or constituting history must satisfy the predicate before that rule distinguishes an occurrence.

The local-kind branch does not turn every participant qualification into a kind. It is justified only when membership, substitution, quantification, or U.SubkindOf reasoning will be performed.

#Dispatch the world-side fact, claim, and local kind

These readings do not leave a fourth object called RelationDefinedQualification. Do not introduce that name or E.24.RC.

They also do not justify a parallel S-kind hierarchy for relation-position readings. Keep the direct relation fact under its relation pattern, the claim under C.2.1, and introduce a C.3 local kind only when membership, substitution, quantification, or typed reasoning is current.

Do not replace that split with a generic KindWitnessedFillerSpec or filler record. The declaration's exact local ValueKind types the participant meaning; when typed quantification is current, a separately defined C.3 local kind and its membership rule supply the reusable classification.

#Read the SlotSpecs of a Direct System-Role-Assignment Species

A.2.1 defines the U.SystemRoleAssignment relation family through directly declared species. The family has no root RelationSignature that hides several participant laws. For the simple InspectionShiftAssignment species, a compatible RelationSignature declares these SlotSpecs under A.6.5:

Every assignment species declares its own participant meanings, predicate, applicability, and occurrence-identity rule. It adds another participant meaning only when its corresponding participant changes the predicate or occurrence identity. A KindSignature, system-role-taxonomy episteme, effective reference scheme, bridge, or model-use structure may interpret a receiving assertion or use when needed; it is not another participant merely because it helps interpret the claim.

assignmentInterval is not another SlotKind or a ValueKind admitted for a relation participant. It is a local content value in an assignment assertion or relation-occurrence description. The field states the currently known temporal extent of one occurrence, including an explicit open end when the occurrence is current. Under A.2.1, an occurrence of one direct species begins when its predicate starts obtaining for all fixed actual participants and continues while it obtains without interruption. Closing an open temporal description refines the same occurrence when continuity holds. A missing-evidence interval remains unknown; only demonstrated non-assignment ends that occurrence. A.2.5 defines assignment-state predicates and direct state relations; the patterns for capability, performed Work, and supporting claims retain their distinct definitions.

#Recover interface and port relations before declaring slots

Keep recognizable source words such as interface, port, endpoint, API, and signature in the recognition sentence; do not erase them and do not promote them into a generic U.Interface. Then use this sequence:

1. Repeat the source sentence so the practitioner can still recognize the situation.
2. Say in ordinary language what connects, crosses, or is transferred between which exact entities.
3. Recover the exact direct relation and its definition. If no current definition supplies the needed participant meanings, predicate, applicability, and identity rule, require A.6.RSIR or record one missing-relation result naming the proposed participants, required predicate, and receiving use.
4. Only after that relation closes, let its RelationSignature declare the SlotSpecs for participant meanings actually reused by the receiving typed claim.

Compact contrast. In “the evaporator outlet interfaces with the compressor inlet,” keep interfaces for recognition. If the intended claim is that refrigerant crosses from one named outlet to one named inlet, name that medium and those two endpoints and recover the exact transfer-relation definition before declaring any slots. If interface instead names a diagram boundary, API description, protocol, or publication form, use the definition for that object and use. A catalogue of possible participants closes neither branch; without a definition of the direct relation, stop before a RelationSignature.

#Name the operation by the object that changes

F.18 supplies the rules for durable name designation; participant-designation substitution and reference resolution do not. When a system selects a method at run time, use the definition of that method family or selector; A.6.5 supplies no method-selection operation. Do not rename that choice with the generic slot binding metaphor. If early or late timing matters, name which operation in this table is early or late.

#Archetypal Grounding

#System-role assignment: first minute, substitution, and repeated occurrence

First minute. Assume the case facts explicitly: Robot_7 is an admitted U.System; InspectorSystemRole is a local system-role kind; and InspectionShiftAssignment <: U.SystemRoleAssignment declares only two participant positions, holder System and assigned system-role kind. InspectionShiftAssignment-17 is the occurrence with those values that obtains without interruption from 09:00 to 17:00 on 13 July. A.2.1 defines the species predicate and continuity rule; it does not inspect this robot or warrant the assertion. The stated case facts satisfy that predicate, and the SystemRoleAssignmentAssertion records affirmative polarity. Any evidence and reliance posture remain separately established. The following field block represents that assertion episteme under C.29:

SystemRoleAssignmentAssertion:
  directClaimFamilyRef: A.2.1 InspectionShiftAssignment
  participantDesignations:
    HolderSystemSlot: Robot_7_Ref
    AssignedSystemRoleKindSlot: InspectorSystemRole
  assignmentInterval: [2026-07-13T09:00, 2026-07-13T17:00]

The two labels inside participantDesignations are convenient source-side labels in this compact representation. An explicit C.29 correspondence relates each label to the matching SlotKind in the InspectionShiftAssignmentRelationSignature; equal spelling does not identify field and SlotKind, and another source field keeps its own name. assignmentInterval is a different assertion field and corresponds to no relation-participant SlotSpec. Robot_7_Ref : U.EntityRef resolves to Robot_7 : U.System; InspectorSystemRole is carried by value under the declaration-local InspectorSystemRoleKindDomain. The assertion does not create the assignment, and neither the system-role kind, assertion, nor assignment performs inspection Work.

If inspection admission also needs InspectionReady, A.2.5 tests InspectionShiftAssignment-17 against that exact SystemRoleAssignmentStatePredicate. The resulting SystemRoleAssignmentStateRelation is separate from the assignment and has its own maximal continuous truth interval. The assignment may continue while that state relation ceases to obtain.

Substitution. Assume Robot_8_Ref : U.EntityRef resolves to another admitted Robot_8 : U.System. Replacing only the HolderSystemSlot designation with Robot_8_Ref passes the declared ValueKind check, but it does not create an assignment for Robot_8. Current case facts must separately satisfy the direct InspectionShiftAssignment predicate before an affirmative assertion is warranted. The proposed designation can therefore be type-correct while the direct claim remains negative or unresolved.

Repeated occurrence. If the same two participants enter another inspection shift after a demonstrated non-assignment period, the A.2.1 continuity rule ends the first occurrence and starts another. A copied field block or reused row key does not merge them. Conversely, closing an open assignmentInterval for one uninterrupted assignment refines the same occurrence; an evidence gap alone does not split it. Under that continuing assignment, true → false → true for one fixed A.2.5 predicate creates two assignment-state-relation occurrences without creating another assignment.

#Hypothetical physical-assembly boundary

Bearing_B isPartOf Pump_P may remain a readable source claim, but current A.14 supplies no generic or installed-part occurrence-identity rule based on removal, reinstallation, installation interval, or installation work. PartHolonSlot, WholeHolonSlot, and their RefKinds are therefore only a hypothetical declaration candidate until an accepted direct part-relation pattern states the participant meanings, predicate, applicability, and same-versus-new-occurrence rule. Do not claim current conformance or an individuated part-relation occurrence from this sketch.

Conditional on such a future declaration, changing a proposed part designation from Bearing_B_Ref to Bearing_C_Ref could be ValueKind-compatible while the direct relation remains false because current case facts do not satisfy its predicate. Until that parthood relation is defined, keep the bearings, pump, installation work, proposed part relation, assertion, designations, and representation separate. The counterexample demonstrates that typed substitution cannot create obtaining; it does not supply the missing parthood settlement.

#Episteme fields are not relation participants by table shape

An evaluation episteme has an EntityOfConcernRef, contains a ClaimGraph, and states an effective ReferenceScheme under C.2.1. A card or tuple view may contain visible fields such as entityOfConcernRef, claimGraph, and referenceScheme. Their co-occurrence in one record does not by itself establish another world-side relation, make the fields participants, or declare SlotSpecs for them.

When a direct relation among an episteme and other entities is current, its definition states the relation kind, participant meanings, obtaining condition, and occurrence identity, and its compatible RelationSignature contains the needed SlotSpecs. A.6.5 supplies the rules for typing participant designations in a receiving assertion. This prevents a convenient episteme form from becoming a pseudo-relation merely because it can be drawn as a tuple or table.

#Relation-dependent result wording

After machining, the machined component can remain the same physical entity in a changed state. It does not acquire a special result kind. Start with one question: did this same component continue through the change, or did a new entity begin?

1. Same component continued. Name that component, the characteristic that changed, and the actual machining transformation. Use the pattern that defines that characteristic and A.3.4 for the bounded change. The component's identity continues; calling it the work's “result” adds no kind, participant meaning, or relation.
2. A new entity began. Use this branch only when a current definition supplies an admitted identity-inception predicate and identity rule and the current Work and change facts satisfy them. If no such definition exists, return one missing identity-inception result naming the candidate entity, relevant work and change facts, required inception predicate, and receiving use. Do not infer a generic work-result relation.
3. The sentence names another relation. Rewrite it with its one concrete verb and participants before declaring slots. For example, Component_C was delivered to AssemblyCell_2 selects one candidate delivery claim about that item and receiver, not a result kind. Recover that direct relation's definition and any additional participant meanings it requires; if it does not close, return a missing-relation result. Handle an evaluation or acceptance sentence separately when that is the actual wording rather than listing possible pattern families.

Only the direct relation selected by one of those concrete sentences receives a compatible RelationSignature, and only when reusable typed use is current. Its assertion episteme records that relation; A.6.5 neither invents a broad result participant nor turns the domain choice into a catalogue.

#Formal reduced case

The expression 3 < 5 is notation carried by a mathematical assertion episteme. Its numeral occurrences, comparison sign, and left and right operand places are representation elements under C.29; they are not thereby FPF relation participants or SlotSpecs. When a reusable direct-relation declaration is current in an FPF use, the relation definition must identify what entities the numerals designate, the lesser-number and greater-number participant meanings, and the obtaining condition. Its RelationSignature may then contain local SlotSpecs such as LesserNumberSlot and GreaterNumberSlot. An explicit correspondence relates the operand places and their designations to those SlotSpecs. Operand order remains local to the mathematical representation, and the notation alone neither establishes the world-side relation nor individuates an occurrence. No receiving use in this case relies on occurrence identity, so the engineer stops at the typed assertion.

#Bias-Annotation

This pattern has a typed-declaration bias because it serves relation uses that depend on reusable participant typing. Progressive elaboration limits that bias: ordinary users stop at a readable relation sentence when no receiving use depends on SlotSpecs.

It also has a logic-facing bias because predicates and typed declarations make substitution and comparison reviewable. Constructive FPF adds what that logical form alone cannot supply: grounded participants, a direct obtaining condition, and an occurrence identity rule when identity is needed.

A declaration episteme describes reusable relation semantics; a separate representation episteme may represent an assertion or relation-occurrence description. Neither episteme is the world-side relation occurrence by form, and publication changes neither identity.

#Conformance Checklist

1. The direct relation kind and the definition of its predicate, applicability, participant meanings, and identity rule are named before SlotSpecs are declared.
2. Every participant meaning needed by reusable typed use has one complete <SlotKind, ValueKind, refMode> SlotSpec in the RelationSignature.
3. Each SlotKind is local to the one exact RelationSignature that contains its SlotSpec.
4. World-side relation prose names participant meanings and actual participants; declaration prose uses SlotSpec and ...Slot only for declaration-local SlotKinds; receiving-episteme prose names participant designations and uses ...Ref only for admitted RefKinds or reference values of those kinds. Actual participant ValueKind names carry neither suffix. For every semantic or representation field that receives relation semantics, verify the applicable §4.2 declaration or C.29 correspondence route and keep the field, SlotSpec, designation, and actual participant distinct. Position and place are not alternate FPF names for a declaration slot.
5. Each ValueKind is exact enough for the direct predicate and does not combine participant kinds for which the predicate has different semantics.
6. An assertion or description episteme that designates a participant by reference names the exact RefKind and resolves it to the declared ValueKind.
7. The actual relation participant, its reference, reference resolution, SlotSpec declaration, participant designation in the assertion, and relation occurrence remain distinct.
8. A C.3 kind is introduced only for a current typed-quantification, membership, substitution, or subkind use.
9. A verb-shaped predicate is not used as evidence of work, method, transformation, agency, or holonhood.
10. Only an admitted U.System is admitted for HolderSystemSlot. Each species under U.SystemRoleAssignment declares its AssignedSystemRoleKindSlot domain and any additional participant meaning whose value changes the predicate or occurrence identity.
11. U.Work and U.Method rely on their own constructive holon tests, while U.Transformation relies on A.3.4's actual-bounded-change identity; A.6.5 admits none of them by grammar.
12. The direct-relation definition supplies the obtaining predicate and occurrence-identity rule; current-case facts or constituting history supply the factual basis; a claim-bearing episteme records polarity; and evidence or reliance remains a separate judgement.
13. A declaration, assertion, description, representation, or publication episteme does not create the world-side relation by form.
14. Ordinary use can stop before signatures, explicit occurrence identity, or C.3 kind derivation when the receiving use depends on none of them; typed reuse, occurrence identity, and local-kind quantification are independent thresholds, and none is a prerequisite for another.
15. Relation-declaration slot discipline remains a rule set; its pattern name is not promoted to U.RelationSlotDiscipline.
16. A relation fact, an episteme claim, and a locally derived kind are handled by the patterns that define those respective objects without minting RelationDefinedQualification or E.24.RC.
17. A SlotSpec declares one direct-relation participant meaning inside one exact RelationSignature. Method-description, operation, plan, work, evaluation, representation, card, schema, and record fields retain the kinds and declaration rules supplied by their defining patterns; a field that receives relation semantics uses the applicable §4.2 route.
18. An A.15.3 planned-filling row may cite an exact SlotSpec, but the planned designation remains plan content and establishes neither an actual participant nor relation obtaining.
19. Interface, port, endpoint, API, and signature language remains available for recognition. The text states what connects, crosses, or is transferred between which entities and recovers the direct-relation definition before declaring SlotSpecs; an unresolved case requires A.6.RSIR or an exact missing-relation result.
20. When source wording calls an entity a result, first determine whether the same entity continued or a new entity began. A separately worded delivery, acceptance, or evaluation claim is opened one at a time with its concrete participants; no pattern catalogue or generic result kind substitutes for that decision.

#Common Failure Modes and Repairs

#Consequences

Benefits. Typed relation reuse becomes reviewable without treating an assertion or storage record as the world-side relation. Substitution checks can name the SlotKind and exact participant ValueKind. Reference changes can be distinguished from referent changes. Exact local system-role kinds remain separate from their holder systems and assignment occurrences, and relation predicates remain separate from Work and agency.

Costs. Load-bearing relation patterns need exact participant ValueKinds and designation modes. A proposed ValueKind may require a relation-kind split when the direct predicate has different semantics for different participant kinds. Existing compact byRef sketches may need adjacent expansion before another pattern can rely on them.

Limits. A.6.5 is limited to precise SlotSpec declarations and participant-designation typing. It neither defines the direct obtaining test nor decides a current case. The direct-relation definition supplies the predicate and identity rule, current facts or constituting history supply the case basis, and a claim-bearing episteme states the result. Separate patterns define evidence, reliance, model-use structure selection, and domain-interface semantics.

#Rationale

SlotKind, ValueKind, and RefKind answer three different engineering questions about one RelationSignature: which participant meaning does this declaration distinguish, what exact world-side kind must the corresponding actual participant have, and how does a receiving assertion or description episteme designate that participant. Keeping the answers separate is enough to support typed substitution and honest reference use without adding a universal relation record.

The direct-relation definition remains essential. A pair of typed participants does not say whether the relation obtains or whether repeated occurrences with the same participants are identical. Constructive ontology therefore combines logical slot discipline with grounding and domain identity rather than treating a schema as the world.

The predicate boundary prevents a second collapse. Natural language often verbalizes relations, work, methods, and transformations. FPF admits their kinds through direct ontological tests, not through grammar. This keeps only systems as actors and as actual participants corresponding to HolderSystemSlot, while preserving the accepted holonhood of work and methods and the separate actual-bounded-change identity of transformations.

#SoTA-Echoing

Reopen only the affected rule or worked case when a current source revises a premise used here: declaration locality or field typing; the separation of an assertion, reifier, or representation from the world-side relation; or the higher-order-typing stress on the three-way dispatch. A newer edition by itself does not reopen the pattern.

#Relations

• A.6.0 defines U.Signature and RelationSignature; A.6.5 supplies SlotSpec declaration discipline inside their vocabulary declarations.
• A.6.REL defines explicit relation-occurrence individuation and the progressive threshold for stable reference.
• A.6.P and A.6.RSIR recover the direct relation and its participants before slot typing begins.
• Use A.2.1 for each direct system-role-assignment species' predicate, identity, and participant meanings, and A.6.5 for the exact SlotSpec reading of that species' declaration.
• C.2.1 defines episteme identity, assertion and description content, and their semantic fields; A.6.5 §4.2 gives the declaration and C.29 correspondence routes by which such fields receive relation semantics while field, SlotSpec, designation, and actual participant remain distinct.
• C.3 and C.3.1 define local participant kinds only when typed quantification or kind order is current.
• A.15.3 may cite an exact RelationSignature SlotSpec for a planned participant designation; A.15.2/A.15.3 define the planned claim, the direct-relation definition supplies the participant meaning and later actual-participation predicate, and A.6.5 supplies only SlotSpec declaration discipline. Operation arguments and results remain A.6.1 declarations.
• A.15.1 and A.3.1 define the constructive holonhood and identity of Work and Methods; A.3.4 defines the actual-bounded-change identity of transformations; E.18 defines selected transformation-flow structures over those independently defined transformations and adjacent loci.
• A.1, A.2, A.2.1, and A.15 keep acting systems, exact local system-role kinds, system-role assignments, Methods, and performed Work distinct.
• Use A.2.4 for compact episteme evidence-use and status-use relation SlotSpecs, A.10 for the full evidence-provenance path, and F.10 for durable status semantics. A.6.5 does not duplicate those relations or make an episteme the holder system, assigned system-role kind, assignment occurrence, or assignment-state relation.
• When one is current, the exact named C.30 architecture-relation subpattern defines the architecture relation. A.6.M defines module-interface relations; after A.6.RSIR recovery, a non-module interface use follows its direct-relation definition. A.6.5 does not duplicate either family.
• C.29 defines how tuple components, graph nodes and edges, database fields and rows, and mathematical operands represent a relation, assertion, signature, or occurrence description.
• E.10 supplies wording-use recovery, E.24.UK supplies the U-kind admission test, and F.18 supplies designation guidance after the object is known.

#A.6.5:End

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