#U.EffectFreeEpistemicMorphing - Effect-Free Morphisms of Epistemes

A.6.2 · Stable · 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.

One‑line summary. U.EffectFreeEpistemicMorphing (EFEM) is the universal class of effect-free, law-constrained morphisms between epistemes. An EFEM morphism rewrites episteme components (ClaimGraph, entityOfConcernRef, optional groundingHolonRef, viewpointRef, referenceScheme, and—where C.2.1+ is in use—representationSchemeRef and related slots, plus meta) in a conservative, functorial, reproducible way, with an explicit mode for what happens to the EntityOfConcernSlot (EntityOfConcernChangeMode ∈ {preserve, retarget}) as defined by C.2.1 U.EpistemeSlotRelation.

Placement. After A.6.1 U.Mechanism and before any specialisations (A.6.3 U.EpistemicViewing, A.6.4 U.EpistemicRetargeting).

Builds on. A.6.0 U.Signature (subject/vocabulary/laws/applicability); A.6.1 U.Mechanism; A.6.5 U.RelationSlotDiscipline; C.2.1 U.Episteme — Epistemes and their slot relation; E.10.D2 (EntityOfConcern and Description-episteme boundary and specification use/refinement gates); C.3.* (Kind‑CAL / KindBridge for EntityOfConcern classes).

Used by. A.6.3 U.EpistemicViewing; A.6.4 U.EpistemicRetargeting; E.17.0 U.MultiViewDescribing; E.17 (MVPK); E.18 (structural reinterpretation over transformation-flow structure).

EntityOfConcern change-mode discipline. EFEM uses EntityOfConcernChangeMode for the preserve/retarget characteristic over C.2.1's EntityOfConcernSlot / entityOfConcernRef family. Earlier source-side spellings must be normalized to the EntityOfConcern family before conformant use and do not define a second EntityOfConcern ontology.

FPF has many operations that transform knowledge epistemes or publications without directly doing work in the world:

#Relations

#Content

#Problem frame

FPF has many operations that transform knowledge epistemes or publications without directly doing work in the world:

• turning an informal method description into a more formal specification;
• projecting a large system description into a smaller “for‑safety‑officer” view;
• re‑expressing the same behavioural model in a different calculus or notation;
• retargeting an analysis from “this subsystem” to “that subsystem” along a known KindBridge.

All of these are episteme→episteme transforms: they change what is written in an episteme, but they do not themselves measure, execute, or actuate. They are neither Work (A.15) nor Mechanisms in the A.6.1 sense; they are “pure morphisms over epistemes”.

Without a universal pattern for such morphisms:

• every family (KD‑CAL, E.18, MVPK, discipline packs) reinvent their own notion of “projection”, “reinterpretation”, or “refinement”;
• laws about what may change in an episteme (content vs EntityOfConcern vs grounding holon vs reference plane) fragment across the spec;
• cross‑family reasoning (e.g. “this E.18 structural reinterpretation is a retargeting, not a view”) becomes brittle and ad‑hoc.

#Problem

Concretely, without EFEM:

1. No single place for “effect‑free” discipline. The distinction “episteme‑only change” vs “Work in the world” is already important (C.2.1 separates episteme components from Work and from publication forms, renderings, and carriers), but the laws for “episteme‑only” operations are scattered or implicit.

2. EntityOfConcern behaviour is unclear. Many transforms intend to keep “what this episteme is about” fixed (viewing), others intend to change it under an invariant (retargeting). Without a common EntityOfConcernChangeMode discipline we get silent breaks in “entityOfConcern”: an operation that looks like a harmless format change may in fact surreptitiously change the entity of concern.

3. No functorial backbone. MVPK, KD‑CAL, and E.18 all implicitly assume that episteme transforms compose and respect identities, but the conditions for this (purity, conservativity, idempotence, scope) are not formulated once and reused. Different parts of the spec repeat subtly different sets of laws.

4. Slot/Ref confusion. With the new U.EpistemeSlotRelation and U.RelationSlotDiscipline, every episteme now has explicit SlotKind / ValueKind / RefKind discipline. Laws for “projection” or “retargeting” that are written against “fields” or unnamed tuple components are now out of alignment.

The result: engineers and tool builders can no longer tell when they are allowed to transform epistemes without changing what is being claimed about the world, nor what needs to be witnessed by Bridges and CL‑penalties when entityOfConcern does change.

#Forces

• Epistemic purity vs operational power. Effect‑free episteme transforms are attractive precisely because they can be reasoned about algebraically and composed freely. But the more operational power they are given (IO, solver calls, measurements), the less they remain “pure” and the more they belong under U.Mechanism / U.WorkEnactment.

• Preserve vs retarget. Viewing is entityOfConcern‑preserving; reinterpretation along a KindBridge is entityOfConcern-retargeting. Both are important, but they must be distinguished and witnessed differently.

• Conservativity vs usefulness. EFEM should be conservative: no new commitments about the EntityOfConcern beyond what input epistemes already entail. At the same time, transformations may factor, aggregate, or normalise content, which may drop information or change representation when the loss and interpretation rule are explicit.

• Locality vs reference planes and Bridges. Epistemes live on reference planes (C.2.1); cross‑plane and cross‑Context reasoning goes via Bridges and CL penalties (Part F/B.3). EFEM must respect this: it cannot smuggle plane changes or transport into “pure” content rewrites.

• EntityOfConcern and Description-episteme boundary and specification-use refinement. The EntityOfConcern is not identical to the Description episteme produced by this use; it may itself be U.Episteme when an episteme is under concern. ...Description names a Description episteme, and ...Spec names a Description episteme admitted for specification use when its subjectRef decodes to DescriptionContext = ⟨EntityOfConcernRef, BoundedContextRef, ViewpointRef⟩ and the declared checkability/formality/harness gate is present. EFEM admits operations on those epistemes and their slot/ref discipline while keeping EntityOfConcern, Description episteme, Description episteme admitted for specification use, publication face, publication form, publication unit, publication carrier, and rendering lanes distinct (A.7, E.10.D2).

#Solution — define U.EffectFreeEpistemicMorphing once

#Informal definition

Definition. A U.EffectFreeEpistemicMorphing (EFEM) is a class of episteme→episteme morphisms that:

• operate only on the components of an episteme as fixed in C.2.1 U.EpistemeSlotRelation (ClaimGraphSlot, EntityOfConcernSlot, GroundingHolonSlot, ViewpointSlot, representation/reference schemes, and meta);
• are effect‑free (no Work, no Mechanism application, no mutation of systems or carriers);
• are conservative in what they claim about the EntityOfConcern: no new EntityOfConcern commitment may appear unless it is a logical consequence under the declared ReferenceScheme, correspondence, or bridge invariant;
• are functorial (identities and composition behave as expected on the category of epistemes);
• declare an explicit EntityOfConcernChangeMode ∈ {preserve, retarget}, controlling how EntityOfConcernSlot behaves, and how source-migration subjectRef decodes through DescriptionContext when that older wiring name is still present.

The category-theory objects of the EFEM universe are epistemes of some U.EpistemeKind (typically realised as U.EpistemeCard / U.EpistemeView / U.EpistemePublication). The arrows are EFEM morphisms f : X → Y satisfying the P0–P5 laws below.

Specialisations:

• U.EpistemicViewing (A.6.3) — EFEM with EntityOfConcernChangeMode = preserve.
• U.EpistemicRetargeting (A.6.4) — EFEM with EntityOfConcernChangeMode = retarget, tied to KindBridges/ReferencePlanes.

#Signature Block (A.6.0 alignment)

As a U.Signature, EFEM publishes the following SubjectBlock and the standard four‑row block (“SubjectBlock / Vocabulary / Laws / Applicability”) from A.6.0, specialised to episteme→episteme morphisms.

SubjectBlock

SubjectBlock
  SubjectKind   = U.EffectFreeEpistemicMorphing
  BaseType      = ⟨X : U.Episteme, Y : U.Episteme⟩        // episteme pair (domain,codomain)
  Quantification= SliceSet:=U.ContextSliceSet;
  ExtentRule:=admissibleEpistemeMorphisms // Context slices & admissible EFEM per slice
  ResultKind?   = U.Morphism                               // typed morphism f : X→Y

This says: EFEM is “about” morphisms between epistemes, indexed by Context slices; its results are morphisms of a declared type U.Morphism in the Ep category.

Vocabulary (core operators & kinds)

• Types

  • U.Episteme (as holon; realised via species U.EpistemeCard, U.EpistemeView, U.EpistemePublication under C.2.1).
  • U.EpistemeKind (episteme n‑ary relation signature; slots per A.6.5 / C.2.1).
  • U.SubjectRef (source-migration wiring name only; for Description epistemes, including Description epistemes admitted for specification use, it decodes to DescriptionContext = ⟨EntityOfConcernRef, BoundedContextRef, ViewpointRef⟩ per C.2.1 §6.1 / E.10.D2). It does not define another EntityOfConcern family.
  • U.Morphism (arrow in Ep).
  • U.EntityOfConcernChangeMode = {preserve, retarget} (enumeration; no new Kernel type for “EntityOfConcern”).

• Operators (arrow algebra)

  • id_X : U.Morphism(X→X) for any episteme X.
  • compose(g,f) : U.Morphism(X→Z) where f : X→Y, g : Y→Z.
  • apply(f, x:U.Episteme) : U.Episteme.
  • dom(f), cod(f) : U.Episteme.
  • subjectRef(E) : U.SubjectRef as source-migration projection from DescriptionContext, when old wiring still exposes that name.
  • entityOfConcernChangeMode(f) : U.EntityOfConcernChangeMode // EFEM‑level characteristic from C.2.1.

Each operator that takes epistemes as arguments obeys SlotSpec discipline from A.6.5: in particular, laws below are phrased in terms of the named SlotKinds (EntityOfConcernSlot, GroundingHolonSlot, ClaimGraphSlot, ViewpointSlot, ReferenceSchemeSlot, ViewSlot, and—when the C.2.1+ extension is used—RepresentationSchemeSlot) and their associated ValueKind/RefKind; we never speak of “field 1/2/3”.

Laws row and Applicability are given by P0–P5 and the Scope clause below.

#Laws P0–P5 (normative)

All laws below are admissibility predicates: a morphism advertised as an instance of U.EffectFreeEpistemicMorphing satisfies them.

#P0 — Typed signature & component profile (C.2.1‑grounded)

For any EFEM morphism f : X→Y:

1. Typed epistemes. X and Y are epistemes of declared kinds K_X, K_Y : U.EpistemeKind, each with a SlotKind signature as per C.2.1 and A.6.5 (at least EntityOfConcernSlot, ClaimGraphSlot, ViewpointSlot?, RepresentationSchemeSlot?, ReferenceSchemeSlot?; GroundingHolonSlot?, ViewSlot? where relevant).

2. Component projection. For each episteme E, EFEM laws may refer to:

   • content(E) : U.ClaimGraph — value of ClaimGraphSlot (stored by value in the minimal core);
   • entityOfConcernRef(E) : U.EntityRef — value of the RefKind for EntityOfConcernSlot;
   • groundingHolonRef?(E) : U.HolonRef — if the episteme kind includes GroundingHolonSlot;
   • viewpointRef?(E) : U.ViewpointRef — if ViewpointSlot is present;
   • referenceScheme?(E) : U.ReferenceScheme — value of ReferenceSchemeSlot (stored by value in the minimal core);
   • representationSchemeRef?(E) : U.RepresentationSchemeRef — only for episteme kinds that use the C.2.1+ RepresentationSchemeSlot;
   • meta(E) — edition/provenance/status components (species‑level).

3. Declared EntityOfConcernChangeMode. Each EFEM species declares a fixed EntityOfConcernChangeMode ∈ {preserve, retarget}. At the level of individual morphisms:

   • if entityOfConcernChangeMode(f) = preserve, then entityOfConcernRef(Y) = entityOfConcernRef(X) (and usually groundingHolonRef(Y) = groundingHolonRef(X) unless an explicit Grounding Bridge is declared);
   • if entityOfConcernChangeMode(f) = retarget, then entityOfConcernRef(Y) ≠ entityOfConcernRef(X) in general and the record names a KindBridge between the two EntityOfConcern values (A.6.4 / F.9).

4. SubjectRef source-migration discipline. For Description epistemes, including Description epistemes admitted for specification use (…Description / …Spec), subjectRef(E) is a DescriptionContext = ⟨EntityOfConcernRef, BoundedContextRef, ViewpointRef⟩ (E.10.D2). EFEM species state how source-migration subjectRef transforms in terms of these components (usually: preserve or explicitly adjust ViewpointRef while preserving EntityOfConcernRef and BoundedContextRef).

#P1 — Purity (no external effects)

EFEM morphisms are pure functions on epistemes:

• Applying f : X→Y does not:
  • change any U.System or U.Holon state;
  • execute Work (U.WorkEnactment) or run a U.Mechanism (A.6.1) with operational guards;
  • mutate U.PresentationCarrier (files, databases, message buses, IDEs).
• The only state change introduced by EFEM is the replacement of input epistemes by output epistemes according to apply(f, X) = Y, with all component changes governed by P2–P5.

Any operation that requires measurements, simulations, solver calls, or tool use with external side-effects is modelled as a U.Mechanism/U.Work that produces new epistemes, which may then be related by EFEM morphisms.

#P2 — Conservativity (no new EntityOfConcern commitments)

Let content_X = content(X), content_Y = content(Y), with associated referenceScheme_X, referenceScheme_Y, entityOfConcernRef_X, entityOfConcernRef_Y, groundingHolonRef_X, groundingHolonRef_Y. Interpret each content via its ReferenceScheme and slots. Then:

The set of claims about the EntityOfConcern values that can be interpreted from Y introduces no new atomic commitments beyond those that are logical consequences of the claims interpreted from X, possibly after applying a declared correspondence between representation/reference schemes.

Intuitively:

• EFEM may:

  • delete information (projection/abstraction);
  • normalise or re‑express information (e.g., reordering ClaimGraph, changing notation via a ReferenceScheme/RepresentationScheme correspondence);
  • add meta‑claims about the episteme itself (edition, source, status, witness entries).

• EFEM may not:

  • assert new atomic facts about the EntityOfConcern values or grounding holons beyond what is derivable from input ClaimGraphs under the declared ReferenceSchemes;
  • silently widen the scope of claims (e.g., treating local facts as global, changing Context or ReferencePlane without a Bridge).

Where entityOfConcernChangeMode(f) = retarget, conservativity is understood relative to a declared invariant of the KindBridge (A.6.4): e.g., conservation of energy for a Fourier transform, or preservation of functional behaviour for a structural reinterpretation.

#P3 — Functoriality (identity, composition, correspondence)

We work in the category Ep whose objects are epistemes (species of U.Episteme) and whose arrows are EFEM morphisms satisfying P0–P2, together with the functor

α : Ep → Ref

that maps each episteme to its EntityOfConcern reference (value of EntityOfConcernSlot, i.e. entityOfConcernRef(E)) as in the mathematical description used for epistemes. EFEM instances with entityOfConcernChangeMode(f) = preserve are vertical morphisms for α (α(f) = id), while those with entityOfConcernChangeMode(f) = retarget reindex along a declared KindBridge in Ref.

1. Identities. For each episteme X, there exists id_X : X→X such that:

   apply(id_X, X) = X
   compose(id_Y, f) = f = compose(f, id_X)

   id_X preserves all components (content, entityOfConcernRef, groundingHolonRef, viewpointRef, representationSchemeRef, referenceScheme, meta).

2. Composition. For f : X→Y, g : Y→Z, the composite h = compose(g,f) is an EFEM morphism X→Z with:

   apply(h, X) = apply(g, apply(f, X))
   entityOfConcernChangeMode(h) = combine(entityOfConcernChangeMode(f), entityOfConcernChangeMode(g))   // as per species-specific rules

and P0–P2 hold for h. For example, two preserve morphisms compose to preserve; preserve after retarget is retarget if the KindBridge composition exists.

3. Correspondence‑aware composition. When EFEM changes RepresentationScheme or ReferenceScheme, a CorrespondenceModel (as in C.2.1 §6 and E.17) may be needed to witness commutativity: composition respects these correspondences up to declared isomorphism/oplax naturality (witness epistemes may be recorded in meta).

#P4 — Idempotence & determinism (on fixed configuration)

For any EFEM morphism f : X→Y with fixed configuration (episteme kinds, EntityOfConcernChangeMode characteristic, KindBridge/CorrespondenceModel where needed):

1. Determinism. For the same input episteme X (identical content, slots, meta), apply(f, X) yields the same output episteme Y up to declared structural equivalence (normal forms, alpha‑renaming etc.). There is no dependence on ambient time, randomness, network state, or solver heuristics unless these are encoded as explicit inputs.

2. Idempotence (up to declared equivalence). Re‑applying the same EFEM to its own output yields no further essential change:

   apply(f, apply(f, X)) ≅ apply(f, X)

   where ≅ denotes the structural equivalence declared for the episteme kinds in question (e.g., ClaimGraph normalisation).

Species MAY weaken idempotence to “idempotent after normalisation”; if so, the normalisation step is itself specified as an EFEM morphism and the composite be idempotent.

#P5 — Applicability, scope & compatibility

Each EFEM species publishes an Applicability clause:

• EntityOfConcernClass / EntityOfConcern class. A constraint on the allowed ValueKind of EntityOfConcernSlot (via EntityOfConcernClass ⊑ U.Entity): e.g., “epistemes describing U.Holon that are systems of type X”.

• Grounding holon & Context. Constraints on GroundingHolonSlot and U.BoundedContext: where the morphism is valid (lab, runtime environment, organisational context).

• Representation/ReferenceSchemes. Enumerates admissible RepresentationScheme/ReferenceScheme pairs and any required CorrespondenceModels.

• Viewpoint discipline. For Description epistemes, including Description epistemes admitted for specification use, EFEM specifies which U.Viewpoints (E.17.0) are admissible and how it interacts with U.MultiViewDescribing families (e.g., “works only on engineering viewpoints from TEVB” or “viewpoint‑agnostic normalisation”).

Applying EFEM outside its Applicability (e.g., wrong EntityOfConcernClass, missing grounding holon, incompatible Viewpoint) is non‑conformant: a conformant implementation rejects such attempts or models them as different mechanisms/works, not as EFEM.

Cross‑Context or cross‑plane use (changing U.BoundedContext or ReferencePlane) is not part of EFEM; it is handled by Bridges (Part F) and A.6.1 transport, which then feed new epistemes into EFEM.

#Archetypal Grounding (Tell–Show–Show)

The examples below show how EFEM is intended to be used across the EntityOfConcern and Description-episteme boundary, specification-use refinements, and Viewpoint/MVPK publication lanes.

#Typed specification-use refinement SpecifyDescEpSpecDesc (species of EFEM)

Context. You have an informal U.MethodDescription for a safety check and want a more formal U.MethodSpec with test harness obligations, but about the same method.

Shape.

• Domain: X = U.MethodDescription episteme with entityOfConcernRef(X) : U.MethodRef, content(X) : U.ClaimGraph_D, viewpointRef(X) an engineering viewpoint (TEVB), ReferenceScheme_D.
• Codomain: Y = U.MethodSpec episteme with the same entityOfConcernRef(Y) = entityOfConcernRef(X), viewpointRef(Y) = viewpointRef(X), more structured content(Y) : U.ClaimGraph_S, more explicit ReferenceScheme (explicit pre/post, obligations).

Specify_DescEp_SpecDesc is a species of EFEM:

• entityOfConcernChangeMode(Specify_DescEp_SpecDesc) = preserve.
• P1 — effect‑free: it transforms epistemes only.
• P2 — conservative: any behavioural claims in the Spec must be logically entailed by the informal Description and the method that fills EntityOfConcernSlot; if the spec makes behavioural claims not entailed by that pair, that is modelled as creating a new EntityOfConcern claim with its own Description epistemes and specification use/refinement gates, not as a valid EFEM instance.
• P3–P5 — functorial and scoped: specs compose, applicability bound to the appropriate engineering context and Viewpoints.

This matches A.7 and E.10.D2: EntityOfConcern-to-Description (Describe_EoC_DescEp) is the strict-boundary describing step and is not itself an episteme→episteme morphism; Specify_DescEp_SpecDesc is an optional EFEM species over a Description episteme after a specification use/refinement gate is present. EFEM supplies the episteme→episteme laws for that refinement; it does not make Specification a third peer in A.7.

#Internal normalisation of a View (species of EFEM, entityOfConcernChangeMode = preserve)

Context. In MVPK you compute a engineering view V of a system description; you then normalise the view (sort, factor, put equations into normal form) without changing what it says.

Let X = V_raw, Y = V_norm, both U.EpistemeView instances with the same:

• entityOfConcernRef(X) = entityOfConcernRef(Y) (same system);
• groundingHolonRef(X) = groundingHolonRef(Y) (same environment);
• viewpointRef(X) = viewpointRef(Y) (same Viewpoint);
• representationSchemeRef(X) = representationSchemeRef(Y) (same notation).

The EFEM NormalizeView : X→Y:

• has entityOfConcernChangeMode(NormalizeView) = preserve;
• changes only content and maybe meta (e.g. “normalised at edition E”);
• is idempotent and deterministic (P4);
• is conservative (P2): no new claims, only re‑expression.

MVPK can then assume functoriality of such normalisations without re‑stating the EFEM laws.

#Retargeting sketch (bridge‑backed, entityOfConcernChangeMode = retarget)

Context. E.18 structural reinterpretation maps a physical layout view into a functional behaviour view, changing the EntityOfConcern from “physical module assembly” to “functional graph” along a KindBridge.

Inside EFEM, this becomes a species with entityOfConcernChangeMode = retarget:

• input episteme describes S₁ (e.g. a component hierarchy holon);
• output episteme describes S₂ (e.g. a functional network holon);
• a declared KindBridge(S₁,S₂) and invariant (e.g. behavioural equivalence) provide the semantic glue;
• P2 conservativity is checked w.r.t. that invariant.

The details belong to A.6.4 and E.18; EFEM provides the generic discipline.

#Worked SlotSpec example (engineering SystemDescription episteme kind)

(informative)

To make the SlotKind/ValueKind/RefKind discipline and EFEM laws concrete, consider a simple engineering U.EpistemeKind for system descriptions over EntityOfConcernClass ⊑ U.Entity with EntityOfConcernClass = U.System in a given Context. A minimal SlotSpec table for such a kind could be:

This table is an instance of A.6.5 U.RelationSlotDiscipline: each row is a SlotSpec triple ⟨SlotKind, ValueKind, refMode/RefKind⟩; no additional kernel types are introduced, and C.2.1’s constraints on EntityOfConcernSlot/GroundingHolonSlot are preserved.

Two typical EFEM species over this kind are:

• Specify_DescEp_SpecDesc_Sys : SystemDescription → SystemSpec — a EntityOfConcernChangeMode = preserve species that:

  • reads EntityOfConcernSlot, GroundingHolonSlot, ViewpointSlot, ReferenceSchemeSlot and writes a refined ClaimGraphSlot and possibly a strengthened ReferenceSchemeSlot;
  • satisfies P2 by only adding claims that are logical consequences of the original description plus the fixed EntityOfConcern (A.7 and E.10.D2);
  • satisfies CC‑C.2.1‑5 by explicitly declaring its slot profile and change mode.

• Normalize_EngView : EpistemeView → EpistemeView — a view‑normalisation EFEM (again with EntityOfConcernChangeMode = preserve) that:

  • reads all slots and writes only ClaimGraphSlot (normal form) and meta;
  • is idempotent and deterministic (P4) and pure (P1);
  • is conservative (P2) by construction: it never introduces new atoms about the selected system.

In later A.6.3/A.6.4/E.17.* patterns, concrete EpistemeKinds (for specific engineering description and specification-useification idioms) are expected to provide SlotSpecs of this general shape and to state explicitly, per CC‑C.2.1‑5 / CC‑EFEM.*, which slots their EFEM species read and write.

#Bias & Defaults (informative)

• Episteme‑first, world‑second. EFEM is strictly about epistemes as objects; any world contact (measurements, executions) lives in U.Mechanism/U.Work and produces new epistemes that EFEM may subsequently relate.

• SlotKinds, not “fields”. Laws talk about EntityOfConcernSlot, GroundingHolonSlot, etc., and their ValueKind/RefKind, as per A.6.5 and C.2.1; they never use unnamed tuple positions or “unnamed slot positions”. This keeps EFEM aligned with the slot discipline used for methods, roles, services, and other n‑ary relations.

• Local‑first semantics. EFEM is Context‑local; crossings of Context or ReferencePlane are always delegated to Bridges / A.6.1 transport (with CL penalties to R/R_eff only). No “implicit cross‑Context EFEM” is permitted.

• EntityOfConcern and Description-episteme boundary and specification-use/refinement respect. EFEM never collapses EntityOfConcern with Description epistemes or with specification-use refinements: EntityOfConcern-to-Description and optional specification-use refinement operations are typed explicitly. The former remains the A.7 describing boundary; the latter is an EFEM species only when it is an episteme→episteme refinement admitted by an exact specification use/refinement gate.

#Conformance Checklist (normative)

#SoTA‑Echoing (informative, lineage)

EFEM is intentionally “thin”: it provides a minimal categorical and slot‑based discipline for episteme→episteme morphisms, making it easy to align with several post‑2015 lines of work:

• Categorical semantics & displayed categories. Treating Ep as a category over Ref via a functor α : Ep → Ref (mapping each episteme to its EntityOfConcern) matches the displayed categories view on fibrations: EFEM arrows are those morphisms in Ep that are “vertical” (preserve α) or “structured reindexings” (retarget under a KindBridge). This is exactly the intended alignment with C.2.1’s subjectRef/ReferencePlane picture.

• Optics as universal projections. Viewing operations (U.EpistemicViewing) refine EFEM in a way analogous to lenses/prisms/traversals in the optics literature: effect‑free, compositional accessors for parts of a larger structure. EFEM captures the laws that underlie those projections (purity, conservation, functoriality); optics‑style constructions can then be used inside discipline packs without modifying the core.

• Structured cospans & correspondences. Many correspondence‑based multi‑view patterns (ISO 42010 correspondences, model synchronisation, traceability links) can be seen as spans/cospans between epistemes. EFEM ensures that the legs of such cospans are effect‑free and conservative, while CorrespondenceModels carry the extra structure needed for consistency management.

• Bidirectional transformations (BX). The “no new commitments” and “functorial & idempotent” constraints mirror modern BX practice around consistency restoration: EFEM is the universal core that BX‑like constructions (view updates, synchronisers) must respect when instantiated for epistemes.

EFEM does not prescribe a specific calculus (deductive, probabilistic, latent‑space), nor a specific representation (symbolic vs distributed); those choices are captured in U.ClaimGraph, U.RepresentationScheme and discipline‑level patterns. EFEM only says what it means to transform epistemes legally in that chosen substrate.

#Consequences

• Single place for episteme‑to‑episteme laws. All effect-free transforms of knowledge epistemes, across KD‑CAL, MVPK, E.18, discipline packs, can now be defined as species of EFEM, instead of each family re‑inventing its own law set.

• Clear separation from mechanisms & work. Anything that touches the world (measurements, execution, simulation) is forced into U.Mechanism / U.WorkEnactment, with CL‑penalised Bridges and Γ_time; EFEM remains pure and compositional.

• Stable backbone for Viewing & Retargeting. A.6.3 and A.6.4 do not need to repeat P0–P5; they specialise EFEM with additional constraints (preserve/retarget). Other patterns (e.g. MultiViewDescribing, MVPK, E.18 structural reinterpretation) can depend on EFEM as a stable base.

• Slot‑level clarity. By formulating EFEM laws in terms of SlotKinds/ValueKinds/RefKinds (A.6.5) and the EpistemeSlotRelation (C.2.1), it becomes much harder for Episteme to confuse “EntityOfConcern”, “slot in a relation”, and “reference to that entity”.

• Better didactics. The old “semantic triangle” becomes a didactic projection of EFEM over the EpistemeSlotRelation: EFEM + C.2.1 explain precisely what the triangle was trying to gesture at (symbol, concept, referent), while correctly foregrounding operations, viewpoints, grounding holons, and reference schemes.

#Rationale

Why a separate EFEM pattern (A.6.2) instead of folding into A.6.1 or C.2.1?

• A.6.1 governs Mechanisms (operations with AdmissibilityConditions, Γ_time, transport and Bridges)—too operational for the pure episteme transforms we want here.
• C.2.1 fixes the ontology of epistemes (slots, components, ReferencePlane), but does not talk about morphisms. EFEM is explicitly a morphism‑level pattern over that ontology.

This split mirrors how Signature (A.6.0) separates “what is declared” from “how it is realised”: C.2.1 says what an episteme is; A.6.2 says what an admissible episteme-to-episteme transform is.

Why insist on EntityOfConcernChangeMode?

Because almost all subtle errors in multi‑view reasoning show up as silent retargeting: a transform that appears to keep the same EntityOfConcern actually changes it (e.g., from “component assembly” to “function bundle”) without naming the bridge or invariant. By forcing every species to declare preserve vs retarget, EFEM makes those decisions explicit and reviewable.

Why attach EFEM to SlotKinds instead of informal “fields”?

FPF already committed to a single SlotKind/ValueKind/RefKind discipline (A.6.5) across relations, methods, roles, and now epistemes. Re‑using that discipline here:

• aligns episteme morphisms with the rest of the framework;
• enables later mechanised checks (e.g., that a viewing only touches slots it promised to touch);
• avoids minting yet another notion of “parameter” or “role in a relation”.

#Relations

• Specialises / is specialised by.

  • Builds on A.6.0 U.Signature and A.6.1 U.Mechanism for the uniform SubjectBlock/vocabulary/laws/applicability structure.
  • Specialised by A.6.3 U.EpistemicViewing (entityOfConcern‑preserving EFEM) and A.6.4 U.EpistemicRetargeting (entityOfConcern-retargeting EFEM).

• Constrained by. A.6.5 U.RelationSlotDiscipline (SlotKind/ValueKind/RefKind); C.2.1 U.EpistemeSlotRelation (episteme components, ReferencePlane); E.10.D2 (EntityOfConcern and Description-episteme boundary and specification use/refinement gates); Part F (Bridges, CL, ReferencePlane crossings); E.10 (LEX‑BUNDLE naming rules, especially on …Slot / …Ref and ban on Subject/Object in episteme tech names).

• Consumed by. E.17.0 U.MultiViewDescribing (families of Description epistemes, including Description epistemes admitted for specification use, under Viewpoints); E.17 (MVPK — publication as species of Viewing/EFEM); E.18 (structural reinterpretation and other transformation-flow relations over epistemes); KD‑CAL/LOG‑CAL rules that reason about episteme transforms categorically.

#A.6.2:End

Last Updated: 2026-06-14 — this section last modified in upstream FPF commit 7c617d5d (github.com/ailev/FPF)