#U.RelationSlotDiscipline - SlotKind / ValueKind / RefKind discipline for n‑ary relations (with slot‑operation lexicon)

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 slot discipline.

Use this when. Use this pattern when a relation, operator, record, episteme slot relation, signature vocabulary item, interface specification, method description, service-access description, role assignment, evidence-use relation, status-use relation, or transformation-flow structure needs named positions and typed fillers rather than a loose parameter list.

Primary EntityOfConcern. The EntityOfConcern is U.RelationSlotDiscipline: the FPF discipline for declaring the positions of a relation-bearing structure, the kinds of values admitted at those positions, and the reference or by-value mode used when a filled instance stores content.

First useful move. For the current relation-bearing value, name the governing pattern and write each relevant position as a SlotSpec = <SlotKind, ValueKind, refMode>. Then say whether the filled slot instance stores a value by value or stores a reference of a RefKind.

What goes wrong if missed. Teams treat "role", "argument", "field", "port", "parameter", "endpoint", "holder", "target", "source", "interface", or "ref" as if the word already said whether it is a position, a filler kind, a filled reference, a described object, or a neighboring relation. This creates duplicate ontology: the same project situation becomes a role in one pattern, an interface in another, a slot in a third, and an evidence relation in a fourth.

What this buys. A relation-bearing pattern can say exactly which slots it has, what may fill each slot, how filled instances point to or embed those fillers, and which neighboring pattern governs any role, capability, method, work, evidence, status, publication, or interface claim that appears near the relation.

Not this pattern when. Do not use A.6.5 as a generic relation ontology, as a second U.Signature, as an interface root kind, as a role ontology, or as a universal wording-repair pattern. Use the direct governing pattern when the current question is relation identity (A.6.P or a relation-specific pattern), signature declaration (A.6.0), role value (A.2), role assignment (A.2.1), evidence use (A.10, B.3, G.6), status use (F.10), publication or view use (E.17*), module interface (A.6.M and architecture patterns), functional port or functional structure (A.6.F, E.18, architecture patterns), or wording-use triage (E.10, E.10.ARCH, A.6.RSIR).

FPF relies on n-ary relations and operators throughout the corpus: episteme slot relations, role assignments, method and method-description signatures, evidence-use relations, status-use relations, service-access descriptions, interface specifications, architecture structures, view relations, transformation-flow structures, and formal-substrate declarations.

#Keywords

• slot
• argument position
• value
• reference
• signature
• substitution
• pass-by-value
• pass-by-reference.

#Relations

#Content

#Problem frame

FPF relies on n-ary relations and operators throughout the corpus: episteme slot relations, role assignments, method and method-description signatures, evidence-use relations, status-use relations, service-access descriptions, interface specifications, architecture structures, view relations, transformation-flow structures, and formal-substrate declarations.

The same local phrase can hide three different things:

1. a named position in one relation-bearing structure;
2. the kind of value admitted at that position;
3. the reference or embedded value placed in one filled relation instance.

For example, EntityOfConcernSlot, U.Entity, and entityOfConcernRef are not three spellings for one thing. The first names a slot position. The second names a filler kind. The third is a filled reference field in an instance. When these layers are blurred, substitutions, retargetings, interface claims, role assignments, evidence-use relations, and episteme morphisms become hard to review.

The governing distinction is important: A.6.5 supplies relation-slot discipline. It does not decide what a relation is in general, and it does not replace U.Signature. Relation identity remains with the pattern that governs the relation. Signature identity remains with A.6.0. A.6.5 gives both of them a disciplined way to talk about positions and fillers.

#Problem

Without a shared slot discipline, FPF texts fall into recurring category errors.

1. Slot, value, and reference are treated as one object. A field such as entityOfConcernRef is read as the slot, the described object, and the stored reference at the same time.
2. Kernel kinds are used as slot names. Writers say "the U.Holon of this relation" when they mean a local slot whose filler has ValueKind U.Holon.
3. Role words become argument-position words. "The role of the subject" or "provider role in the relation" may mean an actual U.Role, a local SlotKind, an evidence-use position, a service-access relation, or ordinary prose.
4. Reference suffixes drift. A *Ref token is sometimes used for a value kind, sometimes for a field, and sometimes for a slot. Downstream readers cannot tell what is being retargeted.
5. Substitution rules cannot be localized. If a text cannot say which SlotKind stays fixed and which ValueKind remains compatible, "replace X with Y" becomes a hand-waved compatibility claim.
6. Interface and port wording overgeneralizes. "Interface" may mean module interface, signature, port, protocol, API description, service-access package, or boundary claim bundle. A.6.5 helps declare slots inside those values, but it does not create a generic U.Interface.
7. Evidence and status relations are mistaken for roles. An episteme used as evidence, a standard used as a requirement, or a publication used as a status source is treated as a U.RoleAssignment case even though the current claim is evidence use, source use, publication use, assurance use, or status use.

The practical failure is simple: local convenience produces global incoherence.

#Forces

#Solution

U.RelationSlotDiscipline says that a relation-bearing structure with named positions uses SlotSpec declarations. A SlotSpec separates the local position, the admitted filler kind, and the instance reference mode.

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

This is a discipline over relation-bearing structures. It is not the identity of the relation itself. It is not a new kind for every possible field name. It is not a publication form.

#SlotKind, ValueKind, and RefKind

SlotKind names one position in one relation-bearing structure. It is structural and local to a governing relation, operator, record, signature vocabulary item, episteme slot relation, role assignment, interface specification, or other signatured bundle. Examples include EntityOfConcernSlot, GroundingHolonSlot, ClaimGraphSlot, ViewpointSlot, EvidenceTargetClaimSlot, RoleValueSlot, AssignmentWindowSlot, ServiceEndpointSlot, and DatasetSlot.

ValueKind names what kind of value may fill that position. Examples include U.Entity, U.Holon, U.System, U.Role, U.Method, U.MethodDescription, U.Episteme, U.ClaimGraph, U.Viewpoint, U.Characteristic, and U.ReferenceScheme. A ValueKind is governed by its own pattern. It does not become a SlotKind because it fills a slot.

RefKind names how a filled relation instance points to a value when the value is not embedded by value. Examples include U.EntityRef, U.HolonRef, U.SystemRef, U.RoleRef, U.MethodRef, U.EpistemeRef, U.ViewpointRef, and U.CharacteristicRef. A RefKind is about references, not about the value itself.

Slot instance is the particular position in one filled relation instance. Slot content or slot filler is what the filled instance stores at that position. The slot content is either an embedded value of the ValueKind or a reference of the RefKind. If it is a reference, resolving it gives a referent value or editioned referent.

#Well-formed SlotSpec discipline

For each named position in a relation-bearing structure:

Well-formedness constraint A6.5-S1 (SlotSpec completeness):
  each SlotSpec has exactly one SlotKind, exactly one ValueKind, and exactly one refMode.

Well-formedness constraint A6.5-S2 (SlotKind locality):
  SlotKind is interpreted relative to the governing relation-bearing structure.

Well-formedness constraint A6.5-S3 (ValueKind preservation):
  a substitution at a slot preserves the SlotKind and uses a filler whose kind is the declared ValueKind or an admitted subkind.

Well-formedness constraint A6.5-S4 (RefKind honesty):
  when refMode is a RefKind, the slot content is a reference value, not the referent itself.

A U.Signature uses this discipline when its vocabulary declares an n-ary relation or operator. The SlotSpecs live inside the relevant vocabulary item. They do not add a fifth row to the [A.6.0](/generated/patterns/A.6.0) Signature Block and do not move operational guards from [A.6.1](/generated/patterns/A.6.1) or method and work patterns into the signature.

#Naming discipline for Slot and Ref

Use *Slot only for SlotKinds. Do not use *Slot for ValueKinds, RefKinds, concrete fields, or publication labels.

Use *Ref only for RefKinds or fields whose type is a RefKind. Do not use *Ref for SlotKinds or for the value itself.

ValueKind names do not carry *Slot or *Ref. If a current source name violates this rule, recover the intended kind before renaming. The repair may split one old token into a SlotKind, a ValueKind, and a RefKind or field.

Do not use Role as the head noun for a SlotKind. U.Role is a role value governed by A.2. A relation position that admits a U.Role filler can be named RoleValueSlot; a position filled by a system or acting holon under a role assignment can be named RoleHolderSlot or a context-specific refinement. The head remains Slot, and the U.Role value remains a value.

#Role assignment under slot discipline

U.RoleAssignment is a typed assignment relation value for work-facing roles. It can be expressed with SlotSpecs without reducing roles to slots.

Core SlotSpecs for a work-facing role assignment include:

Direct work-role patterns may add work-role qualifier slots. Evidence-use, source-use, publication-use, standard-use, requirement-use, assurance-use, and status-use relations do not become RoleAssignment slots merely because their prose says "role of the evidence" or "role of the standard". Those uses are governed by their direct patterns.

RoleEnactment is not introduced here as a root ontic. When a named fact is needed, use RoleEnactmentFact for the derived fact that a U.Work occurrence was performed under a specific U.RoleAssignment, or write the direct relation such as Work.performedBy = RoleAssignment.

#Evidence-use and status-use relations are not work roles

An episteme may be used as evidence for several claims. This creates evidence-use relation instances, not several roles held by the episteme.

Typical evidence-use SlotKinds include:

Status-use relations likewise name the status bearer, status value, status scope, status window, and use relation under the direct status or assurance pattern. They do not create status roles for epistemes.

#Interface, port, and signature wording

A.6.5 is often needed when a source says "interface", "port", "endpoint", "API", "protocol", or "connector". These words do not select one FPF kind by themselves.

Recover the current EntityOfConcern first:

After the governing EntityOfConcern is selected, use A.6.5 only to state the SlotSpecs inside that value. Do not mint a generic U.Interface or erase interface language when it is the ordinary engineering recognition cue.

#Slot operation lexicon

Use slot-operation words by the link they affect.

Avoid person metaphors such as occupant for slot content. Use slot content or slot filler. If a local Plain register uses a metaphor, it cannot carry FPF-governed role, evidence, or status meaning.

#Binding time and currentness of slot operations

"Early binding" and "late binding" are admissible only after the affected link is named.

Use:

• early or late name binding for identifier-to-slot or identifier-to-value links;
• early or late slot filling for when a slot instance receives content;
• eager or lazy resolution for when a reference is resolved to a referent;
• dynamic dispatch only when a method or operation selection relation actually uses runtime context to select the invoked operation.

If the text does not say which link is affected, keep the phrase ordinary or repair it before use.

#Archetypal Grounding

System case: refrigerator functional architecture. A refrigerator functional diagram may describe a transformation-flow structure: compressor, condenser, expansion valve, evaporator, sensors, controller, and refrigerant flow. An interface or port in that description is not automatically a generic interface kind. If the current EntityOfConcern is the functional port between evaporator and compressor, recover the functional or transformation-flow relation first, then declare SlotSpecs such as UpstreamTransformationSlot, DownstreamTransformationSlot, TransferredMediumSlot, BoundaryConditionSlot, and ObservedCharacteristicSlot. The refrigerant, components, controller, and temperature characteristic remain fillers governed by their own patterns.

Episteme case: model evaluation result. A ModelEvaluationResult episteme can use EntityOfConcernSlot with ValueKind U.Method, DatasetSlot with ValueKind U.Entity, TargetCharacteristicSlot with ValueKind U.Characteristic, GroundingHolonSlot with ValueKind U.Holon, and ClaimGraphSlot with ValueKind U.ClaimGraph by value. Retargeting DatasetSlot from Dataset_A to Dataset_B changes a reference filler. Editing the threshold inside ClaimGraphSlot changes embedded claim content. Those are different operations.

Role case: inspection work. A maintenance context assigns InspectorRole to Robot_7 for a window. The role assignment relation can fill RoleHolderSlot = Robot_7, RoleValueSlot = InspectorRole, BoundedContextSlot = MaintenanceLine_A, and AssignmentWindowSlot = from 2026-06-15T09:00 to 2026-06-15T11:00. The robot's capability remains U.Capability, the inspection method remains U.Method or U.MethodDescription, the planned inspection remains U.WorkPlan, and the performed inspection remains U.Work.

Evidence case: one report for two claims. One report episteme can be used as evidence for Claim A and Claim B. The episteme is not assigned two evidence roles. FPF creates two evidence-use relations with different EvidenceTargetClaimSlot fillers and any distinct scope, polarity, relevance-window, or weight-model fillers.

#Bias-Annotation

This pattern has a typed-structure bias: it prefers explicit positions and filler kinds over conversational shorthand. That bias is intentional because relation-bearing FPF prose must remain reusable across epistemes, signatures, roles, interfaces, methods, evidence, status, and architecture.

This pattern also has an episteme-example bias because C.2.1 is the mature precedent for slot relation discipline. The Solution generalizes beyond epistemes and explicitly includes work-facing role assignments, evidence-use relations, status-use relations, interfaces, ports, and transformation-flow structures.

The anti-bias guard is that A.6.5 never makes description or publication the center unless the current EntityOfConcern is itself a description or publication relation. It starts from the relation-bearing EntityOfConcern and only then describes how its slots may be specified or published.

#Conformance Checklist

1. SlotSpec completeness. Every FPF-governed n-ary relation, operator, record, or signature vocabulary item introduced by the pattern names SlotKind, ValueKind, and refMode for each governed position.
2. SlotKind locality. SlotKind is interpreted relative to the governing relation-bearing structure; the same label does not float as a universal kind without a governing pattern.
3. ValueKind separation. ValueKinds remain governed by their own patterns and do not inherit *Slot or *Ref suffixes.
4. RefKind honesty. A *Ref name denotes a reference kind or a field typed by a reference kind, not the referent itself.
5. Role boundary. Role-valued slots may admit U.Role fillers, but SlotKinds are not roles and role labels do not create capability, method, status, evidence, or work.
6. RoleAssignment boundary. A work-facing U.RoleAssignment uses core SlotSpecs for holder, role value, bounded context, and assignment window; evidence-use and status-use relations are not folded into RoleAssignment.
7. Evidence and status direct-pattern use. Epistemes used as evidence, sources, standards, requirements, definitions, explanations, publications, status bearers, or assurance inputs are governed through direct evidence-use, source-use, publication-use, status-use, or assurance-use patterns, not through U.RoleAssignment for epistemes.
8. Interface recovery. Interface, API, port, protocol, connector, or endpoint wording is first recovered to its governing EntityOfConcern; A.6.5 supplies only the SlotSpecs inside the recovered value.
9. Operation verb discipline. Slot changes use bind, fill, initialize, assign, retarget, substitute, resolve, revise, re-edition, or pass according to the link being changed.
10. No generic relation replacement. A pattern does not cite A.6.5 as the governing source for relation identity, evidence authority, assurance, gate passage, method admission, work execution, or publication truth.

#Common Anti-Patterns and How to Avoid Them

#Consequences

A.6.5 adds a small amount of explicit metadata to relation-bearing structures. The payoff is that substitutions, retargetings, evidence-use distinctions, role-assignment boundaries, interface claims, and episteme morphisms become reviewable.

It also prevents ontology overgrowth. A value filling a slot does not become a new kind because it is used in that slot. Conversely, a slot label does not become the value. This is the same discipline that keeps U.Episteme compact in C.2.1 and keeps U.Role compact in the role ontologicalNeighborhood.

The cost is naming care. Authors must recover the current governing pattern before accepting a slot name. That is cheaper than maintaining several local ontologies for the same project situation. Reopen the governing pattern, not A.6.5, when a current case depends on relation identity, evidence authority, status meaning, role ontology, method admission, work execution, publication use, architecture semantics, or another value that SlotSpec discipline only references.

#Rationale

FPF needs relations that are strong enough for engineering use but light enough for cross-domain pattern work. The SlotKind, ValueKind, and RefKind separation gives FPF a compact relation-position discipline without turning every relation into a new formal calculus.

The key design choice is modularity. A.6.5 is central because many patterns need SlotSpecs. It remains narrow because relation identity, evidence authority, status meaning, role ontology, method admission, work execution, publication use, and architecture semantics belong to their own patterns.

The role decision is especially important. If every slot position is called a role, U.Role loses its work-facing meaning. If every episteme used as evidence gets an evidence role, FPF grows a second role ontology for epistemes. A.6.5 keeps both errors visible: a role may fill a slot, but slot position labels do not create alternate ontology.

#SoTA-Echoing

#Relations

A.6.0 governs U.Signature; A.6.5 supplies SlotSpec discipline for n-ary vocabulary items inside signatures.

A.6.P governs qualified relation precision restoration; A.6.5 supplies the slot discipline consumed by relation-restoration patterns.

E.24 governs ontic introduction. A.6.5 is one reusable discipline used by ontic introductions, but it does not create a new ontic every time a slot label appears.

C.2.1 is the mature precedent for slot relation discipline in epistemes. A.6.5 keeps its EntityOfConcernSlot, GroundingHolonSlot, ClaimGraphSlot, ViewpointSlot, ViewSlot, and ReferenceSchemeSlot usable across morphisms and publication patterns.

A.2, A.2.1, A.2.5, A.2.7, and A.15 govern role values, role assignments, role-state checks, role relation structure, and role-method-work alignment. A.6.5 only expresses the SlotSpecs of relations that include role values or role assignments.

A.10, B.3, G.6, C.28, and F.10 govern evidence-use, assurance, causal-use, provenance, and status-use relations. Old evidence-role and status-role source wording is governed through typed evidence-use, assurance, causal-use, provenance, or status-use relations, not through work-role assignment.

A.6.M, A.6.F, E.18, C.30.TFS-REL, and architecture patterns govern interface, port, functional, and transformation-flow cases. A.6.5 applies only after the governing EntityOfConcern has been recovered.

E.10, E.10.ARCH, F.18, and A.6.RSIR govern wording-use triage and naming. They require each relation, signature, interface, role, slot, capability, method, function, concern, or interest word to be resolved under its direct governing pattern, using A.6.5 when relation-position discipline is the current issue.

#A.6.5:End

Last Updated: 2026-06-17 — this section last modified in upstream FPF commit 205de763 (github.com/ailev/FPF)