#U.EpistemicRetargeting - EntityOfConcern-Retargeting Morphism

A.6.4 · 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.EpistemicRetargeting is the EntityOfConcern retargeting species of U.EffectFreeEpistemicMorphing: an effect‑free episteme→episteme morphism that intentionally changes what the episteme is about (the value filling EntityOfConcernSlot in C.2.1) under a declared KindBridge and invariant, while remaining conservative with respect to that invariant. EntityOfConcern retargeting discipline. A.6.4 names the retarget branch of the C.2.1 EntityOfConcern retargeting law: entityOfConcernRef(Y) != entityOfConcernRef(X) only under a declared KindBridge, invariant, loss boundary, and admissible use. Earlier source-side spellings are source-migration wording only; conformant text normalizes them to EntityOfConcern* before use.

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 and E.10.D2 (EntityOfConcern and Description-episteme boundary and specification use/refinement discipline, DescriptionContext); C.2.1 U.Episteme — Epistemes and their slot relation; 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 (StructuralReinterpretation loci and other transformation-flow reinterpretation loci); discipline packs for signal/spectrum transforms, data↔model retargetings, abstraction/refinement under kind‑invariants; KD‑CAL/LOG‑CAL retargeting rules; additional species for architecture and governance reinterpretations.

Retargeting in plain terms. One effect-free episteme-to-episteme retargeting where the source episteme and receiving episteme intentionally describe different but bridge-related values of EntityOfConcernSlot.

First retargeting move in plain terms. Change the value filling EntityOfConcernSlot under a declared KindBridge and invariant, while making preserved commitments, withdrawn commitments, admissible predicate changes, and source-bearing reopen conditions visible.

Use this when. Use this pattern when a representation, view, functional description, model, diagram, StructuralReinterpretation, or other episteme-facing item no longer preserves entityOfConcernRef, but a declared bridge and invariant make a controlled retargeting admissible.

What goes wrong if missed. A changed EntityOfConcern is treated as "the same thing in another form", so users inherit claims, gates, evidence, work authority, or transformation-flow path currentness that the receiving EntityOfConcern does not make admissible.

What this buys. One honest retargeting relation: the reader can see the source entity, receiving entity, bridge, invariant, preserved commitments, lost or new commitments, and the specific admissible use that remains.

Not this pattern when. Not this pattern when the EntityOfConcern is preserved and the main change is wording (A.6.3.CR), representation scheme or reasoning medium (A.6.3.RT), controlled coarsening (A.6.3.CSC), explanation mode (E.17.EFP), bridge-only comparison without retargeting (F.9 or F.9.1), work (A.15), evidence (A.10), assurance (B.3), gate decision (A.21), temporal adequacy (C.27), or dynamics/control law (A.3.3).

Many important operations on descriptions change the EntityOfConcern while preserving a structural or behavioural invariant:

#Relations

#Content

#Problem frame

Many important operations on descriptions change the EntityOfConcern 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 E.18 StructuralReinterpretation loci express when a transformation-flow structure records this reinterpretation.

• 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 EntityOfConcern 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:

• operate on Description epistemes, including Description epistemes admitted for specification use rather than mutating the EntityOfConcern itself,
• do not merely slice or re-express an episteme with the same EntityOfConcern (that would be EpistemicViewing, A.6.3),
• but do change the EntityOfConcern/grounding bundle (EntityOfConcernSlot 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),
• EntityOfConcern retargeting 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” with the same EntityOfConcern, even though they change entityOfConcernRef. This hides the fact that the EntityOfConcern 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 remain only in prose,
   • 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 entityOfConcernRef by setting entityOfConcernChangeMode = retarget, but:

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

4. StructuralReinterpretation is ad‑hoc. E.18 positions StructuralReinterpretation as a transformation-flow locus, but its retargeting semantics are the generic “retargeting under a bridge” relation governed here, not a special graph-position ontology. Without a core pattern:

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

5. EntityOfConcern and Description-episteme boundary and specification-use discipline is left underspecified. For Description epistemes and Description epistemes admitted for specification use (...Description and ...Spec), retargeting changes EntityOfConcernRef in DescriptionContext = ⟨EntityOfConcernRef, 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 EntityOfConcern vs constructing something new. Retargeting expresses “describing a different but bridge-related entity through an explicit bridge”, not arbitrary construction of a new EntityOfConcern claim/episteme. The invariant holds 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 commitment must be modelled as a new or changed EntityOfConcern claim with its own Description epistemes, including Description epistemes admitted for specification use, 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 EntityOfConcern. 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 reference arrows.

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

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

#Informal definition

Definition (informal). U.EpistemicRetargeting is the EntityOfConcern retargeting species of U.EffectFreeEpistemicMorphing. A U.EpistemicRetargeting r : X->Y:

• takes an input episteme X and produces an output episteme Y,
• changes the value filling EntityOfConcernSlot (entityOfConcernRef(Y) != entityOfConcernRef(X)),
• relates the kinds of the source and receiving EntityOfConcern values 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 EntityOfConcernSlot (and often the <EntityOfConcernSlot, GroundingHolonSlot> bundle) along a KindBridge, while re-expressing content : U.ClaimGraph and referenceScheme so that the declared invariant continues to hold at the receiving EntityOfConcern.

#Retargeting witness decision block

When a retargeting claim has FPF-governed use, the receiving text makes these decision-block fields recoverable:

The decision block is not a new FPF kind, record, profile, publication form, or hidden evidence or justification object. It is a recoverable field set for retargeting cases. Ordinary local retargeting can stay compact when the source EntityOfConcern, receiving EntityOfConcern, bridge, invariant, and remaining reader action are already explicit.

If the bridge or invariant is insufficient for the intended use, the receiving item can still be useful, but the current disposition is source-bearing reopen, bridge-only comparison, controlled coarsening, report-only use, exploratory use, or named neighboring-pattern handoff. Do not keep an unnamed middle state where the retargeted item remains rhetorically useful but no FPF disposition is stated.

#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⟩      // episteme 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:

  • EntityOfConcernSlot (ValueKind U.Entity, RefKind U.EntityRef, usually restricted to an EntityOfConcernClass ⊑ 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 entityOfConcernChangeMode = 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 entityOfConcernChangeMode = preserve, where the EntityOfConcern 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 & EntityOfConcernChangeMode.

• Any morphism r:X→Y declared as U.EpistemicRetargeting MUST:
  • be a species of U.EffectFreeEpistemicMorphing (A.6.2), and
  • declare entityOfConcernChangeMode(r) = retarget.
• Consequently:
• the pair <EntityOfConcernSlot, GroundingHolonSlot> is the retargeted EoC/grounding bundle for the change (as in C.2.1 §7.3: EntityOfConcern‑bundle retargeting),
• EntityOfConcernSlot is write‑enabled (unlike Viewing) but only under the constraints below,
• there exist entities T₁, T₂ : U.Entity such that:
  • entityOfConcernRef(X) = T₁,
  • entityOfConcernRef(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 & EntityOfConcern‑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 (EntityOfConcernSlot, GroundingHolonSlot?, ClaimGraphSlot, ViewpointSlot?, ReferenceSchemeSlot) and obey A.6.5.

2. At the SlotKind level:

   • EntityOfConcernSlot:

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

   • GroundingHolonSlot, if present:

     • is either preserved by reference equality (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 = ⟨EntityOfConcernRef, BoundedContextRef, ViewpointRef⟩. Under EpistemicRetargeting:

   • EntityOfConcernRef 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 <EntityOfConcernSlot, GroundingHolonSlot> is treated as a retargeted EoC/grounding bundle: many practical retargetings work at the level of this bundle rather than EntityOfConcern alone, especially where E.18 StructuralReinterpretation is used.

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

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

• entityOfConcernRef(X) = T₁, entityOfConcernRef(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 interpreting 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 planes or ReferencePlanes (with Bridges and CL penalties declared), but MUST NOT violate the declared invariant.

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

   • a change of EntityOfConcern claim (new Description episteme or Description episteme admitted for specification use under A.7 and E.10.D2), or
   • a chain of retargetings and EntityOfConcern claim 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 entityOfConcernRef(X) = T₁ and entityOfConcernRef(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.18), 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 EntityOfConcern values.

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 EntityOfConcern or invariant‑relevant content:

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

• 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, EntityOfConcernClass pairs & CL‑discipline.

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

1. EntityOfConcernClass pairs. Admissible pairs of EntityOfConcernClasses (ValueKinds of EntityOfConcernSlot 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 the E.18 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 entityOfConcernRef (and keeps EntityOfConcernChangeMode = preserve) belongs to A.6.3 U.EpistemicViewing, not to U.EpistemicRetargeting.
   • Any morphism that does change entityOfConcernRef MUST NOT be declared as U.EpistemicViewing; it is either:
     • a U.EpistemicRetargeting, or
     • a more general pattern that composes several retargetings and EntityOfConcern claim changes.

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

2. Separation from Mechanisms.

   • Retargeting MAY depend on outputs 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.

#Boundary with representation, explanation, transformation-flow structure, and neighboring claims

U.EpistemicRetargeting is triggered by changed EntityOfConcern, EntityOfConcern kind, ontology frame, admissible predicate set, or invariant-bearing receiving EntityOfConcern. It is not triggered by changed wording, changed representation scheme, changed explanation mode, or publication formatting alone.

Boundary rules:

• if the EntityOfConcern is preserved and the main change is representation scheme or reasoning medium, use A.6.3.RT;
• if the EntityOfConcern is preserved and the main change is explanation mode, explanatory stance, or explanation-facing publication, use E.17.EFP;
• if the source and receiving items are only bridge-only comparison, analogy, equivalence, or substitution relation, use F.9 or F.9.1 instead of interpreting the bridge as identity;
• if the receiving item is useful only under narrower declared use with visible loss and source-bearing reopen, use A.6.3.CSC;
• if decoded or latent output is interpretable but not tied to source claim, access relation, recoverability evidence, admissible-use value, and remaining reader action, keep it report-only, exploratory, source-bearing reopen, or in the named neighboring pattern;
• if a StructuralReinterpretation, PathSliceId, CrossingRef, or DecisionLogRef is present, use E.18, A.20, or A.21 for graph, path, constraint, and gate relations. Those references do not prove semantic continuity or retargeting admissibility by themselves;
• if changed problem formulation changes abductive prompt, candidate generation, rival-set formation, selected prime hypothesis, plausibility filtering, or abductive reopen, use B.5.2;
• if the receiving item is used as work, evidence, assurance, gate passage, temporal claim, dynamics law, or control relation, use A.15, A.10, B.3, A.21, C.27, A.3.3, or the neighboring governing pattern.

StructuralReinterpretation in E.18 receives retargeting semantics from this pattern. It is not an E.18-local retargeting kind and not proof that the source and receiving items preserve the same entityOfConcernRef.

#Archetypal grounding (Tell-Show-Show)

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

• the source episteme describes “this cabinet”, while the receiving episteme describes “the routing function it realises”;
• the source episteme describes “this signal over time”, while the receiving episteme describes “its spectrum over frequency”;
• the source episteme describes “this dataset”, while the receiving episteme describes “a model class with parameters θ learned from it”.

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

Show 1 — StructuralReinterpretation in E.18.

• 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”.
• An E.18 StructuralReinterpretation locus can be governed as an instance of U.EpistemicRetargeting when its invariant is the behaviour relation between S_phys and S_func.

Show 2 — Signal↔Spectrum.

• X describes a time‑domain signal s(t); EntityOfConcernRef(X) = S_time.
• Y describes its spectrum S(ω); EntityOfConcernRef(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); EntityOfConcernRef(X) = S_data.
• Y describes a model M (e.g. a parametric family with learned parameters); EntityOfConcernRef(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 warranted by X.

#Consequences

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

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

• Canonical governing pattern for StructuralReinterpretation. E.18 StructuralReinterpretation receives semantics from U.EpistemicRetargeting, not from an ad-hoc special graph-position kind. 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 EntityOfConcern and Description-episteme boundary and specification-use gate. For …Description/…Spec epistemes, retargeting is the only place where EntityOfConcernRef in DescriptionContext is allowed to change; all other EntityOfConcern and Description-episteme boundary and specification-use operations (Describe, specification-use refinement, 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 reference 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 EntityOfConcern along a KindBridge.

• Data/model duality in ML. Contemporary ML practice cycles 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 EntityOfConcernChangeMode. Any pattern that claims to define U.EpistemicRetargeting SHALL:

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

CC‑A.6.4‑2 - Slot‑level read/write discipline. Each species of EpistemicRetargeting MUST:

• list the SlotKinds it reads (at least EntityOfConcernSlot, GroundingHolonSlot, ClaimGraphSlot, ViewpointSlot, ReferenceSchemeSlot, plus any C.2.1+ slots used),
• list the SlotKinds it writes (at least EntityOfConcernSlot, 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. Retargeting species that interact with E.18 transformation-flow structures or other graph-level transformation structures 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 - DescriptionContext behaviour for Description-episteme and specification-use cases. For retargetings over …Description/…Spec epistemes:

• laws MUST be phrased in terms of DescriptionContext = ⟨EntityOfConcernRef, BoundedContextRef, ViewpointRef⟩,
• EntityOfConcernRef 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 entityOfConcernRef 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.

CC-A.6.4-7 - Retargeting witness and reopen discipline. For every FPF-governed retargeting use, the source EntityOfConcern, receiving EntityOfConcern, KindBridge, invariant, preserved commitments, withdrawn or new commitments, admissible predicate changes, admissibility value, retargeting witness, and source-bearing reopen condition are recoverable. If bridge or invariant witnessing is insufficient for the intended use, the case records source-bearing reopen, bridge-only comparison, controlled coarsening, report-only use, exploratory use, or named neighboring-pattern handoff.

CC-A.6.4-8 - Neighboring-pattern handoff. Retargeting wording does not carry work authority, evidence force, assurance force, gate passage, abductive selection, temporal adequacy, dynamics law, control relation, bridge substitution, or transformation-flow path currentness unless the governing FPF pattern and project-side FPF kind or reference named by value are named.

CC-A.6.4-9 - StructuralReinterpretation boundary. When StructuralReinterpretation, PathSliceId, CrossingRef, or DecisionLogRef is used, the graph, path, constraint, and gate relations stay with E.18, A.20, or A.21. StructuralReinterpretation receives retargeting semantics from A.6.4; it is not proof of entityOfConcernRef continuity and not an E.18-local retargeting kind.

#Mini-checklist (for use)

When you think you need "retargeting" in FPF, ask:

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

2. Is there a KindBridge between source and receiving entities? If not, add or select the bridge in Part F, or revise the EntityOfConcern instead of treating the relation as 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? 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 such as FFT or model fitting, separate the Mechanism from the EpistemicRetargeting.

6. What remains admissible for the reader? State the remaining reader action, and name source-bearing reopen or a neighboring pattern when the bridge, invariant, or source/bridge/invariant witness is insufficient for the intended use.

#Relations

• Specialises / is specialised by.

  • Specialises A.6.2 U.EffectFreeEpistemicMorphing as the entityOfConcernChangeMode = retarget profile.
  • Complements A.6.3 U.EpistemicViewing (EntityOfConcern-preserving EFEM) as the “retargeting” counterpart.

• Constrained by.

  • A.6.5 U.RelationSlotDiscipline for SlotKind/ValueKind/RefKind discipline.
  • C.2.1 U.EpistemeSlotRelation for episteme components and EntityOfConcernSlot/GroundingHolonSlot.
  • E.10.D2 (EntityOfConcern and Description-episteme boundary and specification use/refinement 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 (StructuralReinterpretation and other cross-kind transformation-flow architecture relations).
  • E.17.0/E.17 (for cases where publication needs to move between different EntityOfConcern values but preserve invariants).
  • KD‑CAL/LOG‑CAL rules that reason about retargeting and invariant preservation across different EntityOfConcern values.

#A.6.4:End

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