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

Pattern A.6.5 · Stable Part A - Kernel Architecture Cluster

Plain‑name. Relation slot discipline.

Status. Normative (Core). Placement. Part A, cluster A.IV “Signature Stack & Boundary Discipline”; directly under A.6.0 U.Signature and alongside A.6.1–A.6.4. Depends on. – A.1 U.Holon (holonic carrier model). – A.6.0 U.Signature (universal morphism/relationship signatures). – A.7 (Strict Distinction; I/D/S vs Surface). – E.8 (pattern authoring order & SoTA discipline). – E.10 (LEX‑BUNDLE: Tech/Plain registers, naming guards).

Coordinates with. – C.2.1 U.EpistemeSlotGraph (episteme slots: DescribedEntity, GroundingHolon, ClaimGraph, Viewpoint, View, ReferenceScheme). – C.3.* Kind‑CAL (Kinds, KindSignature, KindBridge). – F.18 (name governance; twin‑register discipline).

FPF relies heavily on n‑ary relations and morphisms:

#Keywords

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

#Relations

#Content

#Problem frame

FPF relies heavily on n‑ary relations and morphisms:

• episteme component layouts (U.EpistemeKind in C.2.1),
• role enactment and assignment,
• method/service signatures,
• guards and bridges in Part B/C,
• publication and view operators in Part E, and any other U.Signature whose Vocabulary row declares n‑ary relations or operators across Part A/B/C/E.

In practice, existing episteme and drafts frequently conflate:

1. the place/position in a signatured structure (relation/operator/record/port bundle; e.g. “the 2nd argument, named Subject”),
2. the kind of value that may fill that position (U.Entity, U.Holon, …), and
3. the reference/identifier we actually store there (…Id, …Ref).

This produces subtle bugs (elaborated in A.6.5:2):

• misuse of “Subject/Object” as SlotKind‑like names for very different ValueKinds (explicitly banned for episteme Tech names by E.10),
• the …Ref suffix attached to both conceptual values and reference fields, erasing ValueKind vs RefKind,
• mixed reasoning about “role”, “slot”, and “filler” as if they were the same layer,
• fragile substitution questions (“can I plug this module here?”) that depend on informal judgement rather than SlotSpec laws.

A second, subtler conflation appears in prose: authors mix binding / initialization / assignment / substitution / retargeting / mutation / passing as if they were synonyms for “put something in a slot”. This blurs the intended discipline precisely in the places where FPF must be crisp (signatures, morphisms, bridges, and viewing operators).

U.RelationSlotDiscipline pins a single, reusable discipline over U.Signature so that every position in an n‑ary signature is described with:

• a SlotKind — where in the signature,
• a ValueKind — what sort of thing may fill that place, and
• a RefKind — how we point at it in episteme (identifier / handle), if at all,

and it standardises the lexicon for operations over slots so that extension texts can describe “early vs late binding”, “retargeting”, and “by‑value edits” without collapsing layers.

This pattern makes slot discipline explicit and shareable across epistemes, roles, methods, services, bridges, guards, and all other U.Signatured calculi: any “parameter list”, “port list”, “field set”, or “coordinate tuple” for an n‑ary signature in FPF is a set of SlotSpecs governed by this discipline.

#Problem (symptoms in FPF)

Typical failure modes the pattern is designed to eliminate:

1. Slot vs value vs ref confusion. Episteme fields such as DescribedEntityRef are sometimes treated as:

   • the slot (“the described entity position”),
   • the value kind (“the described entity type”), and
   • a reference field (“this is the pointer we store”).

   Reasoning about substitution (“can I swap one described entity for another?”) then mixes three levels at once.

2. Kernel types misused as slot names. Kernel concepts like U.Entity or U.Holon are used directly as slot names (“the U.Entity of this episteme”), hiding the difference between:

   • the abstract Kind (U.Entity as intensional universe), and
   • the place where one such entity is used in a particular relation.

3. “Role” overloaded as slot. In relation signatures and structural calculi, “role” has crept in as a synonym for “argument position”: “the role of the subject”, “the role of the provider”. This clashes with U.Role in RoleEnactment and makes it hard to distinguish:

   • holonic role (mask worn by a system), from
   • slot (position in a relation).

4. Ref‑suffix drift. In the absence of a discipline, the suffix …Ref is attached to:

   • entity kinds (U.EntityRef interpreted as “the entity itself”),
   • episteme fields (describedEntityRef),
   • sometimes even to slots (“DescribedEntityRefSlot”).

   That makes it impossible to read signatures and know whether we talk about:

   • a conceptual value (by‑value), or
   • a reference/identifier (by‑reference via a handle).

5. Substitution rules not localisable. When the slot/value/ref layers are not separated:

   • we cannot state “you may substitute any instance of ValueKind V in Slot S”, nor
   • “this Bridge only changes RefKind, not ValueKind”.

   This blocks clean use of A.6.0 U.Signature as a shared calculus for method/role/episteme signatures.

6. Episteme‑specific slots not standardised. For epistemes, the positions “what is this about?”, “in which holon is it grounded?”, “what ClaimGraph is inside?” re‑appear across patterns. Without a shared slot discipline, each pattern names these ad‑hoc, breaking the ability to state universal laws over episteme morphisms (A.6.2–A.6.4).

7. Operation‑lexicon drift (slot filling spoken as one verb). Extension prose introduces ad‑hoc words for “put something in a slot” and then imports unintended semantics. The most common mistakes are:

   • using a single word (e.g. “fill”, “set”, “occupy”, “attach”) to cover initialization, assignment, retargeting, and by‑value editing;
   • using person/role metaphors for slot content (“occupant”) that re‑introduce the “role ≈ slot” confusion;
   • describing “early vs late binding” without stating which link is early/late (name→slot binding vs slot→content filling vs ref→referent resolution).

The result: local convenience, global incoherence — exactly what A.6.0 and E.10 are supposed to prevent.

#Forces

• F1 - Simplicity vs expressiveness. Engineers need a small number of concepts they can hold in mind while reading a signature; yet we must express:

  • where a parameter sits,
  • which kinds it can take,
  • whether it’s by value/by reference,
  • how substitution behaves,
  • and (in prose) what kind of slot‑operation is being described.

• F2 - Cross‑disciplinary reuse. Slot discipline must work for:

  • logical relations (KD‑CAL, LOG‑CAL),
  • episteme structures (C.2.1),
  • systems/roles/methods (A/B),
  • services and APIs (including method/service interfaces and ports),
  • cells in tables and databases,
  • guards, bridges, and flows in E.TGA,
  • and publication operations (E.17).

  A scheme that is too domain‑specific (e.g. “database attributes only”) won’t scale; the same discipline must underlie all U.Signatured argument/port lists.

• F3 - Alignment with existing tooling. Tooling stacks already operate with:

  • typed parameters and records,
  • identifiers vs values vs references,
  • and (in modern typed settings) explicit distinctions between binding, store update, and mutation.

  FPF must line up with this practice enough that signatures can be implemented without inventing a parallel type system.

• F4 - I/D/S discipline. Strict distinction (A.7, E.10.D2) already separates intensional objects, their descriptions, and specifications. The same discipline is needed inside relations:

  • slot ≠ value ≠ reference,
  • system role ≠ slot name,
  • describedEntity ≠ guard,
  • and “change the reference” ≠ “change the thing referred to”.

• F5 - Didactic primacy and naming discipline. E.8 and E.10 demand patterns that are:

  • teachable (Tell‑Show‑Show examples, explicit biases),
  • lexically guarded (Tech/Plain split, explicit head‑nouns).

  Slot discipline must integrate seamlessly with that.

• F6 - Binding‑time talk must be unambiguous. “Early binding / late binding” is meaningful only if the author states what is being fixed when. FPF needs a canonical way to speak about:

  • early/late slot filling,
  • early/late reference resolution / dispatch,
  • and (where a language surface is in play) early/late name binding.

#Solution — SlotKind / ValueKind / RefKind triple (plus a slot‑operation lexicon)

#Three layers for every argument position

U.RelationSlotDiscipline extends U.Signature with a three‑layer description for every argument position (whether we call it “parameter”, “slot”, “coordinate”, or “port” in colloquial prose). In normative text, the canonical word is slot, and the canonical carrier is a SlotSpec triple (A.6.0).

1. SlotKind (place in signature). How this position is denoted in the Signature and what is fixed about it by the signature’s definition. – Examples: DescribedEntitySlot, GroundingHolonSlot, ClaimGraphSlot, ViewpointSlot, ServiceEndpointSlot, CallerHolonSlot, MetricSlot. – SlotKind is structural: it picks out one distinguished place in the argument/port/field list of a given relation, operator, record, or other signatured bundle; it does not name a “role” played by whatever fills the slot. – For an n‑ary relation/operator declared in a U.Signature, the pair (Signature id, SlotKind) identifies a slot; positional indices are merely a presentation‑level enumeration of these slots. – What a filler “does” in that place (its contribution to laws, constraints, effects) is governed by the laws over the Signature and by the corresponding ValueKind, not by SlotKind‑as‑“role”.

2. ValueKind (kind of slot filler). Which kinds of things may fill this position in principle (at the intensional level). – Examples: U.Entity, U.Holon, U.Method, U.Episteme, U.ClaimGraph, U.Viewpoint, U.Characteristic, U.ReferenceScheme. – ValueKind is a Kind (C.3.*) or another kernel‑level type; it is not a slot and never carries *Slot/*Ref suffixes.

3. RefKind (how we store / refer). What reference/identifier we actually store in episteme when we fill this slot. – Examples: U.EntityRef, U.HolonRef, U.MethodRef, U.EpistemeRef, U.ViewpointRef, U.SurfaceRef, (optionally) U.ClaimGraphRef if a Context chooses to reference claim graphs rather than store them by value. – RefKind is about references, not values; it usually points to an editioned artifact (A.7, F.15) and carries the .edition field when pinning a phase.

Discipline:

• Each declared argument position in a U.Signature MUST be described by:

  • a SlotKind (name and documentation),
  • a ValueKind (type of permissible fillers),
  • and either a RefKind or an explicit declaration “by‑value” (no RefKind; the value is embedded).

• SlotKind and ValueKind are intensional; RefKind is representational. This mirrors I/D/S: slot describes structure, value describes what can sit there, ref describes how we point to concrete instances.

#Naming discipline: Slot and Ref

This pattern introduces the following lexical constraints, aligned with E.10:

1. *Slot reserved for SlotKind.

   • Any Tech name ending with …Slot MUST denote a SlotKind: a named place in a relation/morphism signature.
   • Examples: – DescribedEntitySlot, GroundingHolonSlot, ClaimGraphSlot, ViewpointSlot, ViewSlot, RepresentationSchemeSlot, ReferenceSchemeSlot.
   • *Slot MUST NOT appear in names of: – ValueKind (e.g. U.Entity, U.Holon, U.Method), – RefKind (e.g. U.EntityRef), – concrete episteme fields (they may be named e.g. describedEntityRef, but not describedEntitySlotField).

2. *Ref reserved for RefKind and reference fields.

   • Any Tech name ending with …Ref MUST denote either: – a RefKind (type of references/identifiers), or – a field whose type is a RefKind (describedEntityRef : U.EntityRef).
   • *Ref MUST NOT appear in names of: – ValueKinds (e.g. U.EntityRef cannot mean “an entity”; it is a reference type), – SlotKinds, – Kinds themselves (U.Kind, U.Entity, U.Holon).

3. ValueKind names carry no *Slot/*Ref.

   • ValueKinds are named using standard FPF conventions (A/E/F, E.10), without *Slot/*Ref.
   • Examples: U.Entity, U.Holon, U.Method, U.ClaimGraph, U.ReferenceScheme, U.Viewpoint, U.View.

4. No “Role” as SlotKind head.

   • In the context of relation signatures, do not use “Role” as the head noun for SlotKinds (to avoid conflict with U.Role).
   • Use “Slot” or a neutral description: e.g. EnactorHolonSlot (ValueKind U.Holon) rather than EnactorRoleSlot.

These rules become part of the LEX‑BUNDLE guards and are enforced by F.18 / name‑acceptance harnesses.

#Integration with U.Signature (A.6.0)

U.Signature already provides a generic pattern for declaring morphism/relationship signatures (SubjectKind, BaseType, Quantification, ResultKind, Vocabulary, Laws).

U.RelationSlotDiscipline refines this by adding a SlotSpec layer:

For each parameter position i in a signature:

SlotSpec_i = ⟨name: SlotKind, value: ValueKind, refMode: {ByValue | RefKind}⟩

• SlotKind — Tech name with *Slot suffix, plus documentation.

• ValueKind — a U.Type (often a U.Kind or kernel type) declaring the intensional universe of admissible fillers.

• refMode:

  • ByValue — the actual value of ValueKind is embedded (typical for small structured values like U.ClaimGraph inside an episteme card).
  • RefKind — a type of references/identifiers for that ValueKind; e.g. U.EntityRef for U.Entity, U.HolonRef for U.Holon. Substitution then operates on references, not directly on the underlying values.

In practice, a U.Signature that follows this pattern:

• becomes self‑documenting: each parameter has a clear “slot vs value vs ref” story;
• supports typed substitution: replacing content within the same SlotKind requires only ValueKind compatibility;
• aligns with tool signatures in implementation languages (row‑typed records, dependently typed parameters, effect‑typed arguments). ([13])

#Typed substitution discipline

Given a relation or morphism R with signature Σ and SlotSpecs {SlotSpec_i}:

• A substitution at slot i is a change of the slot content that fills SlotKind_i, within or across episteme entries.
• U.RelationSlotDiscipline enforces:

1. SlotKind invariance. A substitution never changes SlotKind — only the slot content (Value/Ref). – “We put a different dataset into the DatasetSlot.” – “We switch the grounding holon in GroundingHolonSlot.”

2. ValueKind compatibility. The new content MUST be of the same ValueKind (or a declared subkind) as SlotSpec_i.value; Kind‑CAL governs this (⊑ in C.3.1–C.3.2). If a Context uses EoIClass species constraints (C.3.2), those act as additional guards but do not change the SlotKind.

3. RefKind correctness. If refMode=RefKind, the stored field is of that RefKind; substitutions operate on references, not on underlying values. Edition pinning is handled as usual by .edition fields in F‑patterns (F.15, etc.).

4. By‑value vs by‑ref awareness. Substitutions at by‑value slots (e.g. ClaimGraphSlot) are content edits to the episteme or relation instance; they may affect formality F or assurance lanes. Substitutions at ref slots are retargetings of describedEntity or context, and their legality is governed by A.6.2–A.6.4 and Bridge/CL rules. Tooling SHOULD surface this difference explicitly in authoring surfaces (e.g. separate “Ref” vs “embedded content” columns).

These rules give a uniform way to say:

“You may swap component X with Y in this slot, because they share ValueKind and pass the relevant Kind/Bridge constraints.”

#Slot operation lexicon (binding / filling / assignment / retargeting / mutation)

This subsection standardises how Core and extensions talk about operations over slots, without committing FPF to any particular programming language semantics. It is a lexical and didactic guardrail that preserves the SlotKind/ValueKind/RefKind stratification in prose.

#Four‑way separation: Identifier vs Slot vs Slot‑content vs Referent

Diagram is illustrative; the term distinctions are normative.

To avoid conflating “binding / assignment / passing / mutation”, FPF authors SHALL keep the following separation in mind:

(1) Identifier/Name  ──binds-to──>  (2) SlotKind  ──in an instance──>  (2′) Slot‑instance  ──filled-with──>  (3) Slot‑content (Value | Ref)
                                                              └─(if Ref) resolves-to──> (4) Referent value / artifact

Normative terms:

• Identifier (Surface): a name used in a syntax, table column, record field, port label, or parameter label.

• SlotKind (I‑plane): the signature‑level label for a distinguished place in a relation.

• Slot‑instance (S‑plane / representation): the actual location/cell/position corresponding to a SlotKind inside a specific relation instance, record, port bundle, or episteme card.

• Slot‑content (representation): what is stored in a slot‑instance. It is either:

  • a by‑value value of ValueKind, or
  • a reference handle of RefKind.

• Referent: the intensional thing the RefKind points to when resolved (often an editioned artifact).

This separation is the anchor for all “binding time” talk in A.6.5:4.6.

#Canonical verbs (Tech register) for slot operations (normative)

When a pattern, bridge, or operator description discusses a change or action “with respect to a slot”, it SHALL use (or explicitly map to) the following verbs. Each verb is tied to which link/layer it affects.

1. bind / rebind (Identifier → SlotKind/slot‑instance). Use when the subject is an Identifier/Name and the effect is changing what that name designates. – bind: establish a new association of an Identifier to a SlotKind/slot‑instance (or to a value in a language surface). – rebind: change an existing association of an Identifier to designate a different slot‑instance or different value. Guard: do not use “bind” to mean “write into a slot”. Binding is about names, not slots.

2. fill (Slot‑instance ← Slot‑content). The generic, cross‑domain verb meaning “provide slot‑content for a slot‑instance”. – Fill does not by itself imply first‑time vs update, nor by‑value vs by‑ref. – Use fill when discussing hardware slots, tuple coordinates, ports, record fields, or parameters uniformly.

3. initialize (first fill). Use when the slot‑instance previously had no content. – For refMode=RefKind: initialization sets the initial reference handle. – For ByValue: initialization sets the embedded initial value. Guard: do not call initialization “assignment” in normative text.

4. assign / set / write / update (subsequent fill; slot‑content replacement). Use when a slot‑instance already has content and you replace it with new content. – These verbs are allowed as near‑synonyms, but SHOULD be used consistently within one pattern family. Guard: when refMode=RefKind, prefer retarget (below) if the intent is “change what this ref points to”, not “edit content”.

5. retarget (Ref slot update, same SlotKind/ValueKind). Use only for refMode=RefKind slots, when the operation replaces one reference handle with another, thereby changing the referent while preserving SlotKind and ValueKind. – “Retarget DescribedEntitySlot from UserService#staging to UserService#prod.” Retargeting is the canonical FPF verb for “swap the referenced thing in this slot”.

6. substitute (typed replacement with explicit compatibility claim). Use when the statement’s main point is the compatibility law (“allowed because ValueKind matches”). – Substitute is a discipline word: it signals that SlotKind is fixed and ValueKind compatibility is being asserted/checked.

7. resolve / dereference (Ref → Referent). Use when a reference handle is mapped to the intensional referent. – This is where “late binding” often hides in runtime systems (dispatch, dynamic lookup, registry indirection). Guard: resolving a reference is distinct from retargeting the reference.

8. mutate / modify (Referent internal change; content unchanged). Use only when the referent itself changes while the slot‑content (the reference handle) does not. FPF note: In edition‑disciplined contexts, prefer to describe intentional change as revise / re‑edition + retarget, rather than “mutate”, because the Core treats editioned artifacts as stable per edition (A.7, F.15).

9. pass (parameter slot filling). Use for method/service signatures when an argument fills a parameter slot at a call boundary. – Passing is a specialised instance of fill, typically realised as parameter binding + slot filling in implementation languages. In FPF text, “pass into SlotKind” is acceptable if SlotKind names the parameter position.

#Canonical nouns (normative)

To prevent role metaphors from re‑entering slot talk:

• Use slot‑content (preferred) or slot filler for “the thing currently in the slot”.
• Avoid person/role metaphors such as occupant in normative writing. If a Context insists on using such a word in Plain register, it SHALL define it explicitly as a synonym for slot‑content and SHALL NOT derive role semantics from it.
• Use target/referent for what a Ref points to; use retargeting for changing the target by changing the Ref.
• Use by‑value edit (or embedded content edit) for changes to a ByValue slot such as ClaimGraphSlot.

#Operator naming guidance for slot‑writing operators (normative, but intentionally lightweight)

When naming an operator/morphism/bridge whose primary effect is a slot change, the Tech name SHOULD make two things legible:

1. Which SlotKind(s) it writes, and
2. Which operation class it is, using the canonical verbs above.

Recommended patterns (examples only; Contexts may adopt their own naming style via F.18):

• Retarget<SlotQualifier> for ref‑slot retargeting (e.g. RetargetDescribedEntity, RetargetGroundingHolon).
• Edit<SlotQualifier> / Update<SlotQualifier> for by‑value content edits (e.g. EditClaimGraph).
• Substitute<SlotQualifier> when the operator exists to enforce/declare ValueKind compatibility (e.g. SubstituteDataset).
• Resolve<SlotQualifier> when the operator is about resolving a Ref to a referent (e.g. ResolveServiceEndpoint).

This rule is a lexical enforcement of A.6.5:4.4 (typed substitution discipline): the name should tell the reader whether the operator is a retargeting (ref change) or a content edit (by‑value change).

#Binding time and “early vs late binding” (normative framing, informative examples)

In cross‑domain slot talk, “early binding / late binding” is meaningful only if the author states which link is being fixed when. Under A.6.5:4.5, there are three distinct “times” that writers must not conflate:

1. SlotSpec time (signature time). SlotKind / ValueKind / refMode are fixed when the U.Signature is declared. This is “early” by definition in FPF Core.

2. Slot filling time (initialization / assignment / retargeting). A particular relation instance / episteme card / parameter bundle acquires slot‑content for a SlotKind. – Early‑filled means: chosen at authoring/spec time (e.g. configuration pins a specific U.HolonRef). – Late‑filled means: chosen at runtime or late in a workflow (e.g. service endpoint selected by policy at deployment).

3. Resolution / dispatch time (resolve RefKind; select referent). Even if a ref handle is present, the referent may be resolved early or late. – Eager resolution means: resolve now, cache/commit to a referent. – Lazy resolution means: resolve on demand. – Dynamic dispatch is a special case: the “method slot” is resolved at call time based on a receiver/context, rather than being statically selected.

Rule (lexical guard): Any use of “early binding” / “late binding” in Core or extensions SHALL specify which of the above it refers to, using one of:

• early/late‑filled (slot filling),
• eager/lazy‑resolved (resolution),
• early/late name‑binding (Identifier binding, if a language surface is being discussed).

This preserves the A.6.5 stratification and prevents importing accidental semantics from a specific programming language.

#Archetypal Grounding (Tell‑Show‑Show)

Following E.7, we ground the pattern in a System example and an Episteme example.

#System example — authentication pipeline signature

Consider an AuthPipelineSpecKind (system‑level episteme describing an authentication pipeline for a microservice). Its key slots might be:

• DescribedEntitySlot — “which holon the pipeline is about” – ValueKind: U.Holon (EoIClass = “UserService system”). – RefKind: U.HolonRef (e.g. UserService#prod).

• AuthProviderComponentSlot — “which authentication provider component is selected” – ValueKind: U.Holon (EoIClass = “AuthProviderSystem”). – RefKind: U.HolonRef (e.g. Auth_OIDC, Auth_LDAP).

• ClaimGraphSlot — “what is asserted about the pipeline” – ValueKind: U.ClaimGraph. – refMode: ByValue (ClaimGraph stored inside the episteme card).

Substitutions / retargetings:

• Retargeting AuthProviderComponentSlot from Auth_OIDC to Auth_LDAP: – SlotKind fixed (AuthProviderComponentSlot). – ValueKind unchanged (U.Holon, AuthProviderSystem ⊑ U.Holon). – RefKind unchanged (U.HolonRef). – Semantically: “retarget the ref that fills the same slot”.

• Retargeting DescribedEntitySlot from UserService#staging to UserService#prod: – Same SlotKind and ValueKind. – Different U.HolonRef slot‑content. – May require different grounding and assurance episteme, but the slot discipline is identical.

#Episteme example — model evaluation result

Consider ModelEvaluationResultKind as an episteme kind:

• DescribedEntitySlot — the model being evaluated – ValueKind: U.Method (intensional ML model). – RefKind: U.MethodRef (id of Model_v3).

• DatasetSlot — the dataset on which it is evaluated – ValueKind: U.Entity (EoIClass = “Dataset”). – RefKind: U.EntityRef (e.g. Dataset_A, Dataset_B).

• TargetCharacteristicSlot — the characteristic being measured – ValueKind: U.Characteristic (Accuracy, F1, AUROC). – RefKind: U.CharacteristicRef.

• GroundingHolonSlot — evaluation environment – ValueKind: U.Holon (e.g. EvalCluster#1). – RefKind: U.HolonRef.

• ClaimGraphSlot — evaluation result graph – ValueKind: U.ClaimGraph. – refMode: ByValue; the numeric thresholds and results live inside content : U.ClaimGraph.

Typical moves:

• DatasetSlot: retarget Dataset_A → Dataset_B to test generalisation.
• TargetCharacteristicSlot: retarget Accuracy → F1 to focus on class imbalance.
• ClaimGraphSlot: by‑value edit thresholds from “P95Latency ≤ 200 ms” to “≤ 150 ms” — a ByValue content edit, not a ref retargeting.

The SlotKind/ValueKind/RefKind discipline makes these moves local and explicit: the pattern describes which moves are allowed where, and A.6.2–A.6.4 then constrain how episteme morphisms may change ClaimGraphs and references.

#Didactic micro‑examples — substitution by SlotKind / ValueKind / RefKind (informative)

The following short examples are intended for a didactic guide or for cross‑references from A.6.0/A.6.x/C.2.1. In all of them:

• SlotKind names the place/position in the structure (slot/field/coordinate in a tuple/record/port bundle).
• ValueKind is the kind of value admissible at that place.
• RefKind is the reference/identifier type used in episteme when that slot is filled (absent when the slot is by‑value).
• GroundingHolon is not a separate kernel type: it is simply a U.Holon used as the ValueKind of GroundingHolonSlot.

Example names like FurnitureSafetyDescriptionKind, AuthPipelineSpecKind, ModelEvaluationResultKind, IncidentRunbookSpecKind, ServiceSLARequirementKind are context‑local kinds, not new kernel tokens.

#Mechanics — stool on a test rig

EpistemeKind: FurnitureSafetyDescriptionKind.

SlotKind / ValueKind / RefKind:

• DescribedEntitySlot — SlotKind “what this description is about”; ValueKind U.Entity with EoIClass ⊑ U.Holon (stool as a furniture holon); RefKind U.EntityRef (identifier of a concrete stool S_i).
• GroundingHolonSlot — SlotKind “where the test happens”; ValueKind U.Holon (test rig LabRig_j); RefKind U.HolonRef.
• ClaimGraphSlot — SlotKind for the internal content; ValueKind U.ClaimGraph; refMode ByValue (graph embedded in the episteme).

Substitutions (all under the same SlotKinds):

• Episteme E₁: describedEntityRef = S_1, groundingHolonRef = LabRig_A.
• Episteme E₂: describedEntityRef = S_2, groundingHolonRef = LabRig_A — substitute another stool in the same DescribedEntitySlot (different U.EntityRef slot‑content).
• Episteme E₃: describedEntityRef = S_1, groundingHolonRef = LabRig_B — substitute another test rig in GroundingHolonSlot while keeping the same object‑of‑talk.

In all three cases the SlotKinds (and ValueKinds) are stable; only the Refs that fill those slots change. This matches the engineering idiom “drop another module into the same slot”.

#Microservices — switching the authentication provider

EpistemeKind: AuthPipelineSpecKind.

SlotKind / ValueKind / RefKind:

• DescribedEntitySlot — ValueKind U.Holon with EoIClass = “UserService holon”; RefKind U.HolonRef (e.g. UserService#prod).
• AuthProviderComponentSlot — SlotKind “which auth provider component is used in this pipeline”; ValueKind U.Holon with EoIClass = “AuthProviderSystem holon”; RefKind U.HolonRef (e.g. Auth_OIDC, Auth_LDAP).
• ClaimGraphSlot — ValueKind U.ClaimGraph; refMode ByValue (pipeline invariants and flow logic).

Substitutions / retargetings:

• Episteme Spec_OIDC: describedEntityRef = UserService#prod, authProviderComponentRef = Auth_OIDC.
• Episteme Spec_LDAP: same describedEntityRef = UserService#prod, but authProviderComponentRef = Auth_LDAP.

Here SlotKind is identical (AuthProviderComponentSlot); ValueKind is “any auth‑provider holon”; the episteme change is purely a retargeting of the U.HolonRef slot‑content.

#Data/ML — swapping dataset or target characteristic

EpistemeKind: ModelEvaluationResultKind.

SlotKind / ValueKind / RefKind:

• DescribedEntitySlot — ValueKind U.Method; RefKind U.MethodRef (e.g. Model_v3).
• DatasetSlot — ValueKind U.Entity with EoIClass = “dataset”; RefKind U.EntityRef (Dataset_A, Dataset_B, …).
• TargetCharacteristicSlot — ValueKind U.Characteristic; RefKind U.CharacteristicRef.
• GroundingHolonSlot — ValueKind U.Holon; RefKind U.HolonRef.
• ClaimGraphSlot — ValueKind U.ClaimGraph; refMode ByValue.

Substitutions / retargetings:

• Eval_1: describedEntityRef = Model_v3, datasetRef = Dataset_A, targetCharacteristicRef = Accuracy, groundingHolonRef = EvalCluster#1.
• Eval_2: same model / characteristic / cluster, but datasetRef = Dataset_B — substitute another dataset in DatasetSlot (retarget the dataset ref).
• Eval_3: same model and dataset, but targetCharacteristicRef = F1 — substitute another characteristic in TargetCharacteristicSlot.

#Operational practice — the same runbook in different operating centres

EpistemeKind: IncidentRunbookSpecKind.

SlotKind / ValueKind / RefKind:

• DescribedEntitySlot — ValueKind U.Method; RefKind U.MethodRef.
• GroundingHolonSlot — ValueKind U.Holon; RefKind U.HolonRef.
• ClaimGraphSlot — ValueKind U.ClaimGraph; refMode ByValue.

Substitutions / retargetings:

• Runbook_DC1: describedEntityRef = MajorIncidentRunbook, groundingHolonRef = DC1_NOC.
• Runbook_DC2: same describedEntityRef, but groundingHolonRef = DC2_NOC.

This is “one and the same method is specified and validated in two different operational environments”: SlotKind and ValueKind are stable; only the U.HolonRef slot‑content differs.

#SLO/SLA requirements — changing the target characteristic vs changing the threshold

EpistemeKind: ServiceSLARequirementKind.

SlotKind / ValueKind / RefKind:

• DescribedEntitySlot — ValueKind U.Holon; RefKind U.HolonRef (e.g. CheckoutService#prod).
• TargetCharacteristicSlot — ValueKind U.Characteristic; RefKind U.CharacteristicRef.
• ClaimGraphSlot — ValueKind U.ClaimGraph; refMode ByValue. Numeric thresholds live inside the ClaimGraph as literals, not as RefKinds.

Moves:

• SLA_latency_200: describedEntityRef = CheckoutService#prod, targetCharacteristicRef = P95Latency; ClaimGraph contains P95Latency ≤ 200 ms.
• SLA_latency_150: same refs, but ClaimGraph threshold is P95Latency ≤ 150 ms. This is a by‑value edit of ClaimGraphSlot.
• SLA_availability_99_9: same describedEntityRef, but targetCharacteristicRef = Availability; ClaimGraph states Availability ≥ 99.9%. This is a retargeting of TargetCharacteristicSlot.

#Bias‑Annotation

Lenses tested and scope. This pattern was read through all five Principle‑Taxonomy lenses (Gov, Arch, Onto/Epist, Prag, Did) and is intended as a universal discipline for n‑ary relation and morphism signatures across Parts A/B/C/E. It leans toward the Arch and Onto/Epist lenses (typed signatures, explicit kinds), but mitigates this by (a) keeping the discipline notation‑agnostic, (b) aligning with existing tooling rather than prescribing any, and (c) grounding the rules in System/Episteme examples with clear didactic intent. No domain‑specific scope limitation is claimed.

• Typed‑language bias.

  • The pattern leans on intuitions from typed programming languages (parameter types, records, references). This is intentional: it aligns FPF signatures with mainstream tooling and with post‑2015 typed effect/row systems. The pattern remains notation‑agnostic and does not commit to any specific PL or logic.

• Slot‑first bias.

  • We treat slot as the primary abstraction and discourage role‑style or object‑style naming for argument positions. This favours structural clarity over conversational metaphors (“subject/object/role”) and keeps U.Role free for RoleEnactment rather than param‑slots.

• By‑value/by‑ref honesty. We explicitly separate ValueKind and RefKind instead of hiding “by‑reference” behind the type system. This increases verbosity but makes reasoning about edition pinning, caching, and re‑targeting more robust, and keeps I/D/S distinctions visible inside signatures.

• Lexicon bias (precision over metaphor). We standardise the slot‑operation lexicon (bind/fill/initialize/assign/retarget/resolve/mutate) and discourage metaphors that smuggle role semantics back into SlotKinds. This increases didactic load, but directly reduces cross‑pattern ambiguity, especially in “binding time” discussions.

• Episteme‑first describedEntity. The examples and cross‑references prioritise episteme use‑cases (C.2.1, A.6.2–A.6.4) where describedEntity and retargeting are subtle. System‑only usages (e.g. method signatures) are absolutely allowed but not the driving case; they inherit the same discipline without additional obligations.

#Conformance Checklist (normative)

CC‑A.6.5‑1 - SlotSpec for every parameter. Every U.Signature that declares an n‑ary relation or morphism SHALL assign to each parameter position a SlotSpec triple: ⟨SlotKind, ValueKind, refMode⟩.

CC‑A.6.5‑2 - *Slot discipline. Any Tech name ending with …Slot MUST denote a SlotKind; SlotKinds MUST NOT be used as ValueKinds or RefKinds.

CC‑A.6.5‑3 - *Ref discipline. Any Tech name ending with …Ref MUST denote either a RefKind or a field whose type is a RefKind. ValueKinds and SlotKinds MUST NOT end in …Ref.

CC‑A.6.5‑4 - ValueKind purity. ValueKinds MUST be declared without *Slot/*Ref suffixes and MUST be FPF types (often U.Kind or kernel‑level types). Any existing type whose name violates this rule must be either:

• reclassified as a RefKind, or
• renamed to drop the suffix.

CC‑A.6.5‑5 - Episteme core SlotKinds. For episteme kinds (U.EpistemeKind), the following SlotKinds SHALL be used (or their documented refinements) in C.2.1 / C.2.x:

• DescribedEntitySlot with ValueKind U.Entity or a declared subkind (e.g. U.Method, U.Holon) via Kind‑CAL (EoIClass ⊑ U.Entity at species level);
• GroundingHolonSlot with ValueKind U.Holon;
• ClaimGraphSlot with ValueKind U.ClaimGraph and ByValue mode in the minimal core;
• ViewpointSlot with ValueKind U.Viewpoint;
• ViewSlot with ValueKind U.View (U.EpistemeView);
• ReferenceSchemeSlot with ValueKind U.ReferenceScheme and ByValue mode in the minimal core.

CC‑A.6.5‑6 - No “Role” as SlotKind head. SlotKinds MUST NOT use “Role” as their head noun; use “Slot” with a neutral qualifier instead (e.g., EnactorHolonSlot). U.Role remains reserved for RoleEnactment patterns.

CC‑A.6.5‑7 - Substitution checks. Any pattern that describes substitution or replacement of arguments MUST phrase its rules in terms of SlotKinds and ValueKinds (and, where relevant, RefKinds), not in terms of unstructured parameter indices or ad‑hoc labels.

CC‑A.6.5‑8 - Cross‑pattern consistency. When the same conceptual position is used across patterns (e.g. “describedEntity target”, “grounding holon”, “caller system”), the same SlotKind name and ValueKind SHALL be reused, unless a documented Bridge declares a different discipline or the pattern explicitly scopes itself to a distinct calculus.

CC‑A.6.5‑9 - Migration of legacy …Ref/…Slot usage. Contexts adopting this pattern MUST maintain a migration table for legacy types/fields whose names contain Ref or Slot but do not comply with the new discipline. Each entry shall state:

• old name and role,
• new SlotKind/ValueKind/RefKind,
• whether the old name becomes an alias (deprecated) or is removed.

CC‑A.6.5‑10 - Pattern integration. New or revised patterns in Part A/B/C/E that introduce n‑ary relations, morphisms, or signatures SHALL reference A.6.5 in their Relations section and attest that they follow SlotKind/ValueKind/RefKind discipline.

CC‑A.6.5‑11 - Slot‑content terminology. Normative text that refers to “what is in a slot” SHALL use slot‑content (or slot filler) and SHALL NOT rely on role/person metaphors (e.g. “occupant”) unless explicitly defined as a strict synonym for slot‑content with no added semantics.

CC‑A.6.5‑12 - Slot‑operation verb discipline. Any normative description of a change “to a slot” MUST specify which operation class it is (initialize vs assign/set vs retarget vs by‑value edit vs resolve vs mutate/revise), using the canonical verbs in A.6.5:4.5.2 or explicitly mapping local terms to them.

CC‑A.6.5‑13 - Binding‑time clarity. Any use of “early binding / late binding” (or equivalent) MUST specify whether it refers to:

• Identifier binding (name‑binding),
• Slot filling (early/late‑filled),
• Reference resolution / dispatch (eager/lazy‑resolved).

#Consequences

Benefits

• Uniform language for arguments and for operations. Any n‑ary relation (episteme, role, method, service, guard) can be described with the same SlotKind/ValueKind/RefKind triple and with a stable operation lexicon (fill/initialize/assign/retarget/resolve).

• Safer substitutions. Substitution, retargeting, and viewing laws (A.6.2–A.6.4) can be stated in terms of which SlotKinds they read/write and which ValueKinds they preserve or retarget, without accidentally collapsing into “just replace the thing”.

• Cleaner naming and migration. Misuses of *Ref, *Slot, “Role”, “Subject”, “Object” in signatures become guard‑detectable; migration strategies can be described as re‑factoring SlotKinds and ValueKinds rather than ad‑hoc renames.

• Tool alignment. Implementation languages with row‑typed records, dependent types, and algebraic effects map naturally to the SlotKind/ValueKind/RefKind layers, easing code generation and static analysis. ([13])

Trade‑offs / mitigations

• Extra metadata in signatures. Every parameter now has three pieces of information instead of one. Mitigation: template support in authoring tools; pattern‑guided macros for common shapes (episteme, role, method, service).

• Stricter lexical rules. Some legacy names will need migration (EpistemicObject, ad‑hoc …Ref types). Mitigation: migration notes in F.18 and dedicated anti‑pattern sections; transitional aliases allowed but marked deprecated.

• Learning curve. Authors must learn to think “SlotKind/ValueKind/RefKind” and distinguish “retarget vs edit vs resolve” before writing id or subject. Mitigation: Tell‑Show‑Show examples and a didactic micro‑guide on slot operations referenced from A.6.0/C.2.1/E.17.0.

#Rationale

Why a SlotKind/ValueKind/RefKind triple at all. In FPF this pattern makes U.Signature behave like a lightweight dependently‑typed record discipline: SlotKind plays the role of an index or label, ValueKind is the family of admissible fillers at that position, and RefKind captures the representation choice (by‑value or via a handle). This mirrors the way post‑2015 work on row‑polymorphic data and effect rows treats labels and field kinds as first‑class, while keeping the Core notation‑neutral.

Why separate ValueKind from RefKind. In practice, “Ref” types tend to be quietly used as if they were values, eroding the I/D/S split and making edition discipline invisible. By insisting that ValueKind is always the conceptual kind (“what sort of thing is this about?”) and RefKind is always the reference/identifier kind (“how do we point at it in Episteme?”), the pattern aligns with E.10.D2’s intension/description/specification discipline and with modern resource‑aware logics that keep values and resources distinct.

Why add a slot‑operation lexicon. The triple only buys safety if authors and tools can see it at a glance and can narrate changes without collapsing layers. A.6.5:4.5 makes the common “put something in a slot” moves explicit: initialization vs assignment vs retargeting vs by‑value editing vs resolution. This directly reduces ambiguity in episteme morphism descriptions (A.6.2–A.6.4) and prevents accidental imports from a specific PL’s terminology.

Why standardise episteme SlotKinds. describedEntity and grounding recur across epistemes; standard SlotKinds (DescribedEntitySlot, GroundingHolonSlot, ClaimGraphSlot, etc.) let A.6.2–A.6.4 and C.2.1 talk about substitutions and retargetings once, instead of re‑defining “what this is about” in every pattern.

Why lexical rules (*Slot, *Ref, operation verbs, no “Role” heads). The discipline must be cheap to apply. Reserving *Slot for SlotKinds and *Ref for RefKinds/fields gives a syntax‑level guard against conflating places, kinds, and handles. Standardising operation verbs (initialize/retarget/resolve) prevents prose from re‑introducing the same conflation by different words.

#SoTA‑Echoing (post‑2015 practice alignment)

Purpose. To situate SlotKind/ValueKind/RefKind discipline with respect to contemporary typed and relational approaches, without importing any external calculus into the Core. All items are used as conceptual comparators; concrete reuse in a U.BoundedContext would happen only via explicit Bridges (F.9) with declared CL penalties.

1. Row‑typed, extensible data / effect rows (adopt/adapt). Post‑2015 work on row polymorphism and extensible data/effect rows treats records and variants as labelled collections of fields whose presence and type can evolve independently. Adopted: the idea that positions (labels) are first‑class and carry their own typing discipline. Adapted: instead of row kinds, FPF uses SlotKind/ValueKind/RefKind triples for n‑ary relations and epistemic slots; the pattern is notation‑agnostic and applies equally to episteme structures, role relations, and service signatures. ([13])

2. Dependent type systems engineered via macros (adopt/adapt). Macro‑based dependent type systems such as Turnstile+ separate structural indices, value‑level types, and evidence, while allowing them to be related by construction. Adopted: the separation between indices/labels and values, and the intuition that signatures should expose both explicitly. Adapted: SlotKind corresponds to a structural index, ValueKind to the ordinary type of fillers, and RefKind to runtime‑level identifiers; the discipline is phrased at the FPF specification and kept independent of any particular PL.

3. Relational models of types‑and‑effects (adapt). Relational models for types‑and‑effects distinguish value positions from effect/resource annotations and track substitution separately across these layers. Adopted: the insistence that reasoning about substitution and equality must be stratified (values vs additional structure). Adapted: A.6.5 stratifies slot / value / reference instead of value / effect, and applies the discipline not only to programs but also to epistemes, roles, methods, and services. ([15])

4. Optics / lenses as disciplined projections (echo). Profunctor optics formalise get/put pairs where a fixed “focus” position within a larger structure is manipulated under composition laws. Echoed: SlotKind plays the role of the focus coordinate; ValueKind is the focus type; RefKind determines whether the focus is stored by value or via a handle. This perspective informs later use of SlotKind discipline in EpistemicViewing (A.6.3) and multi‑view publication (E.17). ([16])

Cross‑Context reuse and Bridges. When a U.BoundedContext chooses to adopt a concrete row‑typing discipline, relational logic, or optics library, it SHALL do so via explicit Bridges (F.9) with CL and (for plane crossings) Φ(CL)/Φ_plane policy‑ids, keeping numerical policies and notations Context‑local. A.6.5 only constrains the slot discipline that such Bridges must respect.

#Relations (with other patterns)

Specialises A.6.P U.RelationalPrecisionRestorationSuite. A.6.5 is the RPR specialisation for “n‑ary relation as slots”: it restores hidden arity by making participant positions explicit as SlotKinds, and stabilises change semantics via the slot‑operation lexicon + lexical guards.

Builds on A.6.0 U.Signature. Refines parameter declarations with SlotSpec triples ⟨SlotKind, ValueKind, refMode⟩ while leaving the rest of the signature structure (SubjectKind, BaseType, Quantification, ResultKind, Laws) unchanged. SlotKinds become the canonical labels for argument positions.

Constrains C.2.1 U.EpistemeSlotGraph. Fixes core episteme SlotKinds (DescribedEntitySlot, GroundingHolonSlot, ClaimGraphSlot, ViewpointSlot, ViewSlot, ReferenceSchemeSlot) and their ValueKinds/ByValue vs Ref discipline. C.2.1 and its extensions SHALL use these SlotKinds (or documented refinements) so that episteme morphisms can be expressed uniformly over slots.

Supports A.6.2–A.6.4 (episteme morphisms and viewing). DescribedEntity‑preserving vs describedEntity‑retargeting morphisms can now be stated as constraints on which SlotKinds’ ValueKinds/RefKinds they may change. Retargeting becomes “retargeting at DescribedEntitySlot under a Kind‑Bridge” rather than an ad‑hoc parameter tweak. The operation lexicon in A.6.5:4.5 makes “retarget vs edit vs resolve” explicit in these morphism descriptions.

Coordinates with B.5. (RoleEnactment).* Role/assignment relations may declare SlotKinds such as HolderHolonSlot, RoleSlot, ContextSlot, WindowSlot with clear ValueKinds/RefKinds, instead of overloading “role” for both holonic roles and relation positions. This keeps U.Role semantics (A.2, F.6) separate from slot discipline.

Coordinates with E.17 U.MultiViewDescribing. Viewpoint and View positions are governed by SlotKind/ValueKind/RefKind; view‑changing operations can be described as substitutions at specific SlotKinds that preserve ClaimGraph content while re‑indexing viewpoints and views.

Feeds F.18 (LEX‑BUNDLE) and E.10 (LEX). Provides lexical guards for *Slot and *Ref, and (via A.6.5:4.5) for operation verbs:

• *Slot reserved for SlotKinds only;
• *Ref reserved for RefKinds and reference fields;
• ValueKinds and Kind names MUST NOT carry either suffix;
• slot‑operation verbs must not collapse retargeting into “editing”.

Used by A.19 CharacteristicSpace and measurement patterns. Characteristic‑space slots already behave as positions with attached kinds; slot discipline in A.6.5 gives a uniform story for how such slots appear inside relation signatures, episteme cards, and service definitions, and how substitution over those slots is checked.

[13] https://dl.acm.org/doi/pdf/10.1145/3290325 [14] https://www.williamjbowman.com/resources/wjb2019-depmacros.pdf [15] https://iris-project.org/pdfs/2017-popl-effects-final.pdf [16] https://arxiv.org/pdf/1809.00738

#A.6.5:End