#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, name its direct governing pattern, and identify the relation kind and relation-participant meanings. 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>. The angle brackets and ordered entries belong to that notation; they are not parts or participants of the world-side relation. refMode states how an assertion or relation-occurrence description episteme carrying a relation-participant designation denotes the actual participant; it does not turn the reference or SlotSpec into that participant. If the direct relation or its relation obtaining predicate is still unclear, stop and return to A.6.P or A.6.RSIR; declaration notation cannot recover a missing ontology.

First-minute result. For Robot_7 holds InspectorRole, use the admitted A.2.1 declaration. When reusable participant typing is current, its four SlotSpecs are HolderSystemSlot : U.System / U.EntityRef, RoleValueSlot : U.Role / ByValue, RoleTaxonomyEpistemeSlot : U.Episteme / U.EpistemeRef, and EffectiveReferenceSchemeSlot : U.ReferenceScheme / ByValue. A current assertion designates those participants and states its AssignmentInterval separately. Stop there unless later work must substitute a participant or distinguish this assignment episode from another.

What goes wrong if missed. In Robot_7 holds InspectorRole, the holder system, the role value, the declaration-local SlotKind, and a 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 role value, an assignment occurrence, or an assertion about that 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 return to the pattern that governs 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, select the pattern governing the direct relation 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 owner.

The following governed 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 governed reference 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 direct pattern governs the repair.

#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, leave relation obtaining and occurrence identity with the direct governing pattern, and 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. The governed object in this pattern is 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. No method-description, plan, work, evaluation, card, schema, or record field becomes a SlotSpec. 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.

#Keep pattern scope exact

None of these objects gets its identity or truth condition from A.6.5. A.6.5 governs 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 RoleTaxonomyEpistemeSlot are different SlotKinds inside the U.RoleAssignment declaration even when receiving assertions carry both designations by reference. 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 an accepted kind declaration under its governing pattern. That 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 receiving assertion or relation-occurrence description episteme carries a relation-participant designation by reference. A system applying the governed 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 direct patterns admit them. 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 governed 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 represents seven rules for reviewing a declaration episteme. The labels and indentation are presentation elements, not SlotSpecs, relation participants, or work occurrences.

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 DirectPredicateGovernance:
  the direct governing pattern contains statements of the relation 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 direct owner defines that predicate and identity rule; the current case must supply the relevant facts or constituting history. A system evaluates those facts by the direct method, 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 holds a role, 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 direct patterns for that settlement:

• U.Work and U.Method are admitted holon kinds only because their governing patterns supply the required constructive assembly, composition, identity, and meta-holon-transition conditions. 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.
• U.Role is a work-facing role value, not a holon. An admitted U.System holds it through U.RoleAssignment.
• 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 and holds a role. Work is performed, a method is applied in work, and a transformation occurs or is carried out. The relation, method, work, transformation, role, signature, and structure do not become actors because prose gives them an active verb.

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 select the direct pattern. 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 its exact direct governor. 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.

#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 representation edges under [C.29](/generated/patterns/C.29), not transitions in a drafting process, world-side relations, or work occurrences. They show only which additional object the named use consumes. The diagram does not make a RelationSignature prerequisite for explicit occurrence individuation, and it neither makes the direct relation obtain nor supplies occurrence identity. The direct owner defines the obtaining predicate; current case facts or constituting history must satisfy it. The direct occurrence-identity rule governs which occurrence is being distinguished only after that factual condition is met.

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 governed C.3 local kind and its membership rule supply the reusable classification.

#Read the Role-Assignment SlotSpecs

A.2.1 directly governs U.RoleAssignment. Its direct pattern states the predicate, obtaining condition, and occurrence-identity rule. A compatible RelationSignature declares the following SlotSpecs under A.6.5:

The four required SlotSpecs declare all participant meanings of generic U.RoleAssignment. A selected model-use structure that changes one receiving interpretation is designated in that receiving assertion or use, not in this generic RelationSignature.

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 name assignmentInterval states the currently known temporal extent of one occurrence, including an explicit open end when the occurrence is current. Under A.2.1, one generic occurrence begins when the assignment predicate starts obtaining for fixed holder, role value, taxonomy episteme, and reference scheme, 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. Role state, capability, performed work, and every supporting claim remain under their direct governing patterns.

#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 owner. If no current owner supplies the needed participant meanings, predicate, applicability, and identity rule, return to A.6.RSIR or record one missing-governor 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 owner before declaring any slots. If interface instead names a diagram boundary, API description, protocol, or publication form, keep that object under its own governor. A catalogue of possible participants closes neither branch; without a direct relation owner, stop before a RelationSignature.

#Name the operation by the object that changes

Durable name designation is governed by F.18, not by participant-designation substitution or reference resolution. When a system selects a method at run time, use the pattern governing 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

#Role assignment: first minute, substitution, and repeated occurrence

First minute. Assume the current case facts explicitly: Robot_7 is an admitted U.System; InspectorRole, MaintenanceRoles_2026, and MaintenanceScheme_A are the other three A.2.1 participants; and the assignment state holds without interruption from 09:00 to 17:00 on 13 July. A.2.1 defines the predicate and continuity rule; it does not inspect this robot or warrant the assertion. The stated case facts satisfy the predicate, and the RoleAssignmentAssertion records affirmative polarity. Any evidence and reliance posture remain separately governed. The following field block represents that assertion episteme under C.29:

RoleAssignmentAssertion:
  participantDesignations:
    HolderSystemSlot: Robot_7_Ref
    RoleValueSlot: InspectorRole
    RoleTaxonomyEpistemeSlot: MaintenanceRoles_2026_Ref
    EffectiveReferenceSchemeSlot: MaintenanceScheme_A
  assignmentInterval: [2026-07-13T09:00, 2026-07-13T17:00]

The four 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 RoleAssignmentRelationSignature; 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; MaintenanceRoles_2026_Ref : U.EpistemeRef resolves to the role-taxonomy episteme. InspectorRole : U.Role and MaintenanceScheme_A : U.ReferenceScheme are carried by value. The assertion does not create the assignment, and neither role, assertion, nor assignment performs inspection work.

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 make Robot_8 hold the role. Current assignment facts must separately satisfy the A.2.1 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 four 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.

#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 owner 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 owner exists, 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, the governing pattern contains the relation kind, participant meanings, obtaining condition, and occurrence identity, and its compatible RelationSignature contains the needed SlotSpecs. A.6.5 governs how a receiving assertion types its participant designations. 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 existing owner of 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 an admitted identity-inception owner defines the predicate and identity rule and the current work and change facts satisfy them. If no such owner exists, return one missing-governor 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 owner and any additional participant meanings it requires; if it does not close, return its missing-governor result. Handle an evaluation or acceptance sentence separately when that is the actual wording rather than listing possible owners.

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 direct pattern content 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 governing pattern 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 governed reference values. Actual participant ValueKind names carry neither suffix. 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. 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 the participant admitted for HolderSystemSlot and holds U.Role through U.RoleAssignment.
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 pattern defines 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 separately governed.
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 dispatched to their direct patterns without minting RelationDefinedQualification or E.24.RC.
17. SlotSpecs occur only inside exact RelationSignature declarations for direct-relation participant meanings; method-description, operation, plan, work, evaluation, representation, card, schema, and record fields do not become SlotSpecs by shape or label. 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.
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 owner before declaring SlotSpecs; an unresolved case returns to A.6.RSIR or an exact missing-governor result.
20. When source wording calls an entity a result, the text first decides 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 owner 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. Role values remain separate from role holders, 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 owner defines the predicate and identity rule, current facts or constituting history supply the case basis, and a claim-bearing episteme states the result. Evidence, reliance, model-use structure selection, and domain-interface semantics remain with their direct governing patterns.

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

#Relations

• A.6.0 governs U.Signature and RelationSignature; A.6.5 governs SlotSpecs inside their vocabulary declarations.
• A.6.REL governs 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.
• A.2.1 governs role-assignment predicate, identity, and participant meanings; A.6.5 governs their exact SlotSpec reading.
• C.2.1 governs episteme identity, assertion and description content, and their semantic fields. 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.
• C.3 and C.3.1 govern 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 govern the planned claim, the direct relation pattern owns 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 govern the constructive holonhood and identity of work and methods; A.3.4 governs the actual-bounded-change identity of transformations; E.18 governs selected transformation-flow structures over those independently governed transformations and adjacent loci.
• A.1, A.2, and A.15 keep acting systems, role values, role assignments, methods, and performed work distinct.
• A.2.4 governs compact episteme evidence-use and status-use relation SlotSpecs; A.10 governs the full evidence-provenance path, and F.10 governs durable status semantics. A.6.5 does not duplicate those relations or make the episteme a role holder.
• C.30 with the exact named architecture-relation subpattern when one is current governs architecture relation semantics. A.6.M governs module-interface relation semantics; a non-module interface use remains with the direct pattern named after A.6.RSIR recovery. A.6.5 does not duplicate either family.
• C.29 governs tuple components, graph nodes and edges, database fields and rows, and mathematical operands used to represent a relation, assertion, signature, or occurrence description.
• E.10, E.24.UK, and F.18 govern wording recovery, U-kind admission, and designation after the object is known.

#A.6.5:End

Last Updated: 2026-08-04 — upstream FPF commit 7ba40a95 (github.com/ailev/FPF)