#U.EffectFreeEpistemicMorphing — Effect-Free Morphisms of Epistemes

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

One‑line summary. U.EffectFreeEpistemicMorphing (EFEM) is the universal class of effect‑free, law‑governed morphisms between epistemes. An EFEM morphism rewrites episteme components (ClaimGraph, describedEntityRef, 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 DescribedEntitySlot (DescribedEntityChangeMode ∈ {preserve, retarget}) as defined by C.2.1 U.EpistemeSlotGraph.

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 graph; E.10.D2 (I/D/S discipline); C.3.* (Kind‑CAL / KindBridge for described‑entity classes).

Used by. A.6.3 U.EpistemicViewing; A.6.4 U.EpistemicRetargeting; E.17.0 U.MultiViewDescribing; E.17 (MVPK); E.18 (E.TGA StructuralReinterpretation, Transduction graph).

FPF has many operations that transform knowledge artifacts without directly doing work in the world:

#Keywords

• episteme
• effect-free
• morphism
• functoriality
• describedEntity
• lenses
• reproducibility.

#Relations

#Content

#Problem frame

FPF has many operations that transform knowledge artifacts 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.TGA, MVPK, discipline packs) reinvent their own notion of “projection”, “reinterpretation”, or “refinement”;
• laws about what may change in an episteme (content vs described entity vs grounding holon vs reference plane) fragment across the spec;
• cross‑family reasoning (e.g. “this E.TGA StructuralReinterpretation 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 presentation surfaces), but the laws for “episteme‑only” operations are scattered or implicit.

2. Described entity 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 DescribedEntityChangeMode discipline we get silent breaks in “describedEntity”: an operation that looks like a harmless format change may in fact surreptitiously change the entity‑of‑interest.

3. No functorial backbone. MVPK, KD‑CAL and E.TGA 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.EpistemeSlotGraph 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 describedEntity 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 describedEntity‑preserving; reinterpretation along a KindBridge is describedEntity‑retargenting. Both are important, but they must be distinguished and witnessed differently.

• Conservativity vs usefulness. EFEM should be conservative: no new intensional commitments beyond what input epistemes already entail. At the same time, we need transformations that can factor, aggregate, or normalise content, which may drop some information or change its representation.

• 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.

• I/D/S strict distinction. Intension (I) is not itself an episteme; …Description and …Spec are epistemes with a DescriptionContext = ⟨DescribedEntityRef, BoundedContextRef, ViewpointRef⟩. EFEM must support operations on D/S epistemes while keeping the I/D/S layering intact (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.EpistemeSlotGraph (ClaimGraph, slots for described entity, grounding holon, viewpoint, representation/reference schemes, meta);
• are effect‑free (no Work, no Mechanism application, no mutation of systems or carriers);
• are conservative in what they claim about the described entity (no new intensional commitments beyond logical consequences under the declared ReferenceScheme);
• are functorial (identities and composition behave as expected on the category of epistemes);
• declare an explicit DescribedEntityChangeMode ∈ {preserve, retarget}, controlling how DescribedEntitySlot (and associated subjectRef) behaves.

The 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 DescribedEntityChangeMode = preserve.
• U.EpistemicRetargeting (A.6.4) — EFEM with DescribedEntityChangeMode = 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⟩        // carrier 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 (subject reference; for D/S epistemes this is DescriptionContext = ⟨DescribedEntityRef, BoundedContextRef, ViewpointRef⟩ per IDS‑13 (DescriptionContext discipline; C.2.1 §6.1 / E.10.D2)).
  • U.Morphism (arrow in Ep).
  • U.DescribedEntityChangeMode = {preserve, retarget} (enumeration; no new Kernel type for “DescribedEntity”).

• 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.
  • describedEntityChangeMode(f) : U.DescribedEntityChangeMode // 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 (DescribedEntitySlot, 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 normative: any morphism advertised as an instance of U.EffectFreeEpistemicMorphing SHALL satisfy them.

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

For any EFEM morphism f : X→Y:

1. Typed objects. 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 DescribedEntitySlot, 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);
   • describedEntityRef(E) : U.EntityRef — value of the RefKind for DescribedEntitySlot;
   • 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 DescribedEntityChangeMode. Each EFEM species declares a fixed DescribedEntityChangeMode ∈ {preserve, retarget}. At the level of individual morphisms:

   • if describedEntityChangeMode(f) = preserve, then describedEntityRef(Y) = describedEntityRef(X) (and usually groundingHolonRef(Y) = groundingHolonRef(X) unless an explicit Grounding Bridge is declared);
   • if describedEntityChangeMode(f) = retarget, then describedEntityRef(Y) ≠ describedEntityRef(X) in general and a KindBridge between the two described entities MUST be named (A.6.4 / F.9).

4. SubjectRef compatibility. For D/S epistemes (…Description / …Spec), subjectRef(E) is a DescriptionContext = ⟨DescribedEntityRef, BoundedContextRef, ViewpointRef⟩ (E.10.D2). EFEM species SHALL state how subjectRef transforms in terms of these components (usually: preserve or explicitly adjust ViewpointRef while preserving DescribedEntityRef 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 SHALL be modelled as a U.Mechanism/U.Work that produces new epistemes, which may then be related by EFEM morphisms.

#P2 — Conservativity (no new intensional commitments)

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

The set of claims about the described entities that can be read from Y SHALL NOT introduce new atomic commitments beyond those that are logical consequences of the claims read 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 described entities 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 describedEntityChangeMode(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 the object it describes (value of DescribedEntitySlot, i.e. describedEntityRef(E)) as in the mathematical layer for epistemes. EFEM instances with describedEntityChangeMode(f) = preserve are vertical morphisms for α (α(f) = id), while those with describedEntityChangeMode(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, describedEntityRef, 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))
   describedEntityChangeMode(h) = combine(describedEntityChangeMode(f), describedEntityChangeMode(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 MUST respect 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, DescribedEntityChangeMode 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 MUST itself be specified as an EFEM morphism and the composite be idempotent.

#P5 — Applicability, scope & compatibility

Each EFEM species publishes an Applicability clause:

• EoI / described entity class. A constraint on the allowed ValueKind of DescribedEntitySlot (via EoIClass ⊑ 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 supported RepresentationScheme/ReferenceScheme pairs and any required CorrespondenceModels.

• Viewpoint discipline. For Descr/Spec epistemes, EFEM SHALL specify which U.Viewpoints (E.17.0) it supports 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 EoIClass, missing grounding holon, incompatible Viewpoint) is non‑conformant: a conformant implementation MUST reject such attempts or model 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 I/D/S and Viewpoint/MVPK layers.

#Typed formalisation Specify_DS : D→S (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 describedEntityRef(X) : U.MethodRef, content(X) : U.ClaimGraph_D, viewpointRef(X) an engineering viewpoint (TEVB), ReferenceScheme_D.
• Codomain: Y = U.MethodSpec episteme with the same describedEntityRef(Y) = describedEntityRef(X), viewpointRef(Y) = viewpointRef(X), more structured content(Y) : U.ClaimGraph_S, stronger ReferenceScheme (explicit pre/post, obligations).

Specify_DS is a species of EFEM:

• describedEntityChangeMode(Specify_DS) = 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 underlying Method Intension; if the spec makes stronger claims, that is modelled as creating a new Intension with its own D/S pair, 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/E.10.D2 strict distinction: I→D (Describe_ID) is not itself an episteme→episteme morphism, but Specify_DS is; EFEM supplies its laws.

#Internal normalisation of a View (species of EFEM, describedEntityChangeMode = 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:

• describedEntityRef(X) = describedEntityRef(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 describedEntityChangeMode(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, describedEntityChangeMode = retarget)

Context. E.TGA’s StructuralReinterpretation maps a physical layout view into a functional behaviour view, changing the described entity from “physical module assembly” to “functional graph” along a KindBridge.

Inside EFEM, this becomes a species with describedEntityChangeMode = 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/E.TGA; 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 EoIClass ⊑ U.Entity with EoIClass = 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 DescribedEntitySlot/GroundingHolonSlot are preserved.

Two typical EFEM species over this kind are:

• Specify_DS_Sys : SystemDescription → SystemSpec — a DescribedEntityChangeMode = preserve species that:

  • reads DescribedEntitySlot, 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 Intension (A.7/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 DescribedEntityChangeMode = 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 described system.

In later A.6.3/A.6.4/E.17.* patterns, concrete EpistemeKinds (for specific engineering description/specification 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 DescribedEntitySlot, GroundingHolonSlot, etc., and their ValueKind/RefKind, as per A.6.5 and C.2.1; they never use unnamed tuple positions or “role 1/2/3”. 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.

• I/D/S respect. EFEM never collapses Intension with Description/Spec: I→D and D→S operations are typed explicitly and either (i) conform to EFEM laws where they are episteme→episteme, or (ii) remain separate morphism classes (A.7) while being described as EFEM‑conformant.

#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 described entity) 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 artefacts, across KD‑CAL, MVPK, E.TGA, 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.TGA StructuralReinterpretation) 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 EpistemeSlotGraph (C.2.1), it becomes much harder for Episteme to confuse “object of talk”, “slot in a relation”, and “reference to that object”.

• Better didactics. The old “semantic triangle” becomes a didactic projection of EFEM over the EpistemeSlotGraph: EFEM + C.2.1 explain precisely what the triangle was trying to gesture at (symbol, concept, object), 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 a legal episteme→episteme transform is.

Why insist on DescribedEntityChangeMode?

Because almost all subtle errors in multi‑view reasoning show up as silent retargeting: a transform that appears to keep the same object‑of‑talk 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 (describedEntity‑preserving EFEM) and A.6.4 U.EpistemicRetargeting (describedEntity‑retargering EFEM).

• Constrained by. A.6.5 U.RelationSlotDiscipline (SlotKind/ValueKind/RefKind); C.2.1 U.EpistemeSlotGraph (episteme components, ReferencePlane); E.10.D2 (I/D/S discipline); 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 D/S epistemes under Viewpoints); E.17 (MVPK — publication as species of Viewing/EFEM); E.18 (E.TGA StructuralReinterpretation and other transductions over epistemes); KD‑CAL/LOG‑CAL rules that reason about episteme transforms categorically.

#A.6.2:End