#U.EpistemicViewing - EntityOfConcern-Preserving Morphism

A.6.3 · 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.EpistemicViewing is the EntityOfConcern-preserving species of U.EffectFreeEpistemicMorphing: an effect‑free projection between epistemes that may change content and representation, but never changes what the episteme is about (the value filling EntityOfConcernSlot in C.2.1). EntityOfConcern preservation discipline. A.6.3 names the preserve branch of the C.2.1 EntityOfConcern preservation law: entityOfConcernRef(Y) = entityOfConcernRef(X) and EntityOfConcernSlot is read-only. Earlier source-side spellings are source-migration wording only; conformant text normalizes them to EntityOfConcern* before use.

Placement. After A.6.2 U.EffectFreeEpistemicMorphing, before A.6.4 U.EpistemicRetargeting.

Builds on. A.6.0 U.Signature; A.6.2 U.EffectFreeEpistemicMorphing; 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 (KD‑CAL/LOG‑CAL, subjectRef, ReferencePlane).

Used by. E.17.0 U.MultiViewDescribing; E.17 (MVPK — Multi‑View Publication Kit); E.17.1/E.17.2 (Viewpoint bundle libraries, TEVB); B.5.3 (Role‑EpistemicViewing); discipline packs for architecture, safety, and ML/LLM‑based representations.

Engineers and researchers constantly need views that preserve the same EntityOfConcern:

• an ISO 42010‑style architectural view for a particular stakeholder group over a shared architecture description;
• a SysML v2 “view‑as‑query” over an underlying model, changing visualisation but not the modelled system;
• a publication view (Plain/Tech/Assurance) in MVPK over a common description and specification-useification;
• an LLM‑friendly episteme derived from a symbolic specification (or vice versa), preserving what system is being described.

#Relations

#Content

#Problem frame

Engineers and researchers constantly need views that preserve the same EntityOfConcern:

• an ISO 42010‑style architectural view for a particular stakeholder group over a shared architecture description;
• a SysML v2 “view‑as‑query” over an underlying model, changing visualisation but not the modelled system;
• a publication view (Plain/Tech/Assurance) in MVPK over a common description and specification-useification;
• an LLM‑friendly episteme derived from a symbolic specification (or vice versa), preserving what system is being described.

All of these are episteme→episteme transforms that must:

• keep the EntityOfConcern fixed (EntityOfConcernSlot in C.2.1), and
• change only how the episteme talks about it: sliced U.ClaimGraph, different U.Viewpoint, alternative U.RepresentationScheme, or a different U.ReferenceScheme tuned to the same EntityOfConcern and grounding holon.

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

• effect‑free (no Work/Mechanism side‑effects),
• EntityOfConcern-preserving (no silent retargeting),
• conservative (no new commitments about the EntityOfConcern),
• and functorial (compose cleanly in multi-step compositions).

#Problem

Without a dedicated pattern for EpistemicViewing:

1. Views vs retargetings blur. Operations that intend to change only representation (viewing) are easily conflated with operations that change the EntityOfConcern (retargeting). A Fourier‑style transform or a structural reinterpretation in E.18 can quietly drift from “view of S” into “view of a different S′”, without declaring a KindBridge.

2. “View” vs “viewpoint” vs rendered publication collapse. In standards and tools, “view” is often used interchangeably to mean:

   • the viewpoint (specification of concerns and conformance rules),
   • the episteme produced under that viewpoint, and
   • the rendered publication or carrier (document, GUI, export, or other bearer). Without a clear episteme-lane notion of viewing, MVPK and E.17.0 cannot cleanly separate these lanes.

3. No entityOfConcern guarantees. A projection that looks like a harmless slice of a system description may in fact:

   • change entityOfConcernRef (switching to a subsystem or a function),
   • change groundingHolonRef (different plant or runtime),
   • or smuggle in new commitments about the EntityOfConcern. Without explicit invariants over C.2.1 components, “view” becomes an informal metaphor, not a reliable morphism class.

4. Multi‑view reasoning has no core discipline. Multi‑view patterns (ISO 42010 viewpoint libraries, SysML v2 view queries, TEVB, MVPK faces) need:

   • vertical projections that preserve entityOfConcernRef (α : Ep → Ref fixed),
   • and correspondence‑based projections that rely on explicit cross‑episteme links. If each family re‑invents its own notion of “view”, consistency and tool checks degrade.

#Forces

• Same EntityOfConcern, different concerns. Stakeholders want different slices of the same description and specification-useification, sometimes under different viewpoints, without re-identifying the system, method, service, or other entity that fills EntityOfConcernSlot.

• Internal vs cross‑episteme views. Some views depend only on a single episteme (direct viewing); others depend on a CorrespondenceModel (e.g. aligning requirements and design models). Both are admissible, but they require different witnesses.

• Conservativity vs expressivity. A view must not introduce new commitments about the EntityOfConcern, but it may:

  • aggregate or factor claims,
  • change representation regime (diagrammatic vs symbolic vs latent),
  • or shift to a different inference regime, as long as this is conservative.

• EntityOfConcern and Description-episteme boundary and specification-use strictness. …Description names a Description episteme, and …Spec names a Description episteme admitted for specification use whose subjectRef decodes to DescriptionContext = ⟨EntityOfConcernRef, BoundedContextRef, ViewpointRef⟩ when the declared checkability/formality gate is present. Viewing works over these DescriptionContext triples without collapsing the EntityOfConcern into the Description episteme or Description episteme admitted for specification use produced by the use, while still allowing that EntityOfConcern to be a U.Episteme when an episteme is under concern; it also must not confuse those epistemes with publication faces or carriers.

• Slot discipline and modularity. With C.2.1 and A.6.5, epistemes now have explicit SlotKind/ValueKind/RefKind triples. Viewing invariants must be stated per SlotKind, not in terms of ad‑hoc “fields”, so they can be reused across engineering, publication, and discipline packs.

#Solution — U.EpistemicViewing as EFEM profile (entityOfConcernChangeMode = preserve)

#Informal definition

Definition (informal). U.EpistemicViewing is the EntityOfConcern-preserving species of U.EffectFreeEpistemicMorphing. A U.EpistemicViewing v : X→Y:

• takes an input episteme X and produces an output episteme Y,
• preserves the value filling EntityOfConcernSlot (entityOfConcernRef(Y) = entityOfConcernRef(X)),
• may refine or re‑express content : U.ClaimGraph, viewpointRef, representationSchemeRef, and referenceScheme,
• is effect-free and conservative (no new commitments about the EntityOfConcern),
• and composes functorially with other epistemic viewings.

In C.2.1 terms U.EpistemicViewing behaves like a lens/optic over the episteme slot relation: it focuses on some SlotKinds (typically ClaimGraphSlot, ViewpointSlot, RepresentationSchemeSlot, ReferenceSchemeSlot) while preserving EntityOfConcernSlot (and usually GroundingHolonSlot).

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

Signature header. U.EpistemicViewing is a Morphism‑kind under A.6.0:

SubjectBlock
  SubjectKind    = U.EpistemicViewing
  BaseType       = ⟨X:U.Episteme, Y:U.Episteme⟩      // domain/codomain episteme pair
  Quantification = SliceSet := U.ContextSliceSet;
                   ExtentRule := admissible view morphisms
  ResultKind     = U.Morphism                        // an instance v

Vocabulary (re‑uses A.6.2).

• Types. U.Episteme, U.SubjectRef, U.Morphism, U.EpistemicViewing.
• Operators.
  • id : U.Morphism(X→X)
  • compose(g,f) : U.Morphism(X→Z) where f:X→Y, g:Y→Z
  • apply(v, x:U.Episteme) : U.Episteme
  • dom(v), cod(v) : U.Episteme
  • subjectRef(-) : U.SubjectRef SlotKind-specific 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),
  • 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.

Practical species of EpistemicViewing will very often take X and Y from the same U.EpistemeKind, but the pattern itself only requires that the SlotSpecs of the domain and codomain kinds be compatible in the sense of A.6.5, not literally identical.

Relation to EFEM.

• Every U.EpistemicViewing is an EFEM morphism with entityOfConcernChangeMode = preserve in the sense of A.6.2/C.2.1.
• It inherits P0–P5 from A.6.2, specialised to the case where the value filling EntityOfConcernSlot is unchanged.

#Invariants (EV-0...EV-6, over C.2.1 components)

All invariants below are in addition to A.6.2 EFEM invariants P0-P5 and SHALL be read directly against C.2.1 components and A.6.5 SlotSpecs.

EV‑0 - Species & EntityOfConcernChangeMode.

• Any morphism v:X→Y declared as U.EpistemicViewing MUST:
  • be a species of U.EffectFreeEpistemicMorphing (A.6.2), and
  • declare entityOfConcernChangeMode(v) = preserve.
• Consequently:
  • EntityOfConcernSlot has the same ValueKind and RefKind in the episteme kind of X and Y (same EntityOfConcernClass ⊑ U.Entity);
  • entityOfConcernRef(Y) = entityOfConcernRef(X) by definition of the species.

EV‑1 - Typed domain/codomain & DescriptionContext behaviour.

For any v:X→Y in U.EpistemicViewing:

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. Many practical species of EpistemicViewing will take X and Y from the same U.EpistemeKind, but the A.6.3 pattern only requires SlotSpec compatibility between domain and codomain kinds (in the sense of A.6.5), not literal kind equality.

2. In the SlotKind-specific read/write discipline:

   • EntityOfConcernSlot is read‑only (no change in entityOfConcernRef).
   • GroundingHolonSlot, if present, is:
     • either preserved exactly, or
     • changed only within an explicitly declared grounding context (e.g. normalising identifiers for the same plant or runtime), justified via a Bridge in the same ReferencePlane.
   • ViewpointSlot, if present, is:
     • either preserved (internal normalisation under the same viewpoint), or
     • changed only to another U.ViewpointRef within a declared U.MultiViewDescribing family (E.17.0), with a CorrespondenceModel providing witnesses.

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

   • preserve EntityOfConcernRef,
   • preserve BoundedContextRef (unless a Bridge is explicitly cited),
   • treat ViewpointRef as in (2) above.

EV‑2 - Effect‑free boundary (over EpistemeSlotRelation). EpistemicViewing remains pure in the EFEM sense:

• It may change only C.2.1 components of the codomain episteme:
  • content : U.ClaimGraph (e.g. filtering, aggregation, normalisation),
  • viewpointRef (under the constraints in EV‑1),
  • representationSchemeRef and ReferenceScheme (within a fixed representation family or under a declared CorrespondenceModel),
  • meta‑components (edition, provenance, status flags).
• It MUST NOT:
  • invoke U.Mechanism or U.WorkEnactment (measure, execute, actuate),
  • create or modify U.PresentationCarrier (no direct publication rendering or carrier writing),
  • cross ReferencePlanes implicitly (plane crossings go through Bridges with CL penalties in Part F).

Any operational machinery (e.g. SAT/SMT solving, simulation, LLM tool‑use) MUST be modelled as a separate U.Mechanism that produces input epistemes or auxiliary epistemes or carriers consumed by the EpistemicViewing morphism.

EV-3 - No new commitments about the EntityOfConcern.

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

• content_X, referenceScheme_X,
• content_Y, referenceScheme_Y,
• shared entityOfConcernRef and (typically) groundingHolonRef.

Then:

• The set of claims about <entityOfConcernRef, groundingHolonRef> obtained by interpreting content_Y through referenceScheme_Y MUST NOT strictly extend what is already entailed, in KD‑CAL/LOG‑CAL, by content_X interpreted through referenceScheme_X under the same ReferencePlane and context.
• Admissible changes:
  • re‑expression (changing representation, not truth conditions),
  • aggregation (e.g. summarising multiple claims into an explicitly derivable macro‑claim),
  • dropping some information (lossy projection), provided no new atomic commitments about the EntityOfConcern are introduced.
• Any deliberate strengthening of behavioural or structural commitments about the same EntityOfConcern is not a valid EpistemicViewing; it must be modelled either as:
  • a new or changed EntityOfConcern claim with its own Description epistemes, including Description epistemes admitted for specification use under A.7 and E.10.D2, or
  • an A.6.4 U.EpistemicRetargeting plus a new EntityOfConcern claim.

EV‑4 - Functoriality & correspondence alignment.

EpistemicViewing inherits EFEM functoriality and specialises it:

1. Direct EpistemicViewing (same representation scheme). Where representationSchemeRef and ReferenceScheme of X and Y are the same (up to declared normal forms), EpistemicViewing acts as a strict functor on ClaimGraphs:

   • apply(id, X) = X,
   • apply(g ∘ f, X) = apply(g, apply(f, X)),
   • content transformation corresponds to a structural ClaimGraph function.

2. Correspondence‑based EpistemicViewing (representation changes). When viewing relies on a CorrespondenceModel between epistemes or representation schemes:

   • the viewing morphism MUST reference that CorrespondenceModel,
   • compositions involving such viewings MUST publish witnesses (epistemes or proof epistemes or proof records) that squares commute up to declared isomorphism (oplax naturality is allowed, but corrections are deterministic and reproducible),
   • entityOfConcernRef and groundingHolonRef remain as in EV‑1; any transfer across contexts or planes goes via Bridges, not via hidden behaviour of the viewing.

EV‑5 - Idempotency & determinism on fixed configuration.

For any v:X→Y in U.EpistemicViewing, with fixed:

• entityOfConcernRef,
• groundingHolonRef,
• viewpointRef,
• representationSchemeRef,
• referenceScheme,
• and fixed CorrespondenceModel (if used),

the following MUST hold:

• Idempotency. apply(v, apply(v, X)) is isomorphic to apply(v, X):
  • same EntityOfConcern and grounding holon,
  • same viewpoint and representation scheme,
  • ClaimGraphs differ, at most, by declared structural equivalence (e.g. normal form vs source form).
• Determinism. For fixed input and configuration, the result is uniquely determined (modulo declared equivalence). Any source of non‑determinism (random seeds, timing, external service state) MUST either:
  • be exposed as part of content / meta of X, or
  • be moved into a Mechanism outside the viewing morphism.

EV‑6 - Applicability & MultiViewDescribing alignment.

Each species of U.EpistemicViewing MUST:

1. Declare an Applicability profile (A.6.0) specifying:
   • permitted EntityOfConcernClass ⊑ U.Entity (ValueKind of EntityOfConcernSlot),
   • permitted groundingHolonRef classes and ReferencePlanes,
   • admissible viewpointRef ranges (possibly a named U.ViewpointBundle),
   • admissible representationSchemeRef families.
2. For Description epistemes, including Description epistemes admitted for specification use in a U.MultiViewDescribing family (E.17.0):
   • preserve EntityOfConcernRef of DescriptionContext,
   • either preserve ViewpointRef or change it within the declared viewpoint bundle, with any additional constraints recorded in the family’s CorrespondenceModel,
   • never widen ClaimScope beyond what EV‑3 permits.
3. Treat any change of EntityOfConcern (even if “intuitively minor”, such as moving from subsystem to system) as out of scope for A.6.3; such moves belong to A.6.4 U.EpistemicRetargeting.

#Profiles: U.DirectEpistemicViewing and U.CorrespondenceEpistemicViewing

U.EpistemicViewing is further structured into two important species; both inherit EV‑0…EV‑6.

1. U.DirectEpistemicViewing — self‑contained views.

   • Domain and codomain epistemes share:
     • the same representationSchemeRef (up to declared normalisation),
     • the same ReferenceScheme (or a refinement which is conservative and structurally documented).
   • No external CorrespondenceModel is needed: the view is computed solely from the input episteme and, optionally, fixed configuration.
   • Typical cases:
     • internal normalisation (sorting, rewriting) of an engineering view;
     • filtering U.ClaimGraph to keep only safety‑relevant claims;
     • simplifying a proof‑oriented specification to a more operational form under the same semantics.

2. U.CorrespondenceEpistemicViewing — views relying on correspondence models.

   • Viewing depends on:
     • one or more subject epistemes (e.g. requirements and design),
     • an explicit CorrespondenceModel that relates their ClaimGraphs and representation schemes.
   • The result is an episteme (often an U.EpistemeView) whose entityOfConcernRef matches that of the primary episteme, but whose content is computed through the correspondence links.
   • Typical cases:
     • ISO 42010‑style correspondences between architectural descriptions;
     • cross‑model views in model‑based systems engineering (MBSE), where view content is computed from multiple model fragments;
     • traceability‑based views aggregating requirements, design elements, and tests.

In both profiles:

• CorrespondenceModel remains an episteme-lane publication, not a new kernel‑type hidden inside A.6.3.
• U.EpistemicViewing stays view‑like: it reveals what is already there under the correspondence; it does not perform Γ-style construction of new EntityOfConcern claims.

#Common same-entity specialization notes

Two recurring EntityOfConcern-preserving families can be read as specializations governed by A.6.3, provided that EV‑0…EV‑6 remain explicit.

1. ConservativeRetextualization. Use this when the receiving item remains textual and the main change is wording, density, ordering, language, or bounded filtering of already available content. It stays in A.6.3 only if entityOfConcernRef is preserved, no new claims about that entity are minted, and correspondence use does not collapse into bridge or substitution licence.

2. RepresentationSchemeTransition. Use this when the receiving item changes representation scheme or reasoning medium while still preserving the same EntityOfConcern. It stays in A.6.3 only if representation-factor delta, recoverability, loss, and preserve-vs-retarget boundaries remain explicit. Purely textual rewrites belong with ConservativeRetextualization; any change of EntityOfConcernRef belongs with A.6.4.

These notes do not create new governing patterns. They mark recurring same-entity specialization boundaries that remain subordinate to U.DirectEpistemicViewing / U.CorrespondenceEpistemicViewing and to the general A.6.3 invariants.

#Archetypal grounding (Tell–Show–Show)

#Engineering system description → safety officer view (DirectEpistemicViewing)

Context. A system team maintains a rich SystemDescription episteme for a plant holon S under an engineering viewpoint from TEVB. A safety officer needs a concise view showing only safety‑critical components, hazards, and mitigations.

Shape.

• Domain X. X : U.SystemDescription with:
  • entityOfConcernRef(X) : U.SystemRef (the plant S),
  • groundingHolonRef(X) : U.HolonRef (runtime environment),
  • viewpointRef(X) : U.ViewpointRef (engineering TEVB viewpoint),
  • content(X) : U.ClaimGraph (full behavioural & structural claims).
• Codomain Y. Y : U.EpistemeView with:
  • entityOfConcernRef(Y) = entityOfConcernRef(X),
  • groundingHolonRef(Y) = groundingHolonRef(X),
  • viewpointRef(Y) either equal to or a refinement of the original engineering viewpoint (TEVB safety sub‑viewpoint),
  • content(Y) containing only safety‑relevant claims, plus explicit aggregation nodes (e.g. hazard summaries).

SafetyView : X→Y is a DirectEpistemicViewing:

• entityOfConcernChangeMode = preserve,
• only content, viewpointRef (within TEVB) and meta change,
• KD‑CAL/LOG‑CAL checks show that every hazard/mitigation claim in Y is entailed by X,
• view is idempotent and deterministic given X and the selected safety profile.

This is the canonical “engineering view” archetype that later species in E.17.2/TEVB refer back to.

#MVPK publication view normalisation (DirectEpistemicViewing)

Context. MVPK emits a TechCard view V_raw for an arrow f in a morphism class (e.g. a gate-checked, crossing-visible service with OperationalGate(profile) + DecisionLog). The publication pipeline wants a normalised view V_norm where:

• arrows are ordered canonically,
• units and names follow a fixed naming discipline,
• redundant cells are removed.

Shape.

• X = V_raw, Y = V_norm, both U.EpistemeView instances with:
  • same entityOfConcernRef (the morphism’s arrow or capability),
  • same groundingHolonRef (runtime/plant),
  • same viewpointRef (publication viewpoint),
  • same representationSchemeRef (TechCard schema).

NormalizeTechCard : X→Y is a DirectEpistemicViewing:

• changes only content and meta (e.g. “normalised at edition E”),
• is pure and idempotent (two passes give the same normal form),
• is conservative: no new claims about the arrow f appear; information is only reordered or discarded.

MVPK can rely on this as an A.6.3‑conformant step without restating EFEM invariants.

#Cross‑model consistency view (CorrespondenceEpistemicViewing)

Context. A system has:

• a requirements episteme R (“what the system should do”), and
• a design episteme D (“how the system does it”),

both with entityOfConcernRef pointing to the same system holon S, but living in different notations and contexts. A systems engineer wants a view that shows only those requirements that currently have design coverage.

Shape.

• R : U.SystemRequirementsDescription with ClaimGraph C_R.
• D : U.SystemDesignDescription with ClaimGraph C_D.
• CM : U.CorrespondenceModel relating requirements to design elements.
• Y : U.EpistemeView with:
  • entityOfConcernRef(Y) = entityOfConcernRef(R) = entityOfConcernRef(D) = S,
  • groundingHolonRef(Y) inherited from R/D or declared via a Bridge,
  • content(Y) aggregating only those requirements in C_R for which CM records coverage in C_D.

CoveredRequirementsView(R,D,CM) : X→Y (with X a compound episteme or a bundle episteme over R,D,CM) is a CorrespondenceEpistemicViewing:

• relies essentially on CM (without it, the view is undefined — fail‑closed),
• must publish witnesses that two different ways of composing local correspondences give the same result up to declared equivalence,
• remains conservative: it does not assert that any requirement is covered unless that fact is recorded in CM and justified in D.

This archetype mirrors post‑2015 work on model synchronisation and bidirectional transformations, but anchored in the EpistemeSlotRelation.

#Consequences

• Clear separation of viewing vs retargeting. U.EpistemicViewing and U.EpistemicRetargeting (A.6.4) now cleanly separate:

  • “view of the same EntityOfConcern” vs “description of a different entity under a bridge”, and
  • vertical morphisms (α fixed) vs retargeting morphisms (α changes under KindBridge).

• Stable backbone for multi‑view patterns. Multi‑view description (E.17.0), viewpoint bundle libraries (E.17.1/E.17.2), and MVPK publication now share a single notion of view morphism, aligned with C.2.1 slots and the EntityOfConcern and Description-episteme boundary and specification use/refinement discipline.

• SlotKind-specific discipline for tools. Tools implementing views (queries, projections, report generators, LLM‑based summarisation) must declare:

  • which SlotKinds they read,
  • which SlotKinds they may write,
  • and that EntityOfConcernSlot is preserved. This removes ambiguity around subject/EntityOfConcern changes and enables robust static checking.

• Alignment with modern view/query practices. The pattern aligns with:

  • ISO 42010:2011/2022 and its focus on viewpoints, views, and correspondences over an entity of concern;
  • SysML v2 “views‑as‑queries” paradigm, where views are queries over a stable model, not new models;
  • post‑2015 work on optics and displayed categories, treating views as structured projections over a fibred category of epistemes.

#Rationale & SoTA‑echoing (informative)

• Optics and displayed categories. In categorical terms, epistemes form a category Ep fibred over a category of EntityOfConcern references Ref via α : Ep → Ref. EpistemicViewing corresponds to vertical morphisms that preserve α. Their behaviour closely tracks profunctor optics: the EntityOfConcernSlot plays the role of the “focus index”, while ClaimGraphs and representation schemes act as the data being transformed. Recent work on optics (2018‑onwards) provides compositional invariants that FPF leverages without committing to a specific optic calculus.

• Multi‑view modelling and viewpoint libraries. ISO 42010 and its successors, as well as MBSE practice from ~2015 onwards, have refined the separation between viewpoints (families of concerns, stakeholders, and notations) and views (instances under those viewpoints). U.EpistemicViewing gives FPF a substrate‑agnostic notion of “view” that can be instantiated for architecture descriptions, safety cases, or even research epistemes/publications, while TEVB and E.17.0 specialise it to engineering holons.

• Bidirectional transformations and consistency management. Modern BX research treats views and consistency restoration as structured transformations between models, with consistency relations acting as correspondences. U.CorrespondenceEpistemicViewing echoes this practice but insists that:

  • viewing is non-creative for EntityOfConcern commitments,
  • any strengthening or change of EntityOfConcern is explicitly modelled as retargeting or EntityOfConcern-claim change.

• Hybrid symbolic/latent representations. Contemporary work on LLMs and neurosymbolic systems often toggles between:

  • symbolic specifications (logical, tabular, diagrammatic), and
  • distributed or latent representations used for computation. By treating U.RepresentationScheme and U.RepresentationOperation as first‑class episteme components, FPF allows EpistemicViewing to range over:
  • purely symbolic projections,
  • latent‑space projections,
  • or hybrids that invoke external mechanisms before applying a pure view, without changing the core invariants.

#Conformance checklist (normative)

CC‑A.6.3‑1 - EFEM species and EntityOfConcernChangeMode. Any pattern that claims to define U.EpistemicViewing SHALL:

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

CC-A.6.3-2 - SlotKind-specific read/write discipline. For each species of EpistemicViewing, the definition MUST:

• list the SlotKinds it reads (typically EntityOfConcernSlot, GroundingHolonSlot, ClaimGraphSlot, ViewpointSlot, RepresentationSchemeSlot, ReferenceSchemeSlot),
• list the SlotKinds it writes (typically ClaimGraphSlot, optionally ViewpointSlot, RepresentationSchemeSlot, ReferenceSchemeSlot, and meta),
• assert explicitly that EntityOfConcernSlot is read‑only,
• and state any constraints on GroundingHolonSlot / ViewpointSlot changes.

This satisfies A.6.5 and C.2.1 checkpoint CC‑C.2.1‑5.

CC‑A.6.3‑3 - DescriptionContext discipline (for Description epistemes, including Description epistemes admitted for specification use). When domain/codomain epistemes are …Description/…Spec:

• viewing invariants SHALL be phrased in terms of DescriptionContext = ⟨EntityOfConcernRef, BoundedContextRef, ViewpointRef⟩,
• EntityOfConcernRef MUST be preserved,
• BoundedContextRef MUST be preserved unless a Bridge is explicitly cited,
• ViewpointRef MUST either be preserved or changed within a declared U.ViewpointBundle.

CC‑A.6.3‑4 - Conservativity witness. For each species, the definition SHALL provide:

• a clear statement of what counts as a new commitment about the EntityOfConcern in the relevant discipline,
• and a sketch of how conservativity (EV‑3) is checked or approximated (e.g. via KD‑CAL entailment, proof or structural invariants).

CC‑A.6.3‑5 - Profile classification.

• Species that do not require a CorrespondenceModel MUST be marked as U.DirectEpistemicViewing.
• Species that do require such a model MUST be marked as U.CorrespondenceEpistemicViewing and SHALL:
  • document the shape of the CorrespondenceModel,
  • describe how witness epistemes ensure oplax naturality of compositions.

CC‑A.6.3‑6 - Separation from Retargeting and Mechanisms.

• Any species that may change entityOfConcernRef is not a conformant EpistemicViewing; it MUST be treated as U.EpistemicRetargeting (A.6.4) or as a different pattern.
• Any species that performs measurements, actuation, or other side‑effects MUST be declared as U.Mechanism/U.WorkEnactment and cannot be an EpistemicViewing.

#Mini-checklist (for defining a view)

When you introduce a new “view” in FPF, check:

1. Same EntityOfConcern? Does entityOfConcernRef stay the same? If not, this is Retargeting, not Viewing.

2. Which slots move? Have you listed exactly which SlotKinds you read/write, and shown that EntityOfConcernSlot is read‑only?

3. Conservative? Can you explain, in your discipline’s terms, why the view does not introduce new claims about the same EntityOfConcern?

4. Profile? Is this a self‑contained projection (U.DirectEpistemicViewing) or does it depend on a CorrespondenceModel (U.CorrespondenceEpistemicViewing)?

5. Context & viewpoint? Have you stated:

   • the EntityOfConcernClass for EntityOfConcernSlot,
   • the contexts/ReferencePlanes you assume,
   • and the viewpoint bundle (if any) you operate under?

If all answers are crisp and the invariants EV-0...EV-6 are satisfied, the pattern is a good candidate for U.EpistemicViewing.

#A.6.3:End

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