FPF Reference

Multi‑View Publication Kit (for Morphisms)

E.17 · Stable · Part E - The FPF Constitution and Authoring Guides

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

At a glance. Use E.17 when one claim-bearing morphism or functional relation must be published in several readable faces for different readers without changing the underlying claim.

Use this when. The engineering team needs a plain view, technical card, interoperability card, or assurance lane that helps people read, inspect, exchange, or cite the same source-backed relation without turning the face into work occurrence, evidence, gate passage, engineering justification, control architecture, or release permission by presentation alone.

First output. One source-pinned publication face with the underlying U.Episteme / D/S episteme, publication scope, face kind, supported use, and any required project-source exit named only as far as the current use needs.

Working action spine. Publish one morphism face -> separate source episteme/view, face, carrier, supported use, and project-source exit -> use the face for inspection, source-finding, review, exchange, or planning preparation -> output one source-pinned publication face -> use the exact neighboring source pattern if work, evidence, gate, engineering-justification, control, or release use becomes live.

Ordinary formality rule. If the face only supports orientation, source-finding, review, comparison, or planning preparation, keep the publication light: one pinned face or compact card plus a clear supported-use line is enough.

Load-bearing formality rule. Add the fuller MVPK record only when the face will support external-impact reliance, cross-context exchange, evidence citation, gate/release pressure, engineering-justification use, disputed interpretation, or another use where a concrete overclaim would change the next engineering move.

Stop condition. Do not create a new publication record merely because a face exists. Stop when the current face changes no next engineering move and blocks no concrete overclaim.

Supported-use examples.

Supported project useSource-finding or reversible probeUnsupported use
A source-pinned MVPK face lets the team inspect one morphism, review it, exchange it, or prepare planning without changing the claim.A face helps planning support, but the team still needs to recover the exact method, evidence, gate, control, or carrier source before stronger use.A face, screen, export, or diagram is treated as performed work, gate passage, evidence, engineering justification, supervisory/control relation, or release permission by layout/readability alone.

Boundary aid pointer. If one encountered publication-facing item is easy to read as work, evidence, gate, approval, status, explanation, comparison, or weaker rendering, handle one live claim/effect at a time using E.17:5.1d.

Here in the first-screen read, keep only the MVPK publication move: one source-pinned face, one supported use, and exact neighboring source exits only as far as the current use needs.

Not this pattern when. Not this pattern when the live issue is performed U.Work, a work plan, evidence/provenance path, engineering justification, gate decision, control architecture, carrier/OCR work, or a weaker rendering that needs its own fuller-source return. Use the project source pattern that governs that issue.

Tech‑name: U.MultiViewPublicationKit (MVPK) Plain‑name: Multi‑view publication kit (for morphisms) Signature (conceptual form): MVPK : (U.Morphism, Σ_viewpoints) ↦ U.ViewFamily with per‑viewpoint components ViewObj_s : U.Object → U.ViewObj_s and Emit_s(-) : U.Morphism → U.ViewMorph_s, such that (ViewObj_s, Emit_s) forms a functor U → View_s(U). For each s ⪯ t, a reindexing coercion PromoteView[s→t]_X : ViewObj_s(X) → ViewObj_t(X) exists and is natural in X: for every f : X → Y, PromoteView[s→t]_Y ∘ Emit_s(f) = Emit_t(f) ∘ PromoteView[s→t]_X (see Rules §6.2). Notation: Σ_viewpoints is abbreviated as Σ where convenient. Twin‑register aliases (naming discipline): • Tech: Emit_PlainView, Emit_TechCard, Emit_InteropCard, Emit_AssuranceLane; PromoteView[s→t]_-. • Plain: PlainView(x), TechCard(x), InteropCard(x), AssuranceLane(x); “Promote to t”.

USM binding (overview): PublicationScope is a USM‑class object that parameterizes MVPK; see §5.0. Episteme lane. MVPK treats each face as a U.View in the sense of C.2.1/E.17.0 (species U.EpistemeView). For a morphism f, every Emit_s(f) is such a view whose DescribedEntitySlot/DescriptionContext target is f : U.Morphism and whose viewpointRef is a publication U.Viewpoint (PublicationVPId) drawn from a U.ViewpointBundle (E.17.1/E.17.2). Slot discipline (ViewSlot/ViewRef) is inherited from C.2.1/A.6.5 and is not redefined in MVPK.

Provide a disciplined, compositional way to publish morphisms (arrows) across multiple didactic faces (views/cards) without adding semantics, while keeping viewpoints (the specifications that constrain views) explicit and auditable. Authors get a small view‑pack that, when applied to any U.Morphism (including compositions), yields a family of views that commute with arrow composition and respect edition/measurement pinning (Part F/G).

Keywords

  • publication
  • U.View/U.EpistemeView
  • multi-view
  • viewpoints
  • PublicationScope (USM)
  • PlainView/TechCard/InteropCard/AssuranceLane
  • functorial views
  • reindexing (PromoteView[s→t])
  • Publication characteristics (PC.Number
  • PC.EvidenceBinding
  • PC.ComparatorSetRef
  • PC.CharacteristicSpaceRef)
  • CHR/UNM/CG-Spec anchoring
  • UTS
  • pin discipline
  • D/S→Surface (no I→D/D→S).

Relations

E.17builds onStrict Distinction (Clarity Lattice)
E.17builds onIntension–Description–Specification Discipline (I/D/S)
E.17builds onU.EffectFreeEpistemicMorphing — Effect-Free Morphisms of Epistemes
E.17builds onU.EpistemicViewing — describedEntity-Preserving Morphism
E.17builds onU.Episteme — Epistemes and their slot graph
E.17builds onU.MultiViewDescribing — Viewpoints, Views & Correspondences
E.17builds onU.ViewpointBundleLibrary — Reusable Viewpoint Bundles
E.17builds onTEVB — Typical Engineering Viewpoints Bundle
E.17builds onFPF Authoring Conventions and Style Guide
E.17builds onLEX-BUNDLE: Unified Lexical Rules for FPF
E.17coordinates withTransduction Graph Architecture (E.TGA)
E.17constrainsE.17:5.1d
E.17constrainsWork-Relevant Source Restoration
E.17constrainsRole-Method-Work Alignment (Contextual Enactment)
E.17constrainsU.Work: The Record of Occurrence
E.17constrainsEvidence Graph Referring (C-4)
E.17constrainsTrust & Assurance Calculus (F–G–R with Congruence)
E.17constrainsU.Flow.ConstraintValidity — Eulerian
E.17constrainsGateProfilization: OperationalGate(profile) (GateFit core)
E.17constrainsConservativeRetextualization - same-described-entity textual re-expression
E.17constrainsRepresentationTransduction - same-described-entity representation-scheme transition
E.17constrainsControlled Semantic Coarsening
E.17constrainsExplanationFaithfulnessProfile - explanation classification over existing MVPK faces
E.17constrainsComparativeReading - bounded comparative reading over comparative review units
E.17constrainsU.EpistemicRetargeting — describedEntity-Retargeting Morphism
E.17constrainsStrict Distinction (Clarity Lattice)
E.17constrainsU.CrossContextSamenessDisambiguation — Repairing cross-context “same / equivalent / align” via explicit Bridges (RPR-XCTX)
E.17constrainsAlignment & Bridge across Contexts
E.17constrainsBridge Stance Overlay
E.17constrainsMulti‑View Publication Kit (for Morphisms)
E.17coordinates withAlignment & Bridge across Contexts
E.17coordinates withBridge Stance Overlay
E.17coordinates withU.CrossContextSamenessDisambiguation — Repairing cross-context “same / equivalent / align” via explicit Bridges (RPR-XCTX)
E.17outline childU.MultiViewDescribing — Viewpoints, Views & Correspondences
E.17outline childU.ViewpointBundleLibrary — Reusable Viewpoint Bundles
E.17outline childTEVB — Typical Engineering Viewpoints Bundle
E.17outline childExplanationFaithfulnessProfile - explanation classification over existing MVPK faces
E.17outline childAuthoredUnitDiscipline - problem-pressure classification for one authored-readable unit with unstable described-entity or carried-move reading
E.17explicit referenceU.Episteme — Epistemes and their slot graph
E.17explicit referenceU.MultiViewDescribing — Viewpoints, Views & Correspondences
E.17explicit referenceU.ViewpointBundleLibrary — Reusable Viewpoint Bundles
E.17explicit referenceTEVB — Typical Engineering Viewpoints Bundle
E.17explicit referenceU.RelationSlotDiscipline - SlotKind / ValueKind / RefKind discipline for n‑ary relations (with slot‑operation lexicon)
E.17explicit referenceU.EpistemicViewing — describedEntity-Preserving Morphism
E.17explicit referenceStrict Distinction (Clarity Lattice)
E.17explicit referenceIntension–Description–Specification Discipline (I/D/S)
E.17explicit referenceU.EffectFreeEpistemicMorphing — Effect-Free Morphisms of Epistemes
E.17explicit referenceU.EpistemicRetargeting — describedEntity-Retargeting Morphism
E.17explicit referenceBoundary Norm Square (Laws / Admissibility / Deontics / Work-Effects)
E.17explicit referenceContract Unpacking for Boundaries
E.17explicit referenceTransduction Graph Architecture (E.TGA)
E.17explicit referenceWork-Relevant Source Restoration
E.17explicit referenceRole-Method-Work Alignment (Contextual Enactment)
E.17explicit referenceEvidence Graph Referring (C-4)
E.17explicit referenceTrust & Assurance Calculus (F–G–R with Congruence)
E.17explicit referenceU.Flow.ConstraintValidity — Eulerian
E.17explicit referenceGateProfilization: OperationalGate(profile) (GateFit core)
E.17explicit referenceSupervisor–Subholon Feedback Loop
E.17explicit referenceConservativeRetextualization - same-described-entity textual re-expression
E.17explicit referenceRepresentationTransduction - same-described-entity representation-scheme transition
E.17explicit referenceControlled Semantic Coarsening
E.17explicit referenceU.Work: The Record of Occurrence
E.17explicit referenceU.Commitment: Deontic Commitment Object
E.17explicit referenceU.SpeechAct: Communicative Work Object
E.17explicit referenceU.CrossContextSamenessDisambiguation — Repairing cross-context “same / equivalent / align” via explicit Bridges (RPR-XCTX)
E.17explicit referenceAlignment & Bridge across Contexts
E.17explicit referenceBridge Stance Overlay
E.17explicit referenceExplanationFaithfulnessProfile - explanation classification over existing MVPK faces
E.17explicit referenceComparativeReading - bounded comparative reading over comparative review units
E.17explicit referenceCharacteristicSpace & Dynamics Hook (A.CHR-SPACE)
E.17explicit referenceLEX-BUNDLE: Unified Lexical Rules for FPF
E.17explicit referenceFPF Authoring Conventions and Style Guide

Content

Intent

Provide a disciplined, compositional way to publish morphisms (arrows) across multiple didactic faces (views/cards) without adding semantics, while keeping viewpoints (the specifications that constrain views) explicit and auditable. Authors get a small view‑pack that, when applied to any U.Morphism (including compositions), yields a family of views that commute with arrow composition and respect edition/measurement pinning (Part F/G).

Problem frame

  • Teams routinely need several faces of the same arrow: a TechCard for the catalog, an InteropCard for machine exchange, a PlainView for narrative, and an AssuranceLane for evidence.
  • Informal “renderings” quietly drift semantics; composite arrows are often published piecemeal, breaking traceability; evidence forgets unit/scale/edition pins.
  • “View” and “viewpoint” are blurred in practice; authors conflate publication with mechanism.
  • L‑SURF requires SurfaceKind token discipline; Core allows only PublicationSurface/InteropSurface; faces are …View / …Card / …Lane (no ad‑hoc …Surface kinds).

MVPK fixes this by making publication a typed, functorial projection from existing D/S‑epistemes via species of U.EpistemicViewing (A.6.3/E.17.0, A.7 §5.9/E.10.D2) subject to explicit viewpoint specs and pinning guards. Part E is conceptual: no machine‑exchange formats are specified here.

Problem

  1. Semantic drift in publication. Unchecked “presentations” introduce claims not present in the D/S‑epistemes about the arrow (epistemes with DescriptionContext = ⟨DescribedEntityRef, BoundedContextRef, ViewpointRef⟩ in the sense of E.10.D2/E.17.0).
  2. Non‑compositionality. Publishing g∘f yields faces that do not match composing the faces of f and g.
  3. View vs viewpoint confusion. A single template is treated as “the view”, with no declared concerns or conformance rules.
  4. Unpinned numbers. Numeric claims lack unit/scale/reference‑plane and edition pins (Part F/G), undermining auditability.

Forces

ForceTension
Compositionality vs legibilityPreserve arrow invariants across views ↔ keep each view didactic and audience‑appropriate.
Neutral naming vs domain idiomsUse vocabulary stable across domains ↔ allow local templates (SOPs, APIs, checklists).
Publication-face independence (A.7)Publication must not mutate I/D/S semantics ↔ authors expect rich presentations.
Evidence disciplineViews must cite CG‑Spec/CHR anchors ↔ authors want compact cards.

Solution — the MVPK Kit

USM anchoring (normative)

  • PublicationScope (USM). U.PublicationScope is defined in USM (A.2.6 §6.5) analogously to U.WorkScope and U.ClaimScope as a set‑valued scope object over U.ContextSlice. In MVPK, every emitted U.View SHALL declare a U.PublicationScope that bounds where that face is admissible.
    • Non‑overload rule. U.PublicationScope MUST NOT encode viewpoint choice, MVPK profile selection, or Publication Characteristics (PC); those are governed by PublicationVPId/U.Viewpoint and MVPK profile rules (§5.1/§5.2/§5.5).
  • Scope lineage. U.PublicationScope participates in the same USM lineage regime as U.WorkScope/U.ClaimScope (Δ‑moves, editioning and migration rules); MVPK emits faces under a declared PublicationScopeId.
  • MVPK profile (kit configuration). The canonical MVPK profiles (MVPK‑Min/Lite/SetReady/Max) fix:
    • (a) the viewpoint index Σ and its partial order ⪯,
    • (b) the admissible Publication characteristics (PC) and required pinning requirements,
    • (c) any cross‑Context/plane constraints (Bridge/CL policies) applicable to emitted faces.
  • MVPK face-name quartet. The canonical MVPK-Max profile enumerates exactly four face kinds: PlainView (P), TechCard (T), InteropCard (I), AssuranceLane (A). MVPK face ids, SurfaceKind values, claim quadrants, governingPatternRef, and local field values must not use an L/P/D/E mnemonic; use the P/T/I/A face-name initials only when an abbreviation is unavoidable.

Terminology (normative)

  • View (U.View): an episteme-lane view (U.EpistemeView in the sense of C.2.1/E.17.0) produced under a publication viewpoint. In MVPK each face (PlainView, TechCard, InteropCard, AssuranceLane) is such a U.View whose DescribedEntitySlot/DescriptionContext target is a U.Morphism and whose viewpointRef is a publication U.Viewpoint. Every MVPK U.View SHALL declare: SurfaceKind ∈ {PublicationSurface, InteropSurface}, PublicationVPId : U.ViewpointRef, references to the underlying D/S‑epistemes produced by Describe_ID/Specify_DS in A.7/E.10.D2, and a U.PublicationScope (USM §6.5). Any carrier rendering is separate U.Work on SCR/RSCR carriers and is not part of U.View.
  • Publication vs presentation vs rendering vs representation (guard):
    • Publication = typed projection from existing D/S‑epistemes about a morphism into a U.View governed by a PublicationSurface/InteropSurface SurfaceKind via species of U.EpistemicViewing (A.6.3) under the I/D/S discipline of A.7/E.10.D2.
    • Presentation = rhetorical arrangement of a published carrier; notation-neutral, adds no claims and is not a SurfaceKind.
    • Rendering = display/layout of a carrier, purely graphical/formatting; U.Work on carriers (A.7), not a SurfaceKind.
    • Representation = episteme↔referent relation (C.2.1/A.6.2–A.6.4); not a publication operation and not a SurfaceKind operation. Use publication and view here; treat presentation/rendering as U.Work on carriers (A.7).
  • ISO mapping note. ISO viewpoint → PublicationVPId (publication lane); engineering viewpoint → EngineeringVPId (E.TGA E.18:5.12). An ISO view may be a single MVPK face; “bundles” are packaging only.
  • No‑mechanism equivalence: MVPK is not a mechanism; any operational toil (build/render/upload) is separate U.Work by a system on carriers (A.7; see Rule 5 — No Γ-leakage in §6).
  • ViewpointSpec (U.Viewpoint) — a typed specification that declares stakeholders, concerns, conformance rules, allowed Publication Characteristics, and pinning requirements per profile. The index set Σ consists of identifiers of U.Viewpoint instances, typically drawn from U.ViewpointBundle species (E.17.1/E.17.2) (see §5.3).
  • Explanation-use profile values. Existing faces may state an explanation-use profile value as SourcePinnedExplanation, SourceLinkedExplanationReconstruction, DidacticRetelling, or SpeculativeRetelling, but those are local profile values over already existing MVPK faces rather than new face kinds, explanation kinds, or carrier-rendering kinds. Per-face pins, provenance anchors, and no-new-L/A/D/E discipline still apply.

Episteme-publication lane binding (normative)

For functional-description publications, MVPK governs the publication lane only.

Publication lane. A principle scheme, functional diagram, comparison table, screen, export, scenario, explanation, or code-like method description may support interpretation, source-finding, comparison, selected-method inspection, or work-planning support.

Unsupported neighboring claims. The publication does not by itself assert performed U.Work, gate passage, evidence, engineering justification, supervisory/control relation, release permission, or a new TGA kind.

Interface/protocol proximity. When interface, protocol, schema, boundary, or API wording appears beside a functional-flow description, keep the operational boundary/interface/protocol claim with its own project claim set and source record, governed by the relevant FPF kind such as A.6.B, A.6.C, or E.18. Do not absorb it into the functional-flow publication by layout proximity.

Retargeting. If the publication changes the governed target from an already described component, process, material artifact, or source claim into a functional, control, or flow architecture claim, this is not a same-entity publication/use change. Use A.6.4, OntologicalReframing, or E.18 as applicable.

Source recovery. When a requested use requires a project source record beyond the publication face, the engineer first recovers the corresponding existing project source if one already carries the needed claim:

  • work-relevant source restoration under A.15.4;
  • method/work-plan/work-result material under A.15;
  • evidence/provenance path under A.10;
  • engineering-justification record under B.3;
  • constraint or gate decision under A.20 / A.21;
  • supervisory/control architecture record under B.2.5;
  • carrier/export/OCR/front-end record under A.7;
  • same-entity textual, representation, or weaker-rendering relation under A.6.3.CR / A.6.3.RT / A.6.3.CSC.

No backdating. If no existing project source carries a claim that was supposed to be already supported, do not create a backdated source. Create only a prospective repair request, decision request, future work-plan record, or explicit source-gap record, and treat the earlier claim/effect as unsupported until the required source exists.

Ordinary orientation and source-finding can stay as an inline note.

Functional-description guard (CC-MVPK-FD). A functional-description publication face must separate the source U.Episteme / episteme-lane U.View, the MVPK face, any live carrier/rendering work, the supported engineering use, and unsupported neighboring use. The guard applies only when a functional-description face is present; it is not the first universal MVPK conformance gate.

MVPK inherits the C.2.1 distinction between U.Episteme, U.EpistemePublication, publication form, U.View, carrier, and authority-reference relation. MVPK does not introduce a generic object kind for semiosis and does not let a publication face act as governingPatternRef, authoritySourceRef, or the source claim for a claim.

When a morphism publication is encountered or reused, name the relevant lane before relying on it:

  • the underlying U.Episteme / D/S episteme whose ClaimGraph is being projected;
  • the U.EpistemePublication or governed U.Episteme publication when the episteme is available as a published episteme;
  • the publication form used by the local pattern, if one is live;
  • the U.View / MVPK face (PlainView, TechCard, InteropCard, AssuranceLane) that renders the publication for a viewpoint;
  • the SCR/RSCR carrier or rendering work that holds or displays it;
  • the project source record or authority-reference relation when the next work/reliance claim depends on named authority support.

The practical payoff is that a reader can recover exactly what may be relied on: the episteme claim, the published form, the view, the carrier, the project source record, or the authority-reference relation. A dashboard tile, generated explanation, card face, credential view, or carrier can guide source-finding, but it does not by itself become the source claim/effect, gate decision, evidence relation, assurance claim, role/status, work occurrence, or permission.

Source-exposure rule. A publication face, carrier, rendering, dashboard tile, credential/status view, comparison unit, explanation rendering, signed decision memo, release decision record, approval speech-act publication, or gate dashboard may expose, cite, or carry a typed project source record only when that record is recoverable under its governing FPF pattern or project source relation. It does not become that source record by readability, layout, title, color, fluency, proximity, copying, generation, or reuse. When the exposed record is a real SpeechAct, GateDecision, evidence path, credential/status source, U.Work occurrence record, U.Episteme, or U.EpistemePublication, rely on that typed and recoverable source record and its FPF-governed source relation; otherwise treat the face/carrier/display/rendering as orientation or source-finding only.

No retroactive source creation. When required source support is missing, a new record can be only a prospective repair request, future decision request, prospective work-plan record, or explicit source-gap record. It must not be read as earlier evidence, approval, gate passage, instituting speech act, U.Work occurrence, release permission, engineering justification, or assurance for the unsupported past claim/effect.

Shared source-support posture vocabulary

Use this vocabulary when a publication face, rendering, generated text, comparison note, weaker rendering, source-finding cue, or authority-looking display may be over-read as carrying stronger source support than it actually carries. The vocabulary names support posture for one claim/use; it is not a score, not a proof class, not an evidence relation by itself, not an authority source, and not a gate or work state.

Source-support postureMeaning for the local claim/use
source-pointer-onlyThe item points to a possible source but does not show that the source is available, was used, or supports the claim.
source-availableThe cited source can be recovered or inspected for the current use. This does not yet show that the rendering used it correctly.
source-retrievedThe cited source has actually been recovered for the current check. This still does not show that it was used correctly or supports the local claim.
source-usedThe inspectable generation, rewrite, rendering, comparison, or work-reliance path actually used the named source rather than only similar background. If the path is unavailable, treat the item as pointer-only or orientation-only until a source-use path is recovered.
source-faithfulThe item stays within the source claim/support relation for the stated use; omissions, weakening, and additions are visible enough to inspect.
claim-supportedThe local claim is recoverable from the source, declared correspondence support, or required project source record for the stated use.
claim-unsupportedThe local claim is not recoverable from the source support currently available.
claim-contradictedThe local claim conflicts with the available source support.
claim-plausible-onlyThe claim may sound reasonable, but the source support currently available does not carry it.
source-omittedRelevant source material, qualifier, condition, alternative, caveat, or uncertainty is missing from the item.
source-weakenedThe item intentionally carries less detail, narrower scope, redaction, aggregation, or other attenuation than the fuller source.
claim-strengthenedThe item turns a source possibility, hypothesis, bounded condition, low-confidence statement, narrower permission, or source-finding cue into a stronger claim/use.
added-linkageThe item adds a causal, explanatory, bridge, comparison, work, evidence, gate, or authority relation not already carried by the source support.
independent-verification-presentA separate check, test, evidence path, or project source record supports the local claim/use independently of the item.
supported-for-this-useThe item is admissible for the named use only; stronger downstream use still needs its own source support.
downstream-use-forbiddenThe item must not be used for the named downstream claim/effect because the needed source support is absent, weaker, contradicted, or outside scope.
reopen-trigger-presentA stated change, dispute, use escalation, source update, context shift, missing support, or contradiction forces return to the fuller source or the governing project source record.

Patterns may use shorter local field names such as sourceSupportPosture, explanationSourcePosture, or representationValiditySupportPosture when the local object is clear. Comparative patterns split source-support posture from comparative-relation posture instead of using one overloaded field. The local field must still be interpretable through the vocabulary above, and the supported use must be named beside it when downstream reliance could change.

For ordinary use, only name the posture distinction that changes the next admissible use. The common light states are source-pointer-only, supported-for-this-use, downstream-use-forbidden, and reopen-trigger-present. The vocabulary is not an ordered scale or maturity ladder. If independent-verification-present is relied on, name the separate governing pattern, evidence path, gate record, work record, bridge card, or other project source record that performs that independent support.

Shared use-boundary terms

Use these terms when a publication face, rendering, weaker rendering, explanation, comparison note, source-finding cue, or authority-looking display may be read beyond the support it carries. Define them once here and link back to this section from local patterns instead of minting local synonyms.

TermMeaning for FPF use
orientation useThe item helps a reader find, inspect, triage, compare, teach, discuss, or prepare planning while the item itself does not support a downstream work/reliance claim/effect.
reliance useThe item is used as support for an engineering claim/effect that changes a next work/reliance move, such as method choice, work plan, performed-work claim, release, gate, approval, role/status, evidence, assurance, or external-impact move.
work/reliance claim/effectA claim or instituted effect about method selection, selected method, U.WorkPlan, performed U.Work, work result, gate/release, role/status, evidence, assurance, boundary/policy effect, or another exact project source relation.
operative claimA claim whose acceptance would change the next admissible work/reliance move, the project source record to recover, or the cross-context use of the item. Explanatory prose, examples, and source-finding cues are not operative claims unless they are used that way.
unsupported downstream useA stronger use that the current item/source relation does not carry. It requires narrowing the use, returning to a fuller source, recovering source support, or moving to the exact neighboring FPF pattern/source relation that governs the stronger claim/effect.
reopen triggerA dispute, use escalation, missing/stale/contradictory source support, source update, context/window change, or stronger claim/effect that requires fuller-source return, source refresh, re-expansion, or use of the governing pattern.
authority-looking caseA recognition phrase for an encountered item that may be over-read as permission, approval, evidence, gate passage, role/status, work occurrence, assurance, or release support. It is not a U.* kind, not a source record, and not a governing pattern.

Compact Boundary Aid For The Live Claim/Effect

When a readable artifact, publication face, rendering, weaker rendering, explanation, comparison note, dashboard tile, credential/status view, carrier, or generated item creates more than one possible reading, separate the live claim/effect being used now and cite the exact governing source relation for that claim/effect. This is a compact boundary aid, not a standing selection guide, process order, software call path, or artifact taxonomy. The same encountered item may expose several source records; handle one live claim/effect at a time instead of pretending there is one overall source relation for the artifact.

Live claim/effect questionApply or recover
Is the item being used to guide a work/reliance move by appearance, while the acting user still needs the exact project source record before proceeding?A.15.4 for the restoration step; the recovered source may then be A.15, A.15.1, A.10, B.3, A.20, A.21, A.2.8, A.2.9, A.6.B, or another exact project source relation. If that exact source is already the live question, use it directly.
Is the item being used as evidence, provenance, attestation, currentness, freshness, or claim-bound support?A.10 evidence/provenance/currentness path for the exact claim.
Is the item being used as engineering justification, assurance, confidence, readiness, or limitations support?B.3 assurance/engineering-justification claim with evidence, limits, and decay explicit.
Is the item being used as gate passage, constraint validity, adjudication, or release decision support?A.20 / A.21 project records, including gate/constraint profile, decision/log, scope, window, and replay/freshness support.
Is it the same described entity with textual restatement only?A.6.3.CR Conservative Retextualization.
Is it the same described entity with representation scheme or reasoning medium changed?A.6.3.RT Representation Transduction.
Is it deliberately weaker and useful only under narrower supported use, unsupported downstream use, and fuller-source reopen?A.6.3.CSC Controlled Semantic Coarsening.
Is the primary issue explanation-facing rendering class on an existing MVPK face?E.17.EFP ExplanationFaithfulnessProfile.
Is the primary issue one bounded comparative review unit over sources?E.17.ID.CR ComparativeReading.
Did the described entity, target, ontology frame, or governed claim change?A.6.4, OntologicalReframing, or the exact retargeting/reframing pattern.
Is the item being used as bridge, substitution, equivalence, same/equivalent/align/map wording, or cross-context comparison support?Use Part F / A.6.9 for repairing "same / equivalent / align / map" wording into explicit bridge work; use F.9 / F.9.1 for Bridge Cards, bridge kind, direction, CL, loss notes, supported use, and stance overlays. Comparison alone is not a bridge.
Is the live question carrier, export, OCR, screen, front-end behavior, or work on carriers?A.7 and the exact carrier/front-end/work-on-carrier source record.

Evidence-path boundary. An A.10 evidence, provenance, attestation, freshness, or currentness path supports only the exact claim it instantiates. It does not approve or authorize work, pass a gate, perform work, supply release permission, or raise assurance/engineering-justification posture unless the project source relation that carries that downstream claim is also instantiated, such as A.15.4, A.15, A.20, A.21, or B.3.

Gate-display boundary. A dashboard tile, status view, or release screen may expose a gate decision only when the GateDecisionRef, gate or constraint profile/version, target release/work scope, time window, currentness/freshness or replay support, and evidence path are recoverable. Without that exact project source support, the display remains orientation or source-finding only; it is not a gate decision, gate passage, release permission, or performed-work record by color, label, layout, or proximity.

Local review fields are not FPF kinds

Local review fields and values in CR, RT, CSC, EFP, ID.CR, or a neighboring publication-use pattern are local review aids for one case. They are not U.Kind, SurfaceKind, RelationKind, KindBridge, EvidenceKind, SlotKind, GateDecision, SpeechAct, Commitment, U.Work, publication face, authority source, or project source record unless another governing FPF pattern explicitly instantiates that object. When a local field starts carrying one of those loads, move to or cite the governing FPF source relation that carries it.

Shared anti-overread invariants for publication-facing items

Use the lightest FPF pattern that owns the live claim/effect. Keep any local review field local, preserve weaker admissible use, and move only the unsupported stronger claim to its governing source relation.

No-extra-pattern path. If an artifact only supports ordinary orientation, learning, source-finding, review, comparison, or planning preparation, and no operative work/reliance, evidence, gate, assurance, bridge, source-dispute, or release claim is live, keep the existing publication/source relation and proceed with ordinary use.

Pattern-inflation anti-pattern. Do not open a heavier neighboring pattern merely because the artifact resembles a worked example. Open the neighboring pattern only when a live claim/effect changes the next admissible project move.

Carrier-travel invariant. A copied, exported, screenshotted, summarized, generated, translated, or re-rendered artifact may carry orientation or source-finding cues. It does not carry evidence support, authority support, gate passage, approval, engineering-justification support, work occurrence, currentness, or release support unless the governing project source relation remains recoverable for that exact use.

Derivative-chain decay. A second-order rendering inherits at most the supported use that is explicitly carried from the prior source relation. It does not inherit source faithfulness, source support, currentness, authority support, gate support, work support, or reliance support by default.

Claim-level support only. Do not assign one whole-artifact support posture unless every operative claim in that artifact has the same support relation for the same use and unsupported downstream uses are explicit.

Modality and deontic-force preservation. Publication-facing transformations must preserve possibility, obligation, permission, recommendation status, decision status, confidence, scope, and temporal window when those are load-bearing. If one of these changes, narrow the supported use or hand off to the governing pattern that carries the changed claim/effect.

Reader role is not project role. Reader, audience, target user model, verifier, reviewer, and learner positions do not become project roles, role assignments, decision authority, gate authority, issuer roles, or work roles unless a project source instantiates that role relation.

Source-gap states. When support is missing, say which gap is live: source not named; source named but unavailable; source available but not used; source used but insufficient; source stale or outside its window; source contradicted; source accountable role/register mismatch. Block only the unsupported effect and keep any weaker supported use available.

Metric and display overread. A number, score, percentage, color, rank, confidence value, similarity value, dashboard state, or metric display is orientation only until the measurement source, aggregation rule, validity window, population/scope, calibration or evidence path, and intended use are governed by the exact project source relation. Evidence-like use exits to A.10; assurance-like use exits to B.3; gate-like use exits to A.20 / A.21; work/reliance use exits to A.15.4 and then to the recovered project source; bridge/substitution use exits to F.9 / F.9.1.

World-contact stop. Publication-facing items do not self-refresh after source update, revocation, policy change, system-state change, incident, model update, environmental change, or new external observation. A live outside change requires source refresh, reissued publication, or a new governed project source relation before stronger use continues.

Functional-description boundary. A functional, architectural, descriptive, representational, or explanatory fit claim does not create permission, obligation, approval, gate passage, release support, performed-work evidence, or engineering justification. Those uses require the exact neighboring project source relation.

Mixed bundle no-strongest-reading rule. A bundle with source-pinned, weaker, speculative, didactic, comparison, and evidence-facing parts cannot be read at its strongest member's support level. Each operative claim keeps its own source relation and unsupported downstream use.

Educational usefulness. Didactic, onboarding, tutorial, and workshop usefulness is real orientation support. It is not evidence, gate passage, approval, work occurrence, engineering justification, release permission, or bridge support.

Comparison exposes conflict; it does not adjudicate it. A comparison note may expose contradiction, asymmetry, different foregrounding, or unresolved residue. It does not settle the conflict, select an option, approve release, pass a gate, or create bridge/substitution support unless the governing project source relation carries that result.

Same-artifact multi-reading examples. A green release dashboard can be one MVPK face for source-finding, an A.10 currentness/evidence path when the evidence query is recoverable, an A.21 gate-decision view when the GateDecisionRef is recoverable, or an unsupported release cue when those sources are missing. A generated comparative explanation can be an E.17.EFP explanation-use case, an E.17.ID.CR comparison case, a A.6.3.CR generated-summary case, or source-finding only; it is never all of those at the strongest support level by fluency alone.

Concrete reopen trigger. A reopen trigger must name the condition and the nearest fuller source or governing pattern. A vague "reopen if needed" does not preserve source support.

Allowed SurfaceKind values at Part E (L-SURF discipline)

Part E restricts SurfaceKind values to PublicationSurface and InteropSurface. Concrete publication faces SHALL be named ...View / ...Card / ...Lane.

USM linkage (normative). Every U.View SHALL declare a U.PublicationScope (USM §6.5). For a view about an episteme E: PublicationScope(view_E) ⊆ ClaimScope(E). For a view about a capability C: PublicationScope(view_C) ⊆ WorkScope(C). This is the publication scope of a capability description, not permission to perform work and not evidence that work occurred. Work admissibility still requires A.15.4 source restoration when the view is used for work/reliance, and the A.15 role/method/plan/work source relation for the actor, target, context, scope, and time/window in use. Cross‑context views SHALL cite Bridge + CL; CL penalties apply to R only (scope membership unchanged).

L‑PUBSURF naming discipline

  • Allowed SurfaceKind values: PublicationSurface, InteropSurface.
  • Concrete faces MUST be named …View / …Card / …Lane.
  • The tokens carrier/bearer/holder MUST NOT name a U.View or any publication entity. Use U.View (PlainView / TechCard / InteropCard / AssuranceLane) for conceptual publication faces. Reserve carrier exclusively for SCR/RSCR (symbol/document/data carriers) and U.Work on carriers.
  • Avoid geometric metaphors (axis/dimension) for publication forms; use Characteristic/CharacteristicSpace only when referring to CHR‑MM entities.
  • Non‑collision guard. ViewFamilyId (lexical tag for viewpoint families) MUST NOT be used to name any U.View or SurfaceKind; MVPK face kinds remain {PlainView, TechCard, InteropCard, AssuranceLane} only.

MVPK‑Max viewpoints (normative; exactly four; governed by the MVPK profile):

  • PlainView (explanatory prose view)
  • TechCard (typed catalog card)
  • AssuranceLane (evidence bindings/lanes)
  • InteropCard (conceptual interoperability view; mapping to concrete exchange formats lives in Annex/Interop; Part E does not specify schemas)

AssuranceLane may expose evidence bindings, evidence-carrier references, pins, and presence bits. It is not a B.3 assurance claim, readiness/confidence verdict, engineering-justification record, or evidence-sufficiency result. When a published face is used to raise or lower assurance, readiness, confidence, limitation, or engineering-justification posture, the governing source relation is B.3; the lane only helps recover the cited evidence-binding material.

Lean profiles (small‑team friendly, optional; as MVPK kit profiles):

  • MVPK‑Min (F0–F1): Σ = {PlainView, TechCard‑Lite}. AssuranceLane omitted. No interop face.
  • MVPK‑Lite (F1–F3): Σ = {PlainView, TechCard‑Lite, AssuranceLane‑Lite gated by crossing trigger}. InteropCard only if external consumers exist.
  • MVPK‑SetReady (F3–F5): add InteropCard when replayability or external interchange is required (details outside Part E).
  • Profile‑upgrade triggers: (i) cross‑Context/plane reuse; (ii) QD/OEE replay needs; (iii) external consumption.
  • “‑Lite” variants (definition): A ‑Lite face removes optional fields only (never claims), keeps the same typing as its full counterpart, and MUST retain pins for any numeric content. Upgrading from ‑Lite to full is a monotone add‑fields operation (no retractions).

The kit (constructs)

  1. Object component ViewObj_s for each viewpoint (see §5.1), to make types explicit.
  2. Viewpoint set Σ : FinSet(U.Viewpoint) with declared partial order ⪯ for formality/refinement (default chain: PlainView ⪯ TechCard ⪯ InteropCard; AssuranceLane is an independent evidence-binding face and not ordered with respect to others).
  3. Emitters Emit_s(-) : U.Morphism → U.ViewMorph_s (one per s ∈ Σ).
  4. Coherence (rules and invariants §6) + Pin Characteristics policy (UnitType/ScaleKind/ReferencePlane/EditionId) for any numeric/comparable content, grounded in CHR/UNM.
  5. Interop anchors (conceptual) for InteropCard (concerns/semantics only); any concrete schema/exchange mapping is outside Part E (Annex/Interop).

Result: MVPK(f, Σ) returns U.ViewFamily(f) whose components are Emit_s(f). Reindexing across s ⪯ t is mediated by total view-object coercions PromoteView[s→t]_X (see §6.2).

Intensional I/O vs Publication (normative convention)

  1. I/O are intensional. The Input/Output sections of a morphism describe intensional data types (I/D/S) only; they do not depend on any publication face.
  2. No duplication on faces. MVPK faces do not duplicate I/O lists; they publish a minimal profile: presence‑pins, CG‑Spec/CHR anchors, and EditionId only.
  3. Signature reserved to intensional. Use “Signature” exclusively for intensional objects (U.Signature, U.PrincipleFrame, …). On faces, avoid “signature” and use TechName/PlainName.
  4. Admissible orders, return sets. Whenever a face shows selection or comparison, it returns sets / admissible partial orders and never hides scalarization; cite a ComparatorSetRef for any total order.
  5. Bridge crossing penalties. Crossings cite Bridge + CL; publish Φ(CL)/Φ_plane ids; penalties apply to R only (never F/G).
  6. Carrier anchoring & lanes. On first mention, anchor carriers (SCR/RSCR); keep Work occurrences distinct from epistemic claims via lanes.
  7. Publication ≠ execution. No time/resource semantics on faces; any build/render/upload is separate U.Work.

Pin & Publication characteristics (normative; never “axes”)

Intent. Make pinning and publication-time measurement claims explicit, typed, and auditable without importing geometric metaphors. This section introduces Publication characteristics (PC) as CHR-grounded, publication-facing facets that can admissibly appear on MVPK faces.

Terminology (aligned with CHR‑MM & UNM).

  • Characteristic (U.Characteristic): a measured aspect as defined in CHR‑MM (entity/relation characteristic with a chosen Scale).
  • CharacteristicSpace (U.CharacteristicSpace): a CHR‑typed product of slots used by dynamics/measurement theories (A.19).
  • Publication characteristic (U.PubCharacteristic, PC): a declarative facet that a view/card/lane may expose about a morphism under a stated Viewpoint. Each PC is backed by CHR/CG‑Spec publications and pinned by {unit/scale/reference‑plane/edition}. PCs are not geometry and do not define “axes”.

PC catalog (initial set). MVPK defines a minimal open set of PCs that are frequently shown on publication faces:

  • PC.Number — numeric/comparable entries (thresholds, budgets, counts). Pins required: unit, scale, reference‑plane, edition.
  • PC.EvidenceBinding — bindings to evidence carriers and policies (e.g., PathSliceId, BridgeId, CL notes).
  • PC.ComparatorSetRef — an explicit comparator family for admissible partial orders on faces.
  • PC.CharacteristicSpaceRef? — optional pointer when a face needs to cite the space in which a claim is interpreted (e.g., dominance on a declared space). The catalog MAY be extended (see “Extensibility” below); PCs must remain declarative (no embedded mechanisms).

Norms (E17‑PC).

  • E17‑PC‑1 (CHR grounding). Every PC that yields numeric/comparable content SHALL cite CHR/CG‑Spec anchors and carry pins {unit, scale, reference‑plane, edition}.
  • E17‑PC‑2 (Lexical discipline — no geometry). Faces and PCs MUST NOT use “axis”, “dimension”, or geometric metaphors; use Characteristic, slot, CharacteristicSpace where applicable (E.10; see also A.19).
  • E17‑PC‑3 (No hidden arithmetic). Faces MUST NOT smuggle aggregation/normalization; any such logic lives in CG‑Spec (UNM/NormalizationMethod) and is cited by …Ref.edition.
  • E17‑PC‑4 (Plane & crossing). When a PC depends on ReferencePlane or crosses planes/contexts, the face SHALL cite BridgeId and CL policy‑ids; penalties apply to the R‑channel only.
  • E17‑PC‑5 (Edition pinning). PCs that rely on maps or distances SHALL pin DescriptorMapRef.edition, DistanceDefRef.edition, and, if used, CharacteristicSpaceRef.edition / TransferRulesRef.edition.
  • E17‑PC‑6 (Viewpoint scope). Each PC instance declares the Viewpoint under which it is valid; promotion PromoteView[s→t] MUST NOT strengthen claims; at most, it reindexes or annotates.
  • E17‑PC‑7 (Comparator/SetSemantics edition). PC.ComparatorSetRef and any SetSemanticsRef SHALL carry edition identifiers; cards MUST be re‑emitted upon edition change with migration notes.

Publication faces and responsibilities.

  • PlainView MAY include PC.Number iff fully pinned; otherwise it uses compare‑only language.
  • TechCard SHOULD carry PC.Number, PC.ComparatorSetRef, and PC.CharacteristicSpaceRef? when faces enable admissible ordering.
  • AssuranceLane SHALL carry PC.EvidenceBinding and the pins for any numeric claims it relays.
  • InteropCard MAY reference PCs conceptually but SHALL remain notation‑neutral in Part E (schemas map in Annex/Interop).

Rationale. MVPK is a publication discipline, not a measurement calculus. By naming Publication characteristics and pinning them to CHR/UNM, we:

  1. prevent geometric leakage (no “axes”);
  2. keep publication neutral yet auditable;
  3. enable admissible set/ordering behavior on faces via explicit ComparatorSet;
  4. make plane/crossing requirements first-class and checkable by declared publication checks / OperationalGate(profile) GateChecks.

Extensibility.

  • E17‑PC‑Ext‑1 (Open catalog). New PCs MAY be added under U.PubCharacteristic provided they are declarative and CHR/UNM‑grounded.
  • E17‑PC‑Ext‑2 (Kinding). New PCs MUST declare kind ∈ {Number, EvidenceBinding, SelectorHint, ...} and a pinning requirement.
  • E17‑PC‑Ext‑3 (Twin‑register names). Supply Tech and Plain twins; avoid tokens that collide with E.10 bans; do not coin “…Space” names for publication forms.
  • E17‑PC‑Ext‑4 (Edition discipline). If a PC depends on a definition/specification publication, edition‑pin the reference (…Ref.edition) and document migration rules.

Adding invariants (procedure).

  1. Place new invariants for PCs in CG-Spec (specification lane), not on faces; supply acceptance tests.
  2. Version any affected CharacteristicSpace; publish embeddings if semantics change; never mutate slots in place.
  3. Update the relevant GateChecks / GateProfiles (A.21/A.26; incl. GateCrossing/CrossingSurface checks from E.18/A.27) to warn/block on invariant violations; never weaken functorial invariants.
  4. Document edition/migration rules; extend §9 with a conformance item and provide Lean‑profile downgrade (advisory vs block) where applicable.

Author ergonomics (non‑normative)

Quick path for authors (three steps and a micro‑template):

  1. Declare Σ and profile. Choose {PlainView, TechCard, …} and whether faces are full or ‑Lite.
  2. Pin once, reuse everywhere. Attach {UnitType, ScaleKind, ReferencePlane, EditionId} to the arrow; cards reference these pins by ID (no duplication).
  3. Emit & verify. Generate all faces from the arrow.

Guidance: treat ‑Lite as field‑drop only; never add claims in ‑Lite.

Rules and Invariants (normative)

Publication-composition local test bundle. A face that claims compositional publication passes only when five local tests are visible:

  1. identity: Emit_s(id_X) is the identity view for ViewObj_s(X).
  2. composition witness: the published face for g∘f matches the composition of the published faces for f and g, or the face is marked non-compositional / explanatory-only.
  3. no-new-claim diff: red-line against the governing D/S episteme shows formatting, indexing, pinning, or view/refinement work only.
  4. monotone promotion: promotion from a plainer face to a richer face adds fields, pins, or typing without retracting or strengthening the source claim.
  5. scope non-widening: PublicationScope stays within the relevant ClaimScope or WorkScope, and promotion does not widen it.

For any composable arrows X —f→ Y —g→ Z in U, and any s, t ∈ Σ_viewpoints:

  1. Functoriality & typing (per‑viewpoint).

    • (a) Identity: Emit_s(id_X) = id_{ViewObj_s(X)}.

    • (b) Composition: Emit_s(g∘f) = Emit_s(g) ∘ Emit_s(f). A face that claims compositional status carries a local witness: compare the published face for g∘f with the composition of the published faces for f and g. If the witness is absent or fails, mark that face non-compositional / explanatory-only and do not use it to satisfy the composition rule.

    • (c) Typing (totality): if f : X → Y then Emit_s(f) : ViewObj_s(X) → ViewObj_s(Y) is total; ill-typed composites must be fixed via ViewObj_s, not by weakening invariants.

    • Intuition: every viewpoint acts functorially on arrows; publication does not break arrow algebra.

  2. Reindexing coherence (monotone refinement + naturality).
    • (a) If s ⪯ t then the t‑view refines the s‑view for the same morphism (no content extension; increased formality/typing only).
    • (b) For each s ⪯ t there are object‑components PromoteView[s→t]_X : ViewObj_s(X) → ViewObj_t(X) natural in X, i.e., for every f : X → Y PromoteView[s→t]_Y ∘ Emit_s(f) = Emit_t(f) ∘ PromoteView[s→t]_X.
    • (c) Coherence: PromoteView[s→s]_X = id_{ViewObj_s(X)}, and if s ⪯ t ⪯ u then PromoteView[s→u]_X = PromoteView[t→u]_X ∘ PromoteView[s→t]_X for all X.
    • Defaults: PlainView ⪯ TechCard ⪯ InteropCard.
    • Note: AssuranceLane is independent of the formality chain; it binds evidence‑about‑claims and MUST NOT introduce new claims of the morphism.
  3. D/S sourcing & EpistemicViewing compatibility (A.7/E.10.D2, A.6.2–A.6.3, E.17.0).
    • (a) Inputs to Emit_s(-) are existing D/S‑epistemes about the same arrow (for example, MethodDescription, MethodSpec) produced by Describe_ID and Specify_DS/Formalize_DS in A.7/E.10.D2. MVPK does not redefine or collapse these I→D→S morphisms.
    • (b) Each Emit_s(-) SHALL be realised as a species of U.EpistemicViewing (A.6.3) over those D/S‑epistemes: describedEntity‑preserving, effect‑free and conservative in the sense of A.6.2/A.6.3. Publication adds no new commitments beyond what is present in the referenced D/S‑epistemes.
    • (c) Edition governance respects U.EditionSeries/UTS; rows remain the identity anchors for names; MVPK faces MUST be (re‑)emitted when the underlying D/S editions change.
  4. Pin discipline (Part F/G).
    • Any numeric/comparable content in a view SHALL pin {UnitType, ScaleKind, ReferencePlane}. EditionId MAY be coarse at Lean profiles; if units/scale are unknown, declare ordinal/compare‑only and forbid arithmetic until CHR pins are available. Pins upgrade monotonically with profile and risk.
  5. No Γ‑leakage (publication independence). Publication morphisms carry no Γ_method / Γ_time / Γ_work semantics. Any build/render/upload toil is separate U.Work by a system on carriers (A.7). Lean assurance lane: AssuranceLane‑Lite MAY expose only presence bits for {PathId/PathSlice?, Γ_time window?, BridgeId?}; unknowns propagate (tri‑state) with an explicit {degrade|abstain|sandbox} policy note.
  6. Carrier provenance. Every emitted view records its SCR/RSCR ids on first occurrence (A.7 §5.6).
  7. Isomorphism preservation.
    • If f is an isomorphism in U, then Emit_s(f) is an isomorphism in View_s(U); inverses map accordingly.
  8. Cross‑Context/plane bridging.
    • If a view crosses contexts or reference planes, it SHALL cite the Bridge + CL policy ids (A.7 §5.8, bridge crossing). Such crossings MUST be explicit on TechCard and AssuranceLane.
  9. Totality of publication morphisms.
    • Publication maps are total on their domains; when a composition in a view would be ill‑typed, the author must fix the view-object mapping (via ViewObj_s) rather than weakening functoriality or reindexing rules.
  10. PublicationScope discipline (subset & composition).
    • (a) Subset rule: If a view v is about episteme E then PublicationScope(v) ⊆ ClaimScope(E); if about capability C then PublicationScope(v) ⊆ WorkScope(C) only as the publication scope of a capability description, not as work admissibility, gate passage, release permission, or evidence that U.Work occurred.
    • (b) No widening by refinement: If s ⪯ t, then promotion PromoteView[s→t] MUST NOT widen PublicationScope.
    • (c) Compositional bound: For composable arrows X —f→ Y —g→ Z, PublicationScope(Emit_s(g∘f)) ⊆ PublicationScope(Emit_s(g)) ∩ PublicationScope(Emit_s(f)).

Structure & participants

                 Σ_viewpoints
                      │
            ┌─────────┴─────────┐
            │                   │
        Emit_s(-)           Emit_t(-)      … (family)
            │                   │
U :  X ──f──▶ Y ──g──▶ Z    X ──f──▶ Y ──g──▶ Z
        U.ViewMorph        U.ViewMorph
            │                   │
        Emit_s(f),…         Emit_t(f),…
  • Author chooses Σ_viewpoints (declared concerns + conformance rules).
  • MVPK emits U.ViewFamily(f) for each arrow f.
  • Declared publication checks verify that pins/anchors/IDs are present and that MVPK invariants are respected. Use OperationalGate(profile) / GateChecks only when a live project gate profile actually governs the next project move.

Examples (SoTA-aligned Local Tests)

Read these examples as local tests for MVPK invariants, not as source citations by reputation.

  1. Composite service pipeline (InteropCard + AssuranceLane). f: Parse → Normalize, g: Normalize → Score. InteropCard(g∘f) is an interoperability view whose path set equals the relational composition of the two cards; AssuranceLane(g∘f) cites test records as evidence carriers with edition pins. (Carriers, not semantics; concrete envelope formats are outside Part E.)

  2. Control loop morphism (TechCard + PlainView).

    • For h: Setpoint → Actuation, TechCard(h) is a typed card with units; PlainView(h) narrates the same mapping with no new claims. (Monotone formalization echoes refinement‑typed stacks.)

  3. Optics-informed composition witness.

    • Profunctor/optic accounts are useful only as a source idea for why compositional publication matters. The local FPF test is still the MVPK witness: emit the face for g∘f, compose the emitted faces for f and g, and compare them. If the comparison is not supplied or fails, the face stays non-compositional / explanatory-only; optics vocabulary does not carry the rule by analogy.

  4. Functional-description publication (PlainView + TechCard). A principle scheme or functional diagram can publish a readable relation from signature or principle material to method-family selection, selected method, U.WorkPlan, performed U.Work, work-result record, and result measurement. The MVPK faces may help a team inspect that relation and prepare a work plan, but they do not turn the diagram, table, screen, or export into work occurrence, gate passage, evidence, engineering justification, or supervisory/control architecture. For those uses, the team first recovers the existing project source that carries the claim when available: work-relevant source restoration under A.15.4, method/plan/work material under A.15, evidence/provenance path under A.10, engineering-justification record under B.3, gate/constraint decision under A.20 / A.21, or supervisory/control architecture record under B.2.5. If no existing source carries the needed claim, create only a prospective repair request, future decision request, prospective work-plan record, or explicit source-gap record; do not backdate evidence, gate passage, work occurrence, release permission, engineering justification, or assurance for the earlier claim.

Conformance checklist (normative)

CC-MVPK-FD is the functional-description guard in §5.1a. It is conditional on a functional-description publication face and must not read as the first universal MVPK gate.

A conformance check is retained only if it changes the next admissible use of the publication face, blocks a concrete overclaim, or preserves a source/reopen path needed for the declared supported use.

Core ordinary checks

IDRequirementPractical test
CC‑MVPK‑1 (Viewpoint explicit)Each view declares its Viewpoint (stakeholders, concerns, conformance) as a publication U.Viewpoint.Cards show PublicationVPId (or equivalent publication‑viewpoint field) and concerns.
CC‑MVPK‑3 (No content extension)PlainView, TechCard, and InteropCard add no new claims beyond the underlying D/S‑epistemes.Red‑line vs D/S episteme output (Describe_ID/Specify_DS) shows only formatting/indexing.
CC‑MVPK‑4 (Pins & anchors)Numbers/thresholds pin {...}. Lean exception: at MVPK‑Min/Lite profiles, EditionId MAY remain coarse; ordinal claims are admissible only as compare‑only (no means/z‑scores).Validation shows pins present or compare‑only mode engaged.
CC‑MVPK‑4j (PublicationScope present)Each view declares U.PublicationScope (USM §6.5).Field present; presence‑bit green.
CC‑MVPK‑5 (Carrier anchoring)First mention includes SCR/RSCR ids when carrier/rendering work is live.SCR ids visible on the card when used.

Conditional checks

IDRequirementPractical test
CC‑MVPK‑0 (Lean publication guard)For Lean profiles, a minimal guard runs: (i) set‑returning selection present; (ii) ReferencePlane present; (iii) any crossing cites BridgeId+CL with penalties applied to R only.Validation report shows presence bits; penalties apply to R only.
CC‑MVPK‑2 (Functoriality)Emit_s(id) is identity; Emit_s(g∘f) = Emit_s(g)∘Emit_s(f).Compose two cards and diff with the card of the composite.
CC‑MVPK‑3b (Boundary claim‑set integrity)If a published arrow is a boundary/interface/protocol and an A.6.B claim set exists (L-* / A-* / D-* / E-*), then any normative text on faces MUST be traceable to that claim set (prefer claim‑ID citations); faces MUST NOT become a second boundary specification.Lint flags uncited normative clauses; faces reduce to {claim‑ID citations + informative commentary}.
CC‑MVPK‑4b (Lean assurance)If AssuranceLane‑Lite is used, presence bits for {PathSliceId?, BridgeId?} suffice; full evidence-carrier lists stay with the governing evidence source.Presence bits visible; required evidence-carrier refs stay outside Lite.
CC‑MVPK‑4c (I/O vs publication)Faces do not restate I/O; they carry presence‑pins + anchors + EditionId only.Face inspection shows no I/O duplication.
CC‑MVPK‑4d (Admissible orders)Any selection/comparison on faces returns sets / admissible partial orders with a ComparatorSet citation.No hidden scalarization; ComparatorSetRef present.
CC‑MVPK‑4e (Signature on faces — banned)The term “signature” is not used on faces; use TechName/PlainName.Token scan: no “signature” on faces.
CC‑MVPK‑4f (PC discipline)Any numeric/comparable publication uses Publication characteristics (PC) and carries pins {unit, scale, reference‑plane, edition}.Cards show PC fields + pins; validation passes.
CC‑MVPK‑4g (No axis/dimension)Faces avoid “axis/dimension/plane” metaphors except ReferencePlane; use CHR terms (Characteristic/slot/CharacteristicSpace).Lexical check flags none; only ReferencePlane appears.
CC‑MVPK‑4h (Edition pins on defs)Where maps/distances/spaces are cited, the face pins DescriptorMapRef.edition, DistanceDefRef.edition, and CharacteristicSpaceRef.edition?.Validation shows edition fields populated.
CC‑MVPK‑4i (Crossings gated)Plane/Context crossings cite Bridge + CL policies; penalties apply to R‑channel only.IDs present; R-channel penalty application verified in harness logs.
CC‑MVPK‑4k (Subset‑of underlier)For views about epistemes/capabilities, PublicationScope ⊆ ClaimScope/WorkScope; reindexing does not widen it.Subset witness passes; promotion diff shows no widening.
CC‑MVPK‑6 (Γ‑separation)No cost/time/data‑spend on publication morphisms.CI shows proof/witness records; gate validation passes.
CC‑MVPK‑7 (Reindexing monotone)If s ⪯ t, then Emit_s(x) ⪯ Emit_t(x).TechCard ≤ InteropCard (more structure, same claims).
CC‑MVPK‑8 (SurfaceKind discipline)Only PublicationSurface/InteropSurface are used; faces named ...View/...Card.Token scan; no “rendering/presentation” as SurfaceKind values.
CC‑MVPK‑9 (Reindexing naturality)Reindexing coercions PromoteView[s→t] exist, are total, and commute with composition.Witness shows PromoteView[s→t]_Z ∘ Emit_s(g∘f) = (Emit_t(g) ∘ Emit_t(f)) ∘ PromoteView[s→t]_X.
CC‑MVPK‑10 (Iso‑preservation)Isomorphisms in U remain isomorphisms under each viewpoint.Cards show mapped inverses or an iso‑witness.
CC‑MVPK‑11 (Typing & totality)Ill‑typed composites are rejected at ViewObj_s rather than weakening functoriality.Type‑check fails early; no “best‑effort” composition in cards.
CC‑MVPK‑12 (Bridge+CL on crossings)Any cross‑Context/plane view cites Bridge + CL policy ids.IDs present on TechCard/AssuranceLane.

Anti‑patterns (with fixes)

  1. “Presentation logic” as semantics. Fix: Move any logic to Describe_ID/Specify_DS or CG‑Spec/KD‑CAL; keep views declarative; publication adds zero claims.
  2. Publishing only view objects. Fix: MVPK acts on arrows. Always emit views for g∘f, not just for ViewObj_s(X), ViewObj_s(Y), and ViewObj_s(Z).
  3. Unpinned numbers. Fix: Reject card; supply pins and CG/CHR anchors.
  4. Viewpointless views. Fix: Define Viewpoint; attach concerns + conformance; re‑emit.
  5. InteropCard equivalent to TechCard duplication. Fix: InteropCard may refine typing/shape but cannot contradict TechCard (reindexing monotone).

Consequences

BenefitWhy it mattersTrade‑off / Mitigation
Arrow traceability.Composition preserved across views enables chain‑of‑evidence on pipelines.Slight authoring overhead → MVPK templates.
Review-ready faces.Pins + CHR anchors make numeric claims verifiable.Declared publication checks perform MVPK checks; project gates stay with the relevant OperationalGate(profile) / GateDecision source when gate pressure is live.
Terminology hygiene.Clear View vs Viewpoint, Publication vs Presentation.Enforce L‑SURF tokens in CI.
Notation independence.Viewpoints talk concerns, not tools.Provide adapters to local stacks.

SoTA Alignment: Adopted/Adapted Invariants And Rejected Shortcuts

SoTA alignment rule. Read each row here as source idea -> local FPF invariant -> practical local test -> popular shortcut rejected. A source citation governs nothing by reputation; it counts only when the cited idea is translated into the Solution, conformance checks, boundary rules, worked slices, and Relations of this pattern.

Source idea and current sourceLocal FPF invariant / practical local testAdopted/adapted invariant / rejected shortcut
Architecture-description and MBSE practice separates source description, view/viewpoint, model kind, correspondence, and interoperability surface instead of letting one readable model face stand in for all of them.MVPK publishes one source-pinned face over an existing source episteme/view, keeps U.View, viewpoint, carrier/rendering work, correspondence support, and concrete exchange/interoperability envelopes separate, and sends work, evidence, gate, assurance, carrier, or bridge use to the governing source relation.Adopt explicit source/view/viewpoint/model-kind separation; reject the shortcut where a readable architecture or model face becomes evidence, work occurrence, gate passage, release permission, bridge support, or concrete exchange authority by presentation alone.
Profunctor/optic accounts (2017-2019; source maturity = research/theory line, not load-bearing without local witness) support compositional views that compose like arrows.MVPK adopts only local publication-composition tests: identity, composition witness, no-new-claim diff, monotone promotion, and scope non-widening.Adopt the five-test publication-composition bundle; reject optics vocabulary as proof by analogy or as a replacement for local witnesses.
Refinement-typed ecosystems (2016+; source maturity = widely used technical practice) keep units, scales, and type-like constraints attached to values.MVPK publication faces carry pins and CHR/CG anchors; local test: numbers, thresholds, and characteristic claims on faces have units, scales, reference-plane/edition support where load-bearing.Adapt pin discipline; reject readable numbers as self-validating values.
Interoperability and evidence-envelope practice (source maturity = mature standards/practice, depending on concrete envelope) separates exchange format and carrier evidence from the claim being carried.MVPK faces may expose evidence carriers or exchange envelopes, but concrete formats live outside Part E; local test: the face adds no claim and points back to the governing source or evidence path.Adapt envelope discipline; reject treating envelope presence as semantic truth, evidence sufficiency, work occurrence, or gate passage.

(References are selected because they support local MVPK invariants and tests; MVPK remains notation-agnostic.)

Relations

  • Builds on: A.7 / E.10.D2 for carrier/front-end and strict I/D/S discipline; A.6.2-A.6.3 for episteme morphisms, U.EffectFreeEpistemicMorphing, and U.EpistemicViewing; E.17.0 for U.MultiViewDescribing; E.8 and E.10 for authoring and publication-language discipline; Part F/G for bridge, terminology, characteristic, and pin discipline.
  • Constrains: publication-face-emitting automation and hand-authored publication faces. They remain species of U.EpistemicViewing over existing D/S epistemes and may not become a second I->D->S mechanism, evidence path, gate decision, work occurrence, assurance record, release source, or bridge declaration by readable form.
  • Current outgoing exits from E.17:5.1d: work/reliance support exits to A.15.4, with A.15 for role/method/plan/work alignment and A.15.1 for one dated U.Work occurrence; evidence, provenance, attestation, currentness, and freshness exit to A.10; engineering justification, assurance, confidence, readiness, and limitations exit to B.3; gate passage, constraint validity, adjudication, and release decision support exit to A.20 / A.21; same-entity textual restatement exits to A.6.3.CR; same-entity representation-scheme or reasoning-medium change exits to A.6.3.RT; deliberately weaker narrower-use rendering exits to A.6.3.CSC; explanation-facing rendering exits to E.17.EFP; bounded comparative review exits to E.17.ID.CR; changed described entity, target, ontology frame, or governed claim exits to A.6.4, OntologicalReframing, or the exact retargeting/reframing pattern; carrier, export, OCR, screen, front-end behavior, or work on carriers exits to A.7.
  • Part F / bridge wording exit: when the publication face uses or invites "same", "equivalent", "align", "map", substitutable, interchangeable, attribute/entity/profile matching, or other bridge-wording pressure across contexts, the wording repair belongs to Part F / A.6.9 and the bridge support belongs to F.9 / F.9.1; E.17 does not create a local bridge taxonomy.
  • Coordinates with: B-operators for no Gamma-leakage, C-cluster selection/archive patterns where views remain publication faces rather than selections, CHR/UNM for measurement and normalization semantics, F.9 / F.9.1 / A.6.9 for bridge and sameness wording, and the neighboring source patterns named above. This section is relation/exit truth for publication use, not a standing decision tree or process order.

Minimal authoring template (Part E)

Header: MVPK v⟨edition⟩ — Σ = {PlainView ⪯ TechCard ⪯ InteropCard, AssuranceLane ⟂} For each arrow f: emit {Emit_s(f) | s ∈ Σ} (or use the plain aliases {PlainView(f), TechCard(f), …}) with: PublicationScope, ViewpointId, pins, CHR/CG anchors, SCR ids, Bridge+CL ids (if crossing), and—if composite—machine‑checkable witnesses that Emit_s(g∘f) = Emit_s(g)∘Emit_s(f) and for each s ⪯ t the naturality square PromoteView[s→t]_Y ∘ Emit_s(f) = Emit_t(f) ∘ PromoteView[s→t]_X.

Manager’s one‑page review (copy‑paste)

“We publish every morphism under a declared set of viewpoints using MVPK. Each view that claims functorial composition carries the local composition witness; without that witness it stays non-compositional / explanatory-only. Each face adds no new claims and pins unit/scale/reference‑plane/edition with CHR/CG anchors. InteropCard views clarify concerns/semantics only (concrete exchange lives outside Part E); AssuranceLane cites evidence carriers (SCR). Any cross‑Context/plane view cites Bridge+CL (Φ→R only). Publication toil is U.Work on carriers, not a mechanism change.”

E.17:End

Last Updated: 2026-05-12 — this section last modified in upstream FPF commit f73766dd (github.com/ailev/FPF)