#U.EpistemicRetargeting — describedEntity-Retargeting Morphism

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

One‑line summary. U.EpistemicRetargeting is the describedEntity‑retargetning species of U.EffectFreeEpistemicMorphing: an effect‑free episteme→episteme morphism that intentionally changes what the episteme is about (the occupant of DescribedEntitySlot in C.2.1) under a declared KindBridge and invariant, while remaining conservative with respect to that invariant.

Placement. After A.6.3 U.EpistemicViewing, before A.6.5 U.RelationSlotDiscipline.

Builds on. A.6.0 U.Signature; A.6.2 U.EffectFreeEpistemicMorphing; A.6.3 U.EpistemicViewing; A.6.5 U.RelationSlotDiscipline; A.7/E.10.D2 (I/D/S discipline, DescriptionContext); C.2.1 U.Episteme — Epistemes and their slot graph; C.2/C.3 (KD‑CAL/LOG‑CAL, ReferencePlane, Kind‑level reasoning); F.9 (Bridges, KindBridge, CL/CL^plane, SquareLaw witnesses).

Used by. E.18 (E.TGA StructuralReinterpretation and other reinterpretation nodes); discipline packs for signal/spectrum transforms, data↔model retargetings, abstraction/refinement under kind‑invariants; KD‑CAL/LOG‑CAL retargeting rules; future species for architecture and governance reinterpretations.

Many important operations on descriptions change the object‑of‑talk while preserving a structural or behavioural invariant:

#Keywords

• retargeting
• subject retargeting
• describedEntity shift
• KindBridge
• SquareLaw-retargeting
• StructuralReinterpretation.

#Relations

#Content

#Problem frame

Many important operations on descriptions change the object‑of‑talk while preserving a structural or behavioural invariant:

• Physical vs functional reinterpretation. An episteme about a physical module (cabinet, rack, device) is re‑interpreted as an episteme about a function‑holon it realises. This is precisely what StructuralReinterpretation nodes in E.TGA attempt to do.

• Signal vs spectrum. A time‑domain signal description is re‑targeted to a description of its frequency‑domain spectrum. The underlying invariant (typically energy or inner‑product) is preserved, but the “thing we talk about” changes from time→value trajectories to frequency→amplitude/phase distributions.

• Data vs model. An episteme about raw observations (dataset) is turned into an episteme about a learned or estimated model, keeping an invariant such as likelihood, sufficient statistics, or predictive performance.

All of these are Ep→Ep transforms that:

• do not change the Intension (I) directly (they operate on descriptions/specifications),
• do not merely slice or re‑express an episteme of the same entity (that would be EpistemicViewing, A.6.3),
• but do change the DescribedEntity‑bundle (DescribedEntitySlot and usually GroundingHolonSlot) under a formal bridge between kinds.

We need a single, reusable notion of “epistemic retargeting” that captures these operations as:

• effect‑free at the level of Work/Mechanism (EFEM discipline),
• describedEntity‑retargeotating in a controlled way,
• invariant‑conservative (no violation of the declared invariant between kinds),
• and functorial (retargetings compose cleanly and align with Bridges).

#Problem

Without a dedicated pattern for EpistemicRetargeting:

1. Retargeting is silently confused with viewing. Structural reinterpretations (e.g., component→function, signal→spectrum, data→model) can be mistakenly treated as “just another view” of the same entity, even though they change describedEntityRef. This hides the fact that the object‑of‑talk has changed and that a KindBridge and invariant are required.

2. Invariants float untyped. Fourier‑style moves, structural reinterpretations, and abstraction/refinement steps are often justified by “energy is preserved”, “this component realises that function”, or “this model summarises those data” — but these invariants are not connected to the episteme morphism class. Without a dedicated species:

   • invariants live only in text,
   • CL‑penalties and ReferencePlane crossings cannot be tracked systematically (Part F).

3. Cross‑kind reasoning has no canonical morphism. A general EFEM (A.6.2) can change describedEntityRef by setting describedEntityChangeMode = retarget, but:

   • nothing states what that means at the level of kinds (Kind(describedEntityRef(X)) vs Kind(describedEntityRef(Y))),
   • nothing connects these moves to KindBridge and ReferencePlane policies.

4. StructuralReinterpretation is ad‑hoc. E.TGA currently hosts StructuralReinterpretation as a special node, but its semantics are much closer to a generic “retargeting under a bridge” pattern than to something specific to graph‑based architectures. Without a core pattern:

   • StructuralReinterpretation risks duplicating retargeting logic,
   • other discipline packs may reinvent their own ad‑hoc re‑targetings.

5. I/D/S discipline is left underspecified. For descriptions/specifications (…Description / …Spec), retargeting changes DescribedEntityRef in DescriptionContext = ⟨DescribedEntityRef, BoundedContextRef, ViewpointRef⟩ (E.10.D2), but must say what happens to context and viewpoint. Without an explicit pattern, these decisions get scattered across different E‑patterns instead of being governed centrally.

#Forces

• Changing the object‑of‑talk vs constructing something new. Retargeting should express “talking about a different but bridge‑related entity”, not arbitrary construction of a new Intension/episteme. The invariant lives across the pair of entities, not inside a single episteme.

• Invariants may be lossy but must be explicit. A retargeting is often lossy (e.g. data→model, signal→spectrum, structural→functional view), but:

  • it must preserve an explicitly declared invariant (energy, behaviour, statistics),
  • any additional strengthening must be modelled as a change of Intension plus new D/S, not as a hidden side‑effect.

• Bridges and CL‑penalties. Retargeting often crosses:

  • Kind‑planes (different Kind(U.Entity)),
  • ReferencePlanes (different observability or abstraction regimes). Part F already has KindBridge, plane Bridges and CL‑penalties; EpistemicRetargeting must re‑use them instead of introducing its own notion of “link”.

• Functors over α : Ep → Ref. In the fibred view of epistemes (C.2 / A.6.2), α : Ep → Ref maps each episteme to its described entity. EpistemicViewing preserves α (α(v) = id). Retargeting must:

  • change α in a controlled way (α(r) = b : R₁→R₂ in Ref),
  • align with KindBridge and plane Bridges used for those base arrows.

• Slot discipline and modularity. C.2.1 and A.6.5 give epistemes a precise SlotKind/ValueKind/RefKind structure, including DescribedEntitySlot and GroundingHolonSlot. Retargeting laws must be stated at the slot level, not on ad‑hoc “fields”, so they can be reused across E.TGA, MVPK, and discipline packs.

#Solution — U.EpistemicRetargeting as EFEM profile (describedEntityChangeMode = retarget)

#Informal definition

Definition (informal). U.EpistemicRetargeting is the describedEntity‑retargeting species of U.EffectFreeEpistemicMorphing. A U.EpistemicRetargeting r : X→Y:

• takes an input episteme X and produces an output episteme Y,
• changes the occupant of DescribedEntitySlot (describedEntityRef(Y) ≠ describedEntityRef(X)),
• relates the kinds of the old and new described entities via an explicit KindBridge in the appropriate ReferencePlane,
• preserves a declared invariant across the pair of entities (e.g. energy, behaviour, sufficient statistics),
• is effect‑free at the level of Work/Mechanism (EFEM discipline),
• and composes functorially with other retargetings and viewings.

In C.2.1 terms, U.EpistemicRetargeting re‑indexes an episteme along a base‑level bridge: it moves the DescribedEntitySlot (and often the <DescribedEntitySlot, GroundingHolonSlot> bundle) along a KindBridge, while re‑expressing content : U.ClaimGraph and referenceScheme so that the declared invariant continues to hold at the new target.

#Signature (A.6.0 / A.6.5 alignment)

Signature header. U.EpistemicRetargeting is a Morphism‑kind under A.6.0, specialised from EFEM:

SubjectBlock
  SubjectKind    = U.EpistemicRetargeting
  BaseType       = ⟨X:U.Episteme, Y:U.Episteme⟩      // carrier pair
  Quantification = SliceSet := U.ContextSliceSet;
                   ExtentRule := admissible retargeting morphisms
  ResultKind     = U.Morphism                        // an instance r

Vocabulary (re‑uses A.6.2).

• Types. U.Episteme, U.SubjectRef, U.Morphism, U.EpistemicRetargeting.

• Operators.

  • id : U.Morphism(X→X)
  • compose(g,f) : U.Morphism(X→Z) where f:X→Y, g:Y→Z
  • apply(r, x:U.Episteme) : U.Episteme
  • dom(r), cod(r) : U.Episteme
  • subjectRef(-) : U.SubjectRef

• Slot‑level discipline. Domain and codomain epistemes are instances of some U.Episteme species (typically U.EpistemeCard, U.EpistemeView, or U.EpistemePublication) whose episteme kinds each provide SlotSpecs (A.6.5) including at least:

  • DescribedEntitySlot (ValueKind U.Entity, RefKind U.EntityRef, usually restricted to an EoIClass ⊑ U.Entity),
  • GroundingHolonSlot? (ValueKind U.Holon, RefKind U.HolonRef),
  • ClaimGraphSlot (ValueKind U.ClaimGraph, by‑value),
  • ViewpointSlot? (ValueKind U.Viewpoint, RefKind U.ViewpointRef),
  • ReferenceSchemeSlot (ValueKind U.ReferenceScheme, by‑value),
  • and, where C.2.1+ is in use, RepresentationSchemeSlot, ViewSlot and related slots.

The pattern only requires SlotSpec compatibility between domain and codomain kinds (in the sense of A.6.5); they need not be literally the same kind.

Relation to EFEM and Viewing.

• Every U.EpistemicRetargeting is an EFEM morphism with describedEntityChangeMode = retarget in the sense of A.6.2/C.2.1.
• It inherits EFEM laws P0–P5 and adds retargeting‑specific obligations ER‑0…ER‑6 below.
• U.EpistemicViewing (A.6.3) covers the complementary case describedEntityChangeMode = preserve, where the object‑of‑talk does not change.

#Laws (ER‑0…ER‑6, over C.2.1 components)

All laws below are in addition to A.6.2’s EFEM laws P0–P5 and SHALL be read directly against C.2.1 components and A.6.5 SlotSpecs.

ER‑0 - Species & DescribedEntityChangeMode.

• Any morphism r:X→Y declared as U.EpistemicRetargeting MUST:
  • be a species of U.EffectFreeEpistemicMorphing (A.6.2), and
  • declare describedEntityChangeMode(r) = retarget.
• Consequently:
• the pair <DescribedEntitySlot, GroundingHolonSlot> is the target bundle for the change (as in C.2.1 §7.3: DescribedEntity‑bundle retargeting),
• DescribedEntitySlot is write‑enabled (unlike Viewing) but only under the constraints below,
• there exist entities T₁, T₂ : U.Entity such that:
  • describedEntityRef(X) = T₁,
  • describedEntityRef(Y) = T₂,
  • T₁ ≠ T₂ (as Ref/identity), and
  • Kind(T₁) and Kind(T₂) are related by a KindBridge in Part F’s sense (with declared CL^k).

ER‑1 - Typed domain/codomain & DescribedEntity‑bundle behaviour.

For any r:X→Y in U.EpistemicRetargeting:

1. X and Y are instances of U.Episteme species whose episteme kinds both realise at least the core C.2.1 slots (DescribedEntitySlot, GroundingHolonSlot?, ClaimGraphSlot, ViewpointSlot?, ReferenceSchemeSlot) and obey A.6.5.

2. At the SlotKind level:

   • DescribedEntitySlot:

     • MUST change (describedEntityRef(Y) ≠ describedEntityRef(X)),
     • the ValueKinds for the slot in the domain and codomain kinds MUST be related via an EoIClass pair that the KindBridge covers (e.g. PhysicalModule ↔ FunctionHolon, Signal ↔ Spectrum, Dataset ↔ StatisticalModel).

   • GroundingHolonSlot, if present:

     • is either preserved exactly (groundingHolonRef(Y) = groundingHolonRef(X)), or
     • changed only along a declared holon‑Bridge in the same ReferencePlane (for example, moving from one runtime to another under a deployment bridge) with CL^plane penalties recorded in Part F.

   • ViewpointSlot, if present:

     • is either preserved, or
     • changed only within a declared U.ViewpointBundle (E.17.1/E.17.2), with the corresponding CorrespondenceModel explaining how the invariant is maintained under the new viewpoint.

3. For any episteme that is a …Description/…Spec (E.10.D2), subjectRef decodes to DescriptionContext = ⟨DescribedEntityRef, BoundedContextRef, ViewpointRef⟩. Under EpistemicRetargeting:

   • DescribedEntityRef MUST change from T₁ to T₂ as in ER‑0,
   • BoundedContextRef is:
     • either preserved, or
     • changed along an explicit Context‑Bridge (E.10.D1, Part F),
   • ViewpointRef is treated as in (2) above (preserved or mapped within a bundle), and any resulting change in admissible claims is governed by ER‑2.

The pair <DescribedEntitySlot, GroundingHolonSlot> is treated as a target bundle: many practical retargetings work at the level of this bundle rather than DescribedEntity alone, especially in E.TGA.

ER‑2 - Invariant‑based conservativity (lossy but lawful).

Let X and Y = apply(r,X) with:

• describedEntityRef(X) = T₁, describedEntityRef(Y) = T₂,
• KindBridge(T₁,T₂) and associated invariant Inv declared for this species (e.g. energy, behavioural relation, likelihood),
• content_X, referenceScheme_X,
• content_Y, referenceScheme_Y,
• groundingHolonRef_X, groundingHolonRef_Y.

Then:

1. There MUST exist a KD‑CAL/LOG‑CAL expression of Inv such that:

   • all claims about Inv that can be derived by reading content_Y through referenceScheme_Y relative to <T₂, groundingHolonRef_Y> are entailed by claims about Inv derivable from content_X through referenceScheme_X relative to <T₁, groundingHolonRef_X>.

2. Retargeting, as an EFEM instance, may:

   • discard information not needed to maintain Inv (lossy summarisation),
   • change representation schemes (e.g. time vs frequency domain),
   • move to different abstraction levels or ReferencePlanes (with Bridges and CL penalties declared), but MUST NOT violate the declared invariant.

3. Any intended change that strengthens commitments about Inv beyond what is derivable from X is not a valid EpistemicRetargeting. It must be modelled as:

   • a change of Intension (new D/S pair under A.7/E.10.D2), or
   • a chain of retargetings and Intension updates explicitly recorded in KD‑CAL/LOG‑CAL.

ER‑3 - Functoriality, α‑reindexing & SquareLaw witnesses.

EpistemicRetargeting inherits EFEM functoriality and specialises it to the retargeting case:

1. At the Ep level:

   • apply(id, X) = X (no retargeting),
   • apply(r₂ ∘ r₁, X) = apply(r₂, apply(r₁, X)) whenever domains/codomains match,
   • the composite r₂∘r₁ has describedEntityRef(X) = T₁ and describedEntityRef(cod(r₂∘r₁)) = T₃, with a composed KindBridge(T₁,T₃) whenever the Bridges of r₁ and r₂ compose.

2. At the Ref level, under α : Ep → Ref:

   • each retargeting r induces a base arrow α(r) : R₁→R₂ in Ref, compatible with the KindBridge used in ER‑0,
   • the square formed by:
     • X→Y in Ep (retargeting),
     • α(X)→α(Y) in Ref (base retargeting),
     • any measurement or evaluation morphisms on either side, MUST commute up to a declared SquareLaw‑retargeting witness (Part F / E.TGA), documenting that evaluating then retargeting vs retargeting then evaluating yields equivalent results (modulo CL‑penalties).

3. When retargetings use CorrespondenceModels between epistemes (e.g. aligning detailed hardware layouts with function networks), they MUST:

   • reference the CorrespondenceModel explicitly,
   • publish witness epistemes that certify commutativity of key squares, analogous to EV‑4 but now across different described entities.

ER‑4 - Idempotency & determinism on fixed Bridge/invariant.

For any r:X→Y in U.EpistemicRetargeting, with fixed:

• KindBridge(T₁,T₂) and ReferencePlane policies,
• invariant Inv,
• configuration (ContextSlice, representation families, CorrespondenceModels),

the following MUST hold:

• Idempotency. Applying r twice does not further change the described entity or invariant‑relevant content:

  • apply(r, apply(r, X)) is isomorphic (in the EFEM sense) to apply(r, X),
  • describedEntityRef is already T₂ after the first application,
  • content and referenceScheme differ at most by declared structural equivalence (e.g. normal forms at the new target).

• Determinism. For fixed input X and fixed Bridge/invariant configuration, the result is uniquely determined modulo declared equivalence. Any source of non‑determinism (randomness, time, external service state) MUST either:

  • be made explicit as part of content/meta of X, or
  • be moved to a U.Mechanism outside the retargeting morphism.

ER‑5 - Applicability, EoI‑pairs & CL‑discipline.

Each species of U.EpistemicRetargeting MUST declare an Applicability profile (A.6.0) that includes:

1. EoI‑pairs. Admissible pairs of EoIClasses (ValueKinds of DescribedEntitySlot for domain and codomain), for example:

   • (PhysicalModule, FunctionHolon),
   • (Signal, Spectrum),
   • (Dataset, StatisticalModel).

   For each such pair, the pattern MUST reference the appropriate KindBridge species in Part F.

2. Grounding constraints. Permitted classes of groundingHolonRef and ReferencePlanes, including whether:

   • grounding must stay within the same holon,
   • or may move along specific holon Bridges with CL^plane penalties.

3. Viewpoint/context constraints. Whether retargeting is allowed for all viewpoints or only for specific U.ViewpointBundles (TEVB etc.), and any requirements on BoundedContextRef.

4. CL‑discipline. Minimum CL^k and CL^plane required for the Bridges used, aligning with F.9 and E.TGA’s StructuralReinterpretation rules.

Any attempt to apply a retargeting outside this Applicability profile is ill‑typed.

ER‑6 - Compatibility with Viewing and Mechanisms.

1. Separation from Viewing.

   • Any morphism that does not change describedEntityRef (and keeps DescribedEntityChangeMode = preserve) belongs to A.6.3 U.EpistemicViewing, not to U.EpistemicRetargeting.
   • Any morphism that does change describedEntityRef MUST NOT be declared as U.EpistemicViewing; it is either:
     • a U.EpistemicRetargeting, or
     • a more general pattern that composes several retargetings and Intension changes.

   In any composite V∘r or r∘V, describedEntity changes are localised to retargeting steps; Viewing steps are always describedEntityChangeMode = preserve.

2. Separation from Mechanisms.

   • Retargeting MAY depend on artefacts produced by U.Mechanism (e.g., computing a Fourier transform, fitting a model), but those are separate Work/Mechanism steps.
   • U.EpistemicRetargeting itself remains effect‑free: it rearranges epistemes, slots and ClaimGraphs, but does not perform measurements or actuation.

#Archetypal grounding (Tell–Show–Show)

Tell. EpistemicRetargeting captures “same invariant, different described entity” moves:

• we stop talking about “this cabinet” and start talking about “the routing function it realises”;
• we stop talking about “this signal over time” and start talking about “its spectrum over frequency”;
• we stop talking about “this dataset” and start talking about “a model class with parameters θ learned from it”.

In each case, what remains stable is an invariant (behaviour, energy, likelihood), not the described entity itself.

Show 1 — StructuralReinterpretation in E.TGA.

• X describes a physical module holon S_phys.
• Y describes a function holon S_func.
• A KindBridge(S_phys, S_func) expresses “this module realises that function”.
• A StructuralReinterpretation node in E.TGA is an instance of U.EpistemicRetargeting whose invariant is the behaviour relation between S_phys and S_func.

Show 2 — Signal↔Spectrum.

• X describes a time‑domain signal s(t); DescribedEntityRef(X) = S_time.
• Y describes its spectrum S(ω); DescribedEntityRef(Y) = S_freq.
• KindBridge(S_time, S_freq) encodes Fourier duality in the relevant ReferencePlane.
• The invariant is energy (or inner product), expressed as a KD‑CAL statement; EpistemicRetargeting ensures that energy‑related claims in Y are entailed by X.

Show 3 — Data→Model.

• X describes a dataset D (observations); DescribedEntityRef(X) = S_data.
• Y describes a model M (e.g. a parametric family with learned parameters); DescribedEntityRef(Y) = S_model.
• KindBridge(S_data, S_model) encodes the intended data→model relation (e.g. MLE, Bayesian posterior).
• The invariant is likelihood or predictive performance; the retargeting laws ensure Y does not claim more about this invariant than is supported by X.

#Consequences

• Clear separation of Viewing vs Retargeting. A.6.3 and A.6.4 now jointly distinguish:

  • views: same DescribedEntityRef, possible representation/viewpoint changes;
  • retargetings: different DescribedEntityRef under KindBridge and invariants.

• Canonical home for StructuralReinterpretation. E.TGA StructuralReinterpretation becomes a species of U.EpistemicRetargeting, not an ad‑hoc special node. This reduces duplication and clarifies how CL penalties and Bridges are used.

• Invariants become first‑class. Retargeting makes invariants explicit and type‑checked: every such morphism must state what it preserves and how that is expressed in KD‑CAL/LOG‑CAL.

• Safer cross‑plane reasoning. ReferencePlane crossings and kind‑level moves are handled via existing Bridges (Part F), with CL^plane/CL^k penalties and SquareLaw witnesses, instead of hidden in implementation details.

• Better integration with I/D/S. For …Description/…Spec epistemes, retargeting is the only place where DescribedEntityRef in DescriptionContext is allowed to change; all other I/D/S‑level operations (Describe/Specify, Viewing) keep it fixed.

#Rationale & SoTA‑echoing (informative)

• Fibrations and base‑change (displayed categories, 2017+). With epistemes forming a category Ep fibred over Ref via α : Ep → Ref (C.2 / A.6.2), EpistemicViewing corresponds to vertical morphisms (α(v) = id), while EpistemicRetargeting corresponds to reindexing along base arrows (α(r) = b : R₁→R₂). This lines up with base‑change and transport along fibrations in category theory.

• Structured cospans and reinterpretation. Modern work on structured cospans and open systems uses cospans and their morphisms to move between different presentations of a system while preserving a notion of interface/behaviour. Retargeting plays a similar role: it moves from one entity kind to another while preserving a declared invariant.

• Fourier‑style dualities. In signal processing and physics, Fourier and related transforms are often treated as isometries between function spaces, preserving energy while changing the domain of discourse. U.EpistemicRetargeting abstracts this pattern: the invariant is codified in KD‑CAL/LOG‑CAL; the morphism explicitly changes the described entity along a KindBridge.

• Data/model duality in ML. Contemporary ML workflows cycle between data and models; invariants such as likelihood, risk, and calibration matter more than raw equality of ClaimGraphs. Retargeting gives a structured way to talk about data→model (and, potentially, model→data) moves as episteme morphisms, rather than untyped “training” steps.

• Consistency management and abstraction. In model‑driven and bidirectional transformation literature, abstraction and refinement transfers information between models with different subject domains. Treating these as retargetings with explicit Bridges and invariants makes their assumptions amenable to CL accounting and KD‑CAL reasoning, instead of hiding them in tooling.

#Conformance checklist (normative)

CC‑A.6.4‑1 - EFEM species and DescribedEntityChangeMode. Any pattern that claims to define U.EpistemicRetargeting SHALL:

• declare itself a species of U.EffectFreeEpistemicMorphing (A.6.2),
• fix describedEntityChangeMode = retarget,
• and state its Applicability profile (EoI‑pairs, contexts, viewpoints, representation schemes, invariants).

CC‑A.6.4‑2 - Slot‑level read/write discipline. For each species of EpistemicRetargeting, authors MUST:

• list the SlotKinds it reads (at least DescribedEntitySlot, GroundingHolonSlot, ClaimGraphSlot, ViewpointSlot, ReferenceSchemeSlot, plus any C.2.1+ slots used),
• list the SlotKinds it writes (at least DescribedEntitySlot, typically also ClaimGraphSlot, ReferenceSchemeSlot, and meta),
• state explicitly how GroundingHolonSlot and ViewpointSlot behave (preserved vs bridged),
• reference A.6.5 to show that SlotSpecs remain consistent across domain/codomain kinds.

CC‑A.6.4‑3 - Bridge & invariant declaration. Each species SHALL:

• identify the relevant KindBridge species (and, where applicable, plane Bridges),
• declare the invariant(s) it preserves (in KD‑CAL/LOG‑CAL terms),
• sketch how invariant preservation is checked or approximated (e.g. through proofs, tests, or statistical guarantees).

CC‑A.6.4‑4 - SquareLaw‑retargeting witnesses. For retargetings that interact with E.TGA or other graph‑level transductions, authors MUST:

• describe the commutative squares (or more general diagrams) that express “evaluate then retarget = retarget then evaluate” up to equivalence,
• identify the corresponding SquareLaw‑retargeting witnesses and how they are represented as epistemes.

CC‑A.6.4‑5 - D/S‑context behaviour. For retargetings over …Description/…Spec epistemes:

• laws MUST be phrased in terms of DescriptionContext = ⟨DescribedEntityRef, BoundedContextRef, ViewpointRef⟩,
• DescribedEntityRef MUST change in a way consistent with the declared KindBridge,
• BoundedContextRef MUST either be preserved or changed only via explicit Context‑Bridges,
• ViewpointRef MUST either be preserved or change within a declared U.ViewpointBundle.

CC‑A.6.4‑6 - Separation from Viewing and Mechanisms.

• Any species that leaves describedEntityRef unchanged is not a conformant EpistemicRetargeting; it belongs to U.EpistemicViewing (A.6.3) or another EFEM species.
• Any species that performs measurements, actuation, or other side‑effects MUST be declared as U.Mechanism/U.WorkEnactment and cannot be an EpistemicRetargeting.

#Mini‑checklist (for authors)

When you think you need “retargeting” in FPF, ask:

1. Does describedEntityRef change? If no, this is Viewing (A.6.3), not Retargeting.

2. Is there a KindBridge between old and new entities? If not, you probably need to introduce one in Part F or rethink the Intension, not fudge a retargeting.

3. What invariant are you preserving? Write it down in KD‑CAL/LOG‑CAL terms. If you cannot, retargeting is underspecified.

4. How do GroundingHolonRef, context and viewpoint behave? Explicitly state whether they stay the same, move along Bridges, or are out of scope.

5. Can the operation be factored as Mechanism + pure retargeting? If the step needs computation (FFT, model fitting), separate the Mechanism from the EpistemicRetargeting.

#Relations

• Specialises / is specialised by.

  • Specialises A.6.2 U.EffectFreeEpistemicMorphing as the describedEntityChangeMode = retarget profile.
  • Complements A.6.3 U.EpistemicViewing (describedEntity‑preserving EFEM) as the “retargeting” counterpart.

• Constrained by.

  • A.6.5 U.RelationSlotDiscipline for SlotKind/ValueKind/RefKind discipline.
  • C.2.1 U.EpistemeSlotGraph for episteme components and DescribedEntitySlot/GroundingHolonSlot.
  • E.10.D2 (I/D/S discipline; DescriptionContext).
  • Part F (Bridges, KindBridge, ReferencePlane crossings, CL/CL^plane).
  • E.10 (LEX‑BUNDLE naming rules, especially on …Slot/…Ref and ban on Subject/Object in episteme tech names).

• Consumed by.

  • E.18 (E.TGA StructuralReinterpretation and other cross‑kind architecture transformations).
  • E.17.0/E.17 (for cases where publication needs to move between different entities‑of‑interest but preserve invariants).
  • KD‑CAL/LOG‑CAL rules that reason about retargeting and invariant preservation across different described entities.

#A.6.4:End