#U.EpistemicViewing — describedEntity-Preserving Morphism

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

One‑line summary. U.EpistemicViewing is the describedEntity‑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 occupant of DescribedEntitySlot in C.2.1).

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/E.10.D2 (I/D/S discipline, DescriptionContext); C.2.1 U.Episteme — Epistemes and their slot graph; 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 of the same knowledge artefact:

• 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/specification;
• an LLM‑friendly episteme derived from a symbolic specification (or vice versa), preserving what system is being described.

#Keywords

• episteme
• view
• EpistemicViewing
• describedEntity preservation
• ClaimGraph
• Viewpoint
• RepresentationScheme
• CorrespondenceModel
• Direct vs Correspondence Viewing
• optics
• displayed fibration.

#Relations

#Content

#Problem frame

Engineers and researchers constantly need views of the same knowledge artefact:

• 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/specification;
• 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 which intend to:

• keep the DescribedEntity fixed (DescribedEntitySlot 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 entity and grounding holon.

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

• effect‑free (no Work/Mechanism side‑effects),
• describedEntity‑preserving (no silent retargeting),
• conservative (no new intensional commitments about the same entity),
• and functorial (compose cleanly in multi‑step pipelines).

#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 object‑of‑talk (retargeting). A Fourier‑style transform or a StructuralReinterpretation in E.TGA can quietly drift from “view of S” into “view of a different S′”, without declaring a KindBridge.

2. “View” vs “viewpoint” vs “surface” 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 surface (rendered document or GUI). Without a clear episteme‑level notion of viewing, MVPK and E.17.0 cannot cleanly separate these layers.

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

   • change describedEntityRef (switching to a subsystem or a function),
   • change groundingHolonRef (different plant or runtime),
   • or smuggle in new intensional claims. Without explicit laws on 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 over the same described entity (α : 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 support degrade.

#Forces

• Same entity, different concerns. Stakeholders want different slices of the same description/specification, sometimes under different viewpoints, without re‑identifying the entity (system, method, role, service) being described.

• 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 must be supported, but with different obligations.

• Conservativity vs expressivity. A view must not introduce new commitments about the described entity, 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.

• I/D/S strictness. …Description and …Spec are epistemes with DescriptionContext = ⟨DescribedEntityRef, BoundedContextRef, ViewpointRef⟩. Viewing must work over these DescriptionContexts without collapsing Intension (I) into episteme or confusing D/S with publication surfaces.

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

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

#Informal definition

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

• takes an input episteme X and produces an output episteme Y,
• preserves the occupant of DescribedEntitySlot (describedEntityRef(Y) = describedEntityRef(X)),
• may refine or re‑express content : U.ClaimGraph, viewpointRef, representationSchemeRef, and referenceScheme,
• is effect‑free and conservative (no new intensional claims about the same described entity),
• and composes functorially with other epistemic viewings.

In C.2.1 terms U.EpistemicViewing behaves like a lens/optic over the episteme slot graph: it focuses on some SlotKinds (typically ClaimGraphSlot, ViewpointSlot, RepresentationSchemeSlot, ReferenceSchemeSlot) while preserving DescribedEntitySlot (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⟩      // carrier 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 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),
  • 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 describedEntityChangeMode = 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 occupant of DescribedEntitySlot is unchanged.

#Laws (EV‑0…EV‑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.

EV‑0 - Species & DescribedEntityChangeMode.

• Any morphism v:X→Y declared as U.EpistemicViewing MUST:
  • be a species of U.EffectFreeEpistemicMorphing (A.6.2), and
  • declare describedEntityChangeMode(v) = preserve.
• Consequently:
  • DescribedEntitySlot has the same ValueKind and RefKind in the episteme kind of X and Y (same EoIClass ⊑ U.Entity);
  • describedEntityRef(Y) = describedEntityRef(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 (DescribedEntitySlot, 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. At the SlotKind level:

   • DescribedEntitySlot is read‑only (no change in describedEntityRef).
   • 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 = ⟨DescribedEntityRef, BoundedContextRef, ViewpointRef⟩. EpistemicViewing MUST:

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

EV‑2 - Effect‑free boundary (over EpistemeSlotGraph). 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 publishing to surfaces),
  • 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 artefacts consumed by the EpistemicViewing morphism.

EV‑3 - No new intensional claims about the same DescribedEntity.

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

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

Then:

• The set of claims about <describedEntityRef, groundingHolonRef> obtained by reading content_Y through referenceScheme_Y MUST NOT strictly extend what is already entailed, in KD‑CAL/LOG‑CAL, by content_X read 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 same described entity are introduced.
• Any intended strengthening of behavioural or structural commitments about the same entity is not a valid EpistemicViewing; it must be modelled either as:
  • a change in Intension (new D/S pair under A.7/E.10.D2), or
  • an A.6.4 U.EpistemicRetargeting plus a new Intension.

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 objects) that squares commute up to declared isomorphism (oplax naturality is allowed, but corrections are deterministic and reproducible),
   • describedEntityRef and groundingHolonRef remain as in EV‑1; any transfer across contexts/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:

• describedEntityRef,
• 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 DescribedEntity 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 EoIClass ⊑ U.Entity (ValueKind of DescribedEntitySlot),
   • permitted groundingHolonRef classes and ReferencePlanes,
   • admissible viewpointRef ranges (possibly a named U.ViewpointBundle),
   • supported representationSchemeRef families.
2. For D/S epistemes in a U.MultiViewDescribing family (E.17.0):
   • preserve DescribedEntityRef 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 DescribedEntity (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 describedEntityRef 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‑level artefact, 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 constructions of new Intensions.

#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:
  • describedEntityRef(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:
  • describedEntityRef(Y) = describedEntityRef(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:

• describedEntityChangeMode = 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 describedEntityRef (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 laws.

#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 describedEntityRef 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:
  • describedEntityRef(Y) = describedEntityRef(R) = describedEntityRef(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 EpistemeSlotGraph.

#Consequences

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

  • “view of the same entity” 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 I/D/S discipline.

• Slot‑level 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 DescribedEntitySlot is preserved. This removes ambiguity around “subject/object” changes and supports 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‑interest;
  • 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 described entities Ref via α : Ep → Ref. EpistemicViewing corresponds to vertical morphisms that preserve α. Their behaviour closely tracks profunctor optics: the DescribedEntitySlot 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 laws 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 artefacts, 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 in intensional terms (no new commitments),
  • any strengthening or change of described entity is explicitly modelled as retargeting or Intension 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 laws.

#Conformance checklist (normative)

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

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

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

• list the SlotKinds it reads (typically DescribedEntitySlot, GroundingHolonSlot, ClaimGraphSlot, ViewpointSlot, RepresentationSchemeSlot, ReferenceSchemeSlot),
• list the SlotKinds it writes (typically ClaimGraphSlot, optionally ViewpointSlot, RepresentationSchemeSlot, ReferenceSchemeSlot, and meta),
• assert explicitly that DescribedEntitySlot 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 D/S epistemes). When domain/codomain epistemes are …Description/…Spec:

• viewing laws SHALL be phrased in terms of DescriptionContext = ⟨DescribedEntityRef, BoundedContextRef, ViewpointRef⟩,
• DescribedEntityRef 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, authoring SHALL provide:

• a clear statement of what counts as a new intensional claim in the relevant discipline,
• and a sketch of how conservativity (EV‑3) is checked or approximated (e.g. via KD‑CAL entailment, proof obligations, 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 describedEntityRef 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 authors)

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

1. Same described entity? Does describedEntityRef 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 DescribedEntitySlot is read‑only?

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

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 EoIClass for DescribedEntitySlot,
   • the contexts/ReferencePlanes you assume,
   • and the viewpoint bundle (if any) you operate under?

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

#A.6.3:End