#Multi-View Publication Kit

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 Reference product feature page.

#How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

Status: Stable

At a glance. Use E.17 when one source-backed episteme, episteme-side view, morphism, or functional relation needs several readable publication faces for different readers without changing the underlying claim.

Use this when. The engineering team needs a plain view, technical card, interoperability card, or AssuranceLane face 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, Description episteme, or Description episteme selected for specification use, publication scope, face kind, bounded publication use, and any present downstream typed value named only as far as the current use needs, such as a GateDecision, evidence path, work occurrence, status source, or authority-reference relation.

Working publication move. Publish one source-pinned face; separate source episteme or episteme-side view, face, carrier, bounded publication use, and any present downstream typed value plus its governing FPF pattern and reference; use the face for inspection, source-finding, review, exchange, or planning preparation; apply the neighboring FPF pattern governing that claim if work, evidence, gate, engineering-justification, control, or release use is present.

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

Load-bearing formality rule. Add the fuller MVPK record only when the face will be used for external-impact reliance, cross-context exchange, evidence citation, gate or 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.

Boundary aid pointer. If one encountered publication-facing unit is easy to interpret as work, evidence, gate, approval, status, explanation, comparison, or narrower-use rendering, handle one claim being made or effect at a time using E.17:5.1d.

Here in the first-screen interpretation, keep only the MVPK publication move: one source-pinned face, one bounded publication use, and neighboring FPF pattern governing any present typed downstream value only as far as the current use needs.

Not this pattern when. Not this pattern when the issue under repair is performed U.Work, a work plan, evidence path, provenance path, engineering justification, gate decision, control architecture, carrier work, OCR work, or a narrower-use rendering that needs its own source-bearing return. Use the FPF pattern that governs that issue.

Tech-name: U.MultiViewPublicationKit (MVPK)

General publication-face form: one MVPK face is a U.View emitted over one source U.Episteme or episteme-side U.View, under one publication U.Viewpoint, one U.PublicationScope, declared pins where needed, one face kind, and one bounded publication use. The face adds no claim by readable form. Evidence use, authority use, gate use, work use, release use, and engineering-justification use require the neighboring FPF pattern governing that claim and typed project-side value or reference that carry that downstream use, such as a GateDecision, evidence path, work occurrence, status source, or authority-reference relation. USM binding (overview): PublicationScope is a USM‑class object that parameterizes MVPK; see §5.0. Episteme-side view position. MVPK treats each face as a U.View in the sense of C.2.1 and E.17.0 (species U.EpistemeView). For any MVPK face, the source is a named U.Episteme or episteme-side U.View; the face declares a publication U.Viewpoint (PublicationVPId) drawn from a U.ViewpointBundle (E.17.1 and E.17.2). In the morphism profile, every Emit_s(f) has EntityOfConcernSlot and DescriptionContext target f : U.Morphism. In a non-morphism publication, the face names the source episteme named by value, episteme-side view, EntityOfConcern, or claim relation that the face publishes, and no functorial composition claim is present unless the corresponding FPF pattern supplies it. Slot discipline (ViewSlot and ViewRef) is inherited from C.2.1 and A.6.5 and is not redefined in MVPK.

Provide a disciplined way to publish one source episteme or episteme-side view across multiple didactic faces without adding semantics, while keeping publication viewpoints explicit and auditable. The canonical formal profile is morphism publication: a small view-pack applied to any U.Morphism, including compositions, yields a family of views that commute with arrow composition and respect edition and measurement pinning.

#Relations

#Content

#Intent

Provide a disciplined way to publish one source episteme or episteme-side view across multiple didactic faces without adding semantics, while keeping publication viewpoints explicit and auditable. The canonical formal profile is morphism publication: a small view-pack applied to any U.Morphism, including compositions, yields a family of views that commute with arrow composition and respect edition and measurement pinning.

#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, and edition pins.
• “View” and “viewpoint” are blurred in practice; authors conflate publication with mechanism.
• publication-face-kind discipline requires publication-face kind token discipline; Core allows only literal values publication face/form or interop publication form; faces are named ...View, ...Card, or ...Lane (no ad-hoc ...Surface kinds).

MVPK fixes this by making publication a typed projection from existing source epistemes or episteme-side views via species of U.EpistemicViewing subject to explicit viewpoint specs and pinning guards. In the morphism profile, this projection is the functorial publication discipline for Description epistemes, including Description epistemes admitted for specification use, described below. 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 Description epistemes about the arrow, including Description epistemes admitted for specification use (epistemes with DescriptionContext = ⟨EntityOfConcernRef, BoundedContextRef, ViewpointRef⟩ in the sense of E.10.D2 and 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 from Part F or Part G, undermining auditability.

#Forces

#Solution — the MVPK Kit

#USM scope binding (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 declares a U.PublicationScope that bounds where that face has bounded publication use.
  • Non-overload rule. U.PublicationScope does 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 edition-change rules); MVPK emits faces under a declared PublicationScopeId.
• MVPK profile (kit configuration). The canonical MVPK profiles (MVPK‑Min, MVPK‑Lite, MVPK‑SetReady, and MVPK‑Max) fix:
  • (a) the viewpoint index Σ and its partial order ⪯,
  • (b) the declared Publication characteristics (PC) and required pinning requirements,
  • (c) any cross‑Context or cross-plane constraints (Bridge and 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, publication-face kind values, claim quadrants, governingPatternRef, and local field values use the P-, T-, I-, and A-face-name initials only when an abbreviation is unavoidable; the L-, P-, D-, and E-mnemonic set is not a publication-face-name set.

#Terminology (normative)

• View (U.View): an episteme-side view (U.EpistemeView in the sense of C.2.1 and E.17.0) produced under a publication viewpoint. In MVPK each face (PlainView, TechCard, InteropCard, AssuranceLane) is such a U.View. In the morphism profile its EntityOfConcernSlot and DescriptionContext target is a U.Morphism; in a non-morphism publication, the target is the source episteme named by value, episteme-side view, EntityOfConcern, or claim relation named by the source. Every MVPK U.View declares: publication-face kind ∈ {literal publication face/form, interop publication form}, PublicationVPId : U.ViewpointRef, references to the underlying Description epistemes, including any Description episteme admitted for specification use selected by neighbouring gates, and a U.PublicationScope (USM §6.5). Any carrier rendering is separate U.Work over carrier or rendering infrastructure, with A.10 carrier and source-currentness records when reliance is current, and is not part of U.View.
• Publication vs presentation vs rendering vs representation (guard):
  • Publication = typed projection from existing source epistemes or episteme-side views into a U.View governed by the literal publication face/form or interop publication form value of publication-face kind via species of U.EpistemicViewing (A.6.3). In the morphism profile, the source epistemes are Description epistemes about a morphism, possibly under specification use when A.6.2, C.2.3, A.21, C.16, E.10, or another neighboring pattern governing the claiming gate grants that use. A.7 supplies the EntityOfConcern and Description-episteme boundary; publication expression does not turn that boundary into a three-member strict-distinction ontology.
  • Presentation = rhetorical arrangement of a published carrier; notation-neutral, adds no claims and is not a publication-face kind.
  • Rendering = display layout of a carrier, purely graphical formatting; U.Work on carriers (A.7), not a publication-face kind.
  • Representation = episteme↔referent relation (C.2.1, A.6.2 through A.6.4); not a publication operation and not a publication-face kind operation. Use publication and view here; treat presentation and rendering as U.Work on carriers (A.7).
• ISO mapping note. ISO viewpoint -> PublicationVPId (publication relation position); engineering viewpoint -> EngineeringVPId (E.18:5.12 transformation-flow viewpoint-family map). An ISO view can be a single MVPK face; “bundles” are packaging only.
• No‑mechanism equivalence: MVPK is not a mechanism; any operational activity, such as build, render, or upload work, 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, declared 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 or E.17.2) (see §5.3).
• Explanation-use profile values. Existing faces can 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 references, and no-new-A.6.B-boundary-claims discipline still apply.

#Episteme-publication relation-position binding (normative)

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

Publication relation position. A principle scheme, functional diagram, comparison table, screen, export, scenario, explanation, or code-like method description can help interpretation, source-finding, comparison, selected-method inspection, or work-planning preparation.

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

Interface and protocol proximity. When interface, protocol, schema, boundary, or API wording appears beside a functional-flow description, keep the operational boundary, interface, or protocol claim with its own project claim set and typed project-side value named by value and reference, governed by the relevant FPF pattern 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 EntityOfConcern or retargeting target from an already described component, recovered transformation, method, work occurrence, transformation-flow structure, material U.Entity, 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 an typed project-side value named by value and reference beyond the publication face, the engineer first recovers the corresponding existing project-side FPF value if one already carries the needed claim:

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

No backdating. If no existing typed project-side value named by value and reference carries a claim that was supposed to already have a source relation, do not create a backdated source. Create only a prospective repair request, prospective decision request, prospective work-plan entry, or explicit source-gap note, and treat the earlier claim or 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 separates the source U.Episteme or episteme-side U.View, the MVPK face, any present carrier or rendering work, the bounded 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 semio kind 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 relation position before relying on it:

• the underlying U.Episteme, D episteme, or S episteme whose ClaimGraph is being projected;
• the U.EpistemePublication or source U.Episteme publication when the episteme is available as a published episteme;
• the publication form used by the local pattern, when one is present;
• the U.View-typed MVPK face (PlainView, TechCard, InteropCard, AssuranceLane) that renders the publication for a viewpoint;
• the carrier or rendering work that holds or displays it, plus A.10 carrier/source-currentness or provenance records when downstream reliance is current;
• the typed project-side value named by value and reference or authority-reference relation when the next work or reliance claim depends on that named authority-reference relation, approval source, gate source, release source, or typed project-side value named by value and reference.

The practical payoff is that a reader can recover which relation is available for reliance: the episteme claim, the published form, the view, the carrier, the typed project-side value named by value and reference, 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 or effect, gate decision, evidence relation, assurance claim, role or status, work occurrence, or permission.

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

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

#Shared source-relation and bounded-use vocabulary

Use this vocabulary when a publication face, rendering, generated text, comparison note, narrower-use rendering, source-finding cue, or authority-looking display can be overinterpreted as carrying a wider source relation or bounded-use permission than it actually carries. The vocabulary names the source relation or bounded-use value for one claim or use. It does not instantiate evidence, gate, assurance, work, commitment, speech act, decision, release, or authority.

Patterns can use shorter local field names such as sourceRelationStatus, explanationSourceStatus, or representationValidityStatus when the local object is clear. Comparative patterns split source-relation status from comparative-relation status instead of using one overloaded field. The local field remains interpretable through the vocabulary above, and the bounded use is named beside it when downstream reliance could change.

For ordinary use, name only the status distinction that changes the next bounded use. The common light states are source-pointer-only, source-relation-unknown, source-relation-not-needed, source-not-recoverable-here, admissible-for-this-use, downstream-use-forbidden, and reopen-trigger-present. The vocabulary is not an ordered scale, source-stage model, source-record taxonomy, authority-reference source taxonomy, or project-side evidence and assurance, gate, or work substitute. If a source relation is missing from the publication-facing unit, only the unsupported downstream use is blocked; the missing relation does not by itself prove the underlying world claim false. If independent-verification-present is relied on, name the separate governing pattern and record named by value that performs that independent check: A.10 evidence path, B.3 assurance claim, A.21 GateDecision, A.20 constraint profile, A.15 U.WorkPlan, A.15.1 dated U.Work occurrence, or F.9 Bridge Card.

#Shared use-boundary terms

Use these terms when a publication face, rendering, narrower-use rendering, explanation, comparison note, source-finding cue, or authority-looking display can be interpreted beyond its named source relation. Define them once here and link back to this section from local patterns instead of minting local synonyms.

#Compact boundary aid for the present claim or effect

When a publication-facing unit, publication face, rendering, narrower-use rendering, explanation, comparison note, dashboard tile, credential view, status view, carrier, or generated unit creates more than one possible interpretation, separate the claim being made or effect being used now and cite the source relation that makes the operative claim recoverable by value for that claim or effect. This compact boundary aid governs the present claim or effect only; it does not classify the whole encountered unit. The same encountered unit can expose several typed records; handle one claim being made or effect at a time instead of pretending there is one overall governing relation for the encountered unit.

Mixed-case precedence. When several publication-use patterns appear possible, repair the smallest unstable interpretation that changes the current bounded use before applying a neighboring pattern whose claim or effect is present:

1. If one local head is the only unstable part, apply E.17.AUD.LHR or C.2.P and stop when the repaired sentence names the local kind, relation, and bounded use.
2. If the bounded PublicationUnit or its primary EntityOfConcern interpretation is unstable, apply E.17.AUD or E.17.AUD.OOTD before using E.17.ID.CR or E.17.EFP.
3. If the unit is stable and the present problem is comparison overread, apply E.17.ID.CR; use F.9, C.11, A.20, or A.21 only when equivalence, recommendation, selection, decision, gate, or release claim is actually being made.
4. If the unit is stable and the present problem is explanation overread, apply E.17.EFP; use A.10, B.3, A.20, A.21, or A.15.4 only when evidence, engineering-justification, gate, release, work, or reliance claim is actually being made.
5. If the present problem is a durable reusable name, UTS row, Core-facing term, or cross-context naming relation, apply F.18; otherwise keep the lighter local repair pattern.

Evidence-path boundary. An A.10 evidence, provenance, attestation, freshness, or currentness path carries only the claim named by value it instantiates. It does not approve or authorize work, pass a gate, perform work, supply release permission, or raise assurance or engineering-justification use unless the typed project-side value named by value and reference 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 exposes a gate decision only when the GateDecisionRef, gate or constraint profile version, target release or work scope, time window, currentness, freshness reference or replay reference, and evidence path are recoverable. Without that exact gate record, 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, publication-face kind, RelationKind, KindBridge, EvidenceKind, SlotKind, GateDecision, SpeechAct, Commitment, U.Work, publication face, authoritySourceRef target, or typed project-side value named by value and reference unless another governing FPF pattern explicitly instantiates that object. When a local field starts carrying one of those downstream claims, cite or apply the governing FPF pattern and typed project-side value named by value and reference that carry it.

#Shared anti-overread invariants for publication-facing units

Use the FPF pattern that governs the claim being made or effect under use. Keep any local review field local, preserve reduced bounded use, and assign only the unsupported wider claim or effect to its governing source relation.

Source-relation minimality. Name the smallest FPF source relation named by value sufficient for the use under repair. A source pointer, source-exposure relation, evidence path, engineering-justification record, gate decision, and release decision are different FPF relations; choosing one does not license another. Do not apply A.10, B.3, A.20, or A.21 when the use under repair only needs source finding, orientation, or inspection of an existing source U.Episteme, source U.EpistemePublication, or status-register entry.

Local repair vs publication redesign. A local epistemic precision repair is enough only when it can preserve the current publication face or PublicationUnit while fixing one head, boundary, source relation, bounded use, explanation class, or unsupported downstream claim. If layout, grouping, visual emphasis, comparison arrangement, generated explanation, hidden source limitation, or mixed EntityOfConcern packaging still induces overread after the local relation is repaired, create a redesigned publication face or PublicationUnit instead of adding warning text around the misleading form.

Most-likely careful interpretation constraint. Design and word a publication-facing unit so its most likely careful interpretation does not exceed its named source relation, bounded use, and governing FPF pattern. A visible head such as Approved needs a visible GateDecision or a different head; a sorted comparison needs its comparator or sorting relation visible if no recommendation claim is intended; a generated explanation separates inferred links from pinned source claims by wording, label, or source reference.

Visual cue claim pressure. Layout, order, color, prominence, icon, grouping, and proximity are carrier or front-end cues that can carry publication-move pressure even when the words do not. Green color can imply readiness, top position can imply preference, grouping can imply equivalence, proximity to evidence can imply an evidence relation, a badge form can imply approval, and a lock or checkmark can imply verification. If the visual cue would make the reader treat the unit as evidence, gate passage, decision, recommendation, reliance relation, bridge relation, or approval, recover the governing FPF pattern and project-side kind and reference named by value, or redesign the publication face so the overread is no longer invited.

Extraction survival. When a PublicationUnit is excerpted, quoted, screenshotted, summarized, copied into a tutorial, retold by a generator, or moved to a slide, it keeps only the claims, source pins, boundary line, references named by value, and bounded use carried in that extracted unit. Any use that depended on hidden neighboring context is lost unless that context is carried by source pins, a boundary line, or a reference named by value. A dashboard screenshot does not carry the underlying gate record, a quoted comparison row does not carry the full comparator or sorting relation unless that relation is included or referenced, a copied explanation paragraph does not carry source pins unless pins remain recoverable, and a pattern excerpt does not carry the whole pattern boundary unless the excerpt states or cites it.

No-extra-pattern case. If a publication-facing unit has bounded use only for ordinary orientation, learning, source-finding, review, comparison, or planning preparation, and no operative work or reliance, evidence, gate, assurance, bridge, source-dispute, or release claim is present, keep the existing publication source relation and proceed with ordinary use. The visible closure is: no operative work or reliance, evidence, gate, assurance, bridge, source-dispute, release, durable naming, or project-side source-relation claim recovered; ordinary publication wording remains bounded to the current use.

Pattern-inflation anti-pattern. Do not apply a neighboring pattern merely because the publication-facing unit resembles a worked example. Apply the neighboring pattern only when a claim being made or effect changes the next available project move.

Strategic overread invariant. Apply the same anti-overread rules whether the misleading interpretation is accidental, conventional, incentive-driven, or intentionally induced by publication design. Green status color without GateDecisionRef, reviewed-looking wording without approval, selective source links without operative-claim source relation, comparison ordering without selection decision, hidden caveats behind a source link, or pins for trivial claims beside unpinned causal linkage do not create evidence, gate, decision, assurance, work, release, or bridge relation by design pressure.

Carrier-travel invariant. A copied, exported, screenshotted, summarized, generated, translated, or re-rendered publication-facing unit can carry orientation or source-finding cues. It does not carry evidence relation, authority-reference relation, gate passage, approval, engineering-justification relation, work occurrence, currentness, or release source relation unless the governing FPF pattern and typed project-side value named by value and reference remain recoverable for that use named by value.

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

Publication-face snapshot and refresh identity. A publication face can keep the same visible layout, face name, or carrier while its source pins, source data window, source-relation status, freshness or currentness relation, EditionId, or bounded use changes. Visual sameness across time is not source, evidence, or use-boundary sameness. When a refreshed, revised, translated, regenerated, screenshotted, or re-rendered face is used beyond orientation or source-finding, name the face edition or snapshot, the source pins or data window that still carry the claim, and any changed bounded use. If those cannot be recovered, treat the face as orientation or source-finding only, or reissue the face under the governing pattern before work, evidence, gate, assurance, release, or reliance use continues.

Claim-level source relation only. Do not assign one whole-unit source-relation status unless every operative claim in that publication-facing unit has the same source relation named by value for the same use and unsupported downstream uses are explicit.

Modality and deontic-force preservation. Publication-facing transformations preserve possibility, obligation, permission, recommendation status, decision status, confidence, scope, and temporal window when those values change the claim or use. If one of these changes, narrow the bounded use or apply the governing pattern that carries the changed claim or effect. Comparison does not become recommendation or decision; explanation does not become evidence; a publication face does not become authority; a publication unit does not smuggle a downstream effect; source-linked does not mean source-available for reliance; ready-looking does not mean gate-passed.

This preservation rule also applies across extraction, translation, screenshotting, summary, and generated retelling. A translated permission is not wider permission, a screenshot of approval-looking display is not an approval record, a summary of evidence is not an evidence path, and a generated retelling of a decision is not the decision record unless the source relation that makes the operative claim recoverable by value and source pins survive in the new publication-facing unit.

Reader position is not project role. Reader position, audience, target user model, verifier position, reviewer position, and learner position do not become project roles, role assignments, decision authority, gate authority, issuer roles, or work roles unless a typed project-side value and reference instantiates that role relation.

Source-gap states. When the source relation is missing, say which source gap is present: 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 or register mismatch. Block only the unsupported effect and keep any reduced bounded use available.

Measure and display overread. A number, score, percentage, color, rank, confidence value, similarity value, dashboard state, or measurement display is orientation only until the measurement source, aggregation rule, time window, population or scope, calibration or evidence path, and intended use are governed by the typed project-side value named by value and reference. Evidence-like use applies A.10; assurance-like use applies B.3; gate-like use applies A.20 or A.21; work or reliance use applies A.15.4 and then the recovered typed project-side value named by value and reference; bridge or substitution use applies F.9 or F.9.1.

World-contact stop. Publication-facing units do not self-refresh after source update, revocation, policy change, holon-state change, incident, model update, environmental change, or new external observation. An outside change under the current use requires source refresh, reissued publication, or a new governed typed project-side value named by value and reference before work, evidence, gate, control, carrier, or other downstream use continues.

Functional-description boundary. A functional, architectural, descriptive, representational, or explanatory fit claim does not create permission, obligation, approval, gate passage, release source relation, performed-work evidence, or engineering justification. Those uses require the neighboring FPF pattern governing that claim and typed project-side value named by value and reference.

Mixed bundle no-shared-evidence-relation rule. A bundle with source-pinned, reduced-use, speculative, didactic, comparison, and evidence-facing parts is not interpreted under one shared evidence relation or use-boundary value borrowed from another member. Each operative claim keeps its own source relation and unsupported downstream use.

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

Comparison exposes conflict; it does not adjudicate it. A comparison note can 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 relation or substitution relation unless the neighboring FPF pattern governing that claim and typed project-side value named by value and reference carry that result.

Same publication-facing unit, multiple interpretations. A green release dashboard can be one MVPK face for source-finding, an A.10 currentness path or 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 under one shared evidence-relation class or bounded-use value by fluency alone.

Archetypal publication-use cases. Use these as quick recognition slices, not as a closed taxonomy:

• Green dashboard tile. A tile says Model ready. Treat the tile as the PublicationUnit when that tile carries the present release overread. The useful publication use is source-finding and status orientation unless an exact GateDecisionRef, gate profile, source relation, and evidence or currentness relation are recoverable. Without those, the tile is not release permission or gate passage by green color or placement.
• Generated explanation with source links. A generated text explains a method and cites sources. The explanation rendering is not source replacement. Source links carry only the pinned operative claims they actually carry. If work or reliance is present, use A.10 for the evidence path named by value or keep the rendering as reader help; if the rendering is deliberately reduced-use, use A.6.3.CSC.
• Comparison table. A table compares two methods and places one first. Ordering is not selection. The comparator or sorting relation, source references, shared review frame, and unsupported downstream claim remain visible. Choice or decision needs C.11; equivalence or bridge relation needs F.9 or F.9.1.
• Unrecovered source wording. A draft uses source-object wording, undeclared interpretive-view shorthand, or generic unit wording without naming the FPF kind. Recover the FPF kind and relation positions instead of minting source-relation pseudo-kinds or undeclared interpretive-view pseudo-kinds. Use PublicationUnit only when a bounded reader-inspected unit inside a publication is present; otherwise use the exact episteme, view, publication, carrier relation, section of a named non-pattern FPF publication form whose reader-help function and reference are recoverable, A.6.P relation claim, or typed project-side value named by value and reference.
• Translated tutorial. A translated tutorial can improve reader access to an FPF pattern. It is a derivative rendering, not the original source. Operative claims need source mapping for reliance, translated heads can need E.17.AUD.LHR or C.2.P, and F.18 is present only when durable naming, UTS, Core-facing, or cross-context naming work is intended.

Practical harm prevented by neighboring pattern. Use this map when the reader asks what the discipline buys in practice:

Blocked overread with useful publication use remaining.

• A comparison table appears to select option B. Block the selection interpretation when no C.11 ChoiceResult, decision record, or visible selection relation exists. Useful publication use remains: use the table as a bounded comparison under E.17.ID.CR, or apply C.11 when selection is intended.

• A green dashboard tile appears to permit release. Block the release or gate-passage interpretation when no GateDecisionRef, gate profile, evidence or currentness relation, and source relation are recoverable. Useful publication use remains: use the tile for source-finding and status orientation, then inspect the exact gate or evidence source if release work is intended.

• A generated explanation appears to prove a causal relation. Block the evidence or assurance interpretation when source pins and evidence path are absent or insufficient. Useful publication use remains: use the explanation as reader help or source-finding, then apply A.10 or B.3 only for the evidence named by value or engineering-justification claim they govern.

• C.2.P prevents the wrong object from being treated as source, the wrong relation from being treated as source relation, and a loose phrase from being treated as an FPF kind.

• E.17.AUD and E.17.AUD.OOTD prevent action on a publication unit whose primary entity of concern, carried publication move, or outside boundary shifted silently.

• E.17.ID.CR prevents a comparison unit from being used as decision, equivalence, bridge, evidence, or release source relation.

• E.17.EFP prevents fluent explanation from laundering unsupported claims into reliance, assurance, gate, or evidence use.

• E.17 MVPK prevents a readable publication face from being treated as evidence, gate, work, authority, or release source relation by display quality.

• F.18 prevents a local name from becoming global identity without context, kind, lineage, and bridge or cross-context naming relation.

Anti-escalation examples. Do not apply a neighboring pattern when its claim being made is absent:

• Do not apply F.18 when a one-off local phrase repair restores the local kind, relation, and bounded use without minting a durable reusable name.
• Do not apply A.10 when the publication-facing unit is not being used for reliance, evidence, provenance, currentness, or claim-bound evidence relation.
• Do not apply A.21 when a dashboard tile is merely status orientation and no GateDecisionRef or gate profile is present.
• Do not apply F.9 when a comparison does not claim sameness, substitution, bridge relation, or cross-context equivalence.
• Do not apply E.17.EFP when the text is only a same-entity rewrite or representation change governed by A.6.3.CR or A.6.3.RT.

Concrete reopen trigger. A reopen trigger names the condition and the nearest source-bearing side or governing pattern. A vague "reopen if needed" does not preserve the source relation.

#Declared publication-face kind values at Part E

Part E restricts publication-face kind values to the literals publication face/form and interop publication form. Concrete publication faces use names ending in ...View, ...Card, or ...Lane.

USM linkage (normative). Every U.View declares 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-use reliance still requires A.15.4 source restoration when the view is used for work or reliance, and the A.15 role, method, plan, and work source relation for the actor, target, context, scope, and time window in use. Cross-context views cite Bridge + CL; CL penalties apply to R only (scope membership unchanged).

Publication-face-kind naming discipline.

• Declared publication-face kind values: publication face/form, interop publication form.
• Concrete faces use names ending in ...View, ...Card, or ...Lane.
• The tokens carrier, bearer, and holder do not name a U.View or any publication entity. Use U.View (PlainView, TechCard, InteropCard, or AssuranceLane) for conceptual publication faces. Reserve carrier for symbol, document, data, transport, or display carriers and for U.Work over those carriers; source-currentness and evidence-provenance records are governed by A.10/G.6 when reliance is current.
• Avoid geometric metaphors such as axis or dimension for publication forms; use Characteristic or CharacteristicSpace only when referring to CHR-MM entities.
• Non-collision guard. ViewFamilyId is a lexical tag for viewpoint families; it is not used to name any U.View or publication-face kind. 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)
• InteropCard (conceptual interoperability view; mapping to concrete exchange formats lives in the interop annex; Part E does not specify schemas)

AssuranceLane can expose evidence bindings, evidence-carrier references, pins, and presence bits. It is not a B.3 assurance claim, readiness or 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 result, the governing source relation is B.3; the face only helps recover the cited evidence bindings.

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 reuse or ReferencePlane crossing; (ii) QD replay needs or 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 retains 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 or 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, and EditionId) for any numeric or comparable content, grounded in CHR and UNM.
5. Interop concern references (conceptual) for InteropCard (concerns and semantics only); any concrete schema or exchange mapping is outside Part E (Annex or 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).

#EntityOfConcern-side input and output vs publication (normative convention)

1. Input and Output are signature-side declarations. The Input and Output sections of a morphism describe declared input and output data or episteme types under the morphism signature; they do not depend on any publication face.
2. No duplication on faces. MVPK faces do not duplicate Input and Output lists; they publish a minimal profile: presence-pins, CG-Spec and CHR references, and EditionId only.
3. Signature reserved to signature-governed entities. Use Signature only for entities already governed by signature patterns, such as U.Signature. On faces, use TechName or PlainName.
4. Set-returning comparison. Whenever a face shows selection or comparison, it returns sets or declared partial orders and does not hide scalarization; cite a ComparatorSetRef for any total order.
5. Bridge crossing penalties. Crossings cite Bridge and CL; publish Φ(CL) and Φ_plane ids; penalties apply to R only (never F or G).
6. Carrier references and relation positions. On first mention, name carrier references and any A.10/G.6 source-currentness or provenance records when downstream reliance is current; keep U.Work occurrences distinct from epistemic claims via relation positions.
7. Publication is not execution. Faces carry no time or resource semantics; any build, render, or upload work 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 appear on MVPK faces under a declared scope and viewpoint.

Terminology (aligned with CHR-MM & UNM).

• Characteristic (U.Characteristic): a measured aspect as defined in CHR-MM (entity characteristic or relation characteristic with a chosen Scale).
• CharacteristicSpace (U.CharacteristicSpace): a CHR-typed product of slots used by dynamics and measurement theories (A.19).
• Publication characteristic (U.PubCharacteristic, PC): a declarative facet that a view, card, or AssuranceLane face can expose about a morphism under a stated Viewpoint. Each PC is grounded by CHR and CG-Spec publications and pinned by unit, scale, reference-plane, and 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 or 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 declared partial orders on faces.
• PC.CharacteristicSpaceRef? - optional pointer when a face cites the space in which a claim is interpreted (e.g., dominance on a declared space).

The catalog is open to extension through U.PubCharacteristic. PCs remain declarative and do not embed mechanisms.

Norms (E17-PC).

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

Publication faces and responsibilities.

• PlainView includes PC.Number only when fully pinned; otherwise it uses compare-only language.
• TechCard carries PC.Number, PC.ComparatorSetRef, and PC.CharacteristicSpaceRef? when faces enable declared ordering.
• AssuranceLane carries PC.EvidenceBinding and the pins for any numeric claims it relays.
• InteropCard references PCs conceptually while remaining notation-neutral in Part E; schemas map in the interop annex.

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

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

Extensibility.

• E17-PC-Ext-1 (Open catalog). New PCs are added under U.PubCharacteristic when they are declarative and CHR- and UNM-grounded.
• E17-PC-Ext-2 (Kinding). New PCs 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 or specification publication, edition-pin the reference (...Ref.edition) and document edition-change rules.

Adding invariants.

1. Place new invariants for PCs in CG-Spec (specification-use relation position), 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 or GateProfiles (A.21, including GateCrossing checks and crossing-visibility checks from E.18, F.9, and relevant Part G bridge or crossing wiring) to warn or block on invariant violations; never weaken functorial invariants.
4. State edition and edition-change rules; name the conformance check that detects the changed invariant and state the Lean-profile downgrade result (advisory vs block) where applicable.

#Author ergonomics (non‑normative)

Quick author steps (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 or explanatory-only.
3. no-new-claim diff: red-line against the governing Description episteme, including any Description episteme admitted for specification use, 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 or 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 are repaired 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 and 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 does not introduce new claims of the morphism.
3. Description-source and specification-use sourcing and EpistemicViewing compatibility (A.7 and E.10.D2, A.6.2–A.6.3, E.17.0).
   • (a) Inputs to Emit_s(-) are existing Description epistemes about the same arrow (for example, MethodDescription, MethodSpec when specification use has been granted by neighboring pattern governing the claiming gates). MVPK does not redefine, collapse, or create EntityOfConcern-to-Description or specification-use mechanisms.
   • (b) Each Emit_s(-) is realised as a species of U.EpistemicViewing (A.6.3) over those Description epistemes: entityOfConcern-preserving, effect-free, and conservative in the sense of A.6.2 and A.6.3. Publication adds no new commitments beyond what is present in the referenced Description episteme.
   • (c) Edition governance respects U.EditionSeries and UTS; rows remain the row identity handles for names; MVPK faces are re-emitted when the underlying Description episteme or specification-use editions change.
4. Pin discipline (Part F and Part G).
   • Any numeric or comparable content in a view pins {UnitType, ScaleKind, ReferencePlane}. EditionId can be coarse at Lean profiles; if units and scale are unknown, the face declares ordinal compare-only and keeps arithmetic outside the face until CHR pins are available. Pins upgrade monotonically with profile and risk.
5. No Γ‑leakage (publication independence). Publication morphisms carry no Γ_method, Γ_time, or Γ_work semantics. Any build, render, or upload activity is separate U.Work by a system or acting holon under current U.RoleAssignment over carrier/rendering infrastructure (A.7, A.15, A.10). Lean AssuranceLane face: AssuranceLane-Lite exposes only presence bits for {PathId or PathSlice?, Γ_time window?, BridgeId?}; unknowns propagate (tri-state) with an explicit {degrade|abstain|sandbox} policy note.
6. Carrier provenance. Every emitted view records carrier references and any A.10/G.6 source-currentness or provenance record ids on first occurrence when reliance, evidence, or replay is current.
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 and ReferencePlane bridging.
   • If a view crosses contexts or reference planes, it cites the Bridge + CL policy ids (A.7 §5.8, bridge crossing). Such crossings are 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, repair 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] does 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, source references, and IDs are present and that MVPK invariants are respected. Use OperationalGate(profile) GateChecks only when a present 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 specification toolchains.)

3. Optics-informed composition witness.

   • Profunctor and 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 or 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 episteme content to method-family selection, selected method, U.WorkPlan, performed U.Work, work-result record, and result measurement. The MVPK faces can 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 or control architecture. For those uses, the team first recovers the existing typed project-side value named by value and reference that carries the claim when available: work-relevant source restoration under A.15.4, project U.Method, U.WorkPlan, and dated U.Work occurrence under A.15 and A.15.1, evidence or provenance path under A.10, engineering-justification record under B.3, gate or constraint decision under A.20 or A.21, or supervisory or control architecture record under B.2.5. If no existing source carries the needed claim, create only a prospective repair request, prospective decision request, prospective work-plan entry, or explicit source-gap note; 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 does not function as the first universal MVPK gate.

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

#Core ordinary checks

#Conditional checks

#Anti‑patterns (with fixes)

1. “Presentation logic” as semantics. Fix: Move any logic to Describe_EoC_DescEp, an exact specification-use or episteme-refinement gate, CG‑Spec, or 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 plus CG and CHR references.
4. Viewpointless views. Fix: Define Viewpoint; attach concerns + conformance; re‑emit.
5. InteropCard equivalent to TechCard duplication. Fix: InteropCard can refine typing or shape but cannot contradict TechCard (reindexing monotone).

#Consequences

#SoTA Alignment: Adopted And 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.

(References are selected because they supply source material for local MVPK invariants and tests; MVPK remains notation-agnostic.)

#Relations

• Builds on: A.7 and E.10.D2 for carrier and front-end discipline plus the EntityOfConcern and Description-episteme boundary and specification-use gates; 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 and Part G for bridge, terminology, characteristic, and pin discipline.
• Constrains: publication-face-emitting automation and hand-written publication faces. They remain species of U.EpistemicViewing over existing Description epistemes, including Description epistemes admitted for specification use, and do not become a second EntityOfConcern-to-Description mechanism, specification-use gate, evidence path, gate decision, work occurrence, assurance record, release source, or bridge declaration by readable form.
• Neighboring-pattern boundary use: use the compact boundary aid in E.17:5.1d when a publication-facing unit starts carrying work, reliance, evidence, assurance, gate, release, bridge, explanation, comparison, retargeting, carrier, or front-end claims beyond ordinary publication use. This Relations section cites that aid instead of repeating the whole map.
• Part F bridge wording boundary: when the publication face uses or invites "same", "equivalent", "align", "map", substitutable, interchangeable, attribute, entity, or profile matching, or other bridge-wording claim pressure across contexts, the wording repair belongs to Part F and A.6.9; the bridge relation belongs to F.9 or F.9.1. E.17 does not create a local bridge taxonomy.
• Coordinates with: B-operators for no Gamma-leakage, C-cluster selection or archive patterns where views remain publication faces rather than selections, CHR and UNM for measurement and normalization semantics, F.9 or F.9.1 for bridge relation, A.6.9 for sameness wording, and the neighboring source patterns named above. This section names relation and neighboring-pattern boundaries for publication use; the operative governing claim or effect still comes from the present case and the compact boundary aid in E.17:5.1d.

#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 face names {PlainView(f), TechCard(f), …}) with: PublicationScope, ViewpointId, pins, CHR and CG references, carrier/provenance record ids when current, 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 or explanatory-only. Each face adds no new claims and pins unit, scale, reference-plane, and edition with CHR and CG references. InteropCard views clarify concerns and semantics only (concrete exchange lives outside Part E); AssuranceLane cites evidence carriers or provenance records through A.10/G.6 when reliance is current. Any cross-Context or cross-plane view cites Bridge+CL (Φ→R only). Publication build, render, or upload activity is U.Work on carriers, not a mechanism change.”

#E.17:End

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