E.17 - Multi‑View Publication Kit

Status: Stable Type: Part E publication pattern Normativity: Normative unless explicitly marked informative

At a glance. Use E.17 when one already accepted engineering account must be published in one or more readable faces for different readers without changing its claims.

Use this when. The source account is already accepted for the present work, but a reader needs a plain explanation, technical card, interoperability card, or evidence-facing lane. The publication task is to expose the same account for that reader, not to create a new engineering claim or establish performed Work, gate passage, or assurance by presentation.

What goes wrong if missed. A readable face can silently add, widen, or hide claims. The opposite failure is to make every publication start with a four-face kit, a newly authored viewpoint or bundle, and an assurance dossier even when one small face would answer the reader’s question.

What this buys. Each current reader gets the smallest useful face, the source remains recoverable, omitted detail and bounded use stay visible, and stronger identity or assurance apparatus is added only when a downstream use needs it.

First action. Point to the current source account and the engineering object or relation it describes, name the reader and what that reader must be able to understand or do, and choose only the face or faces needed for that use. Resolve an existing viewpoint when one already fits; do not author a new viewpoint or bundle merely to start publication.

First output. One useful publication face, or the smallest necessary set, that names the source, intended reader/use, what it preserves or omits, and how to return to the source. No ClaimGraph, formal profile, viewpoint bundle, evidence package, or four-face completion is required for this ordinary result.

Working publication move. Select the current source; choose the minimum face set for the named readers; copy or conservatively arrange only source-backed claims; mark material omissions and the bounded use; publish and stop. If a face will carry safety, release, evidence, cross-context, or other consequential reliance, strengthen only that face with the relations and records that the reliance needs.

Ordinary formality rule. A source pointer, reader/use line, readable face, and visible omission or return note are enough when the face is used for orientation, inspection, explanation, comparison, exchange preparation, or planning preparation and no downstream identity depends on it.

High-reliance formality rule. When reliance changes the engineering move, identify the exact source edition; resolve the exact viewpoint and E.17.0 conformance only if U.View membership matters; identify the E.24.PUB publication occurrence, form, carrier, and bounded use when their identities matter; and cite the concrete evidence, gate, release, provenance, or assurance record that carries the downstream claim. These additions do not turn the face itself into that record.

Stop condition. Stop as soon as every current reader has a useful face that preserves the needed claims and exposes its return to source. Do not create unused faces, fields, viewpoints, bundles, or assurance records for kit completeness.

Boundary aid pointer. Use E.17:5.1d only when a publication-facing unit begins to carry a distinct work, evidence, gate, approval, status, explanation, comparison, or reduced-use claim. Ordinary publication of a source-backed face does not require that boundary map.

At the first screen, keep only the current source, named reader/use, minimum useful face set, visible omissions, and return to source.

Not this pattern when. Use A.15.1 for a performed-work claim, A.10 for an evidence or provenance path, B.3 for assurance or engineering justification, A.20/A.21 for constraint or gate decisions, A.7 when carrier, publication, and Work are conflated, and the relevant release or authority rule when that is the actual problem. E.17 only publishes the already accepted account and keeps those downstream claims separate.

Tech-name: MultiViewPublicationKit (MVPK)

General publication-face form: In E.17, MVPK face refers by default to the publication form. The selected source episteme, any separately constructed receiving episteme, the bounded-use declaration, the publication occurrence, and the carrier remain different objects and are named explicitly whenever one of them is meant. A face is not a U-kind and does not become a U.View, evidence, assurance, gate decision, work occurrence, authority, or release permission by its label or readability. Source-edition, viewpoint, scope, occurrence, form, carrier, pin, or downstream-record identities are stated when they change the receiving use. USM binding (overview): when publication-scope identity must travel, U.PublicationScope under A.2.6 carries that bound; an ordinary bounded-use line can precede that exact record. See §5.0. Episteme-side view position. MVPK can publish an already recognized U.View, or it can publish another selected episteme without claiming view membership. When U.View membership is material, E.17.0 tests that same episteme against the exact U.Viewpoint episteme resolved from publicationViewpointRef; PublicationVPId is the viewpoint episteme’s designator, not the reference. A.6.3 construction, E.17.0 conformance, E.24.PUB publication occurrence/form/carrier, and C.29 representation remain separate relations.

E.17:1 - Intent

Let a practitioner publish the few readable faces that current readers actually need from one accepted engineering account, without adding claims or turning publication metadata into engineering authority. The optional morphism profile keeps the earlier compositional publication tests for uses that genuinely publish morphisms; it is not the entry price for ordinary publication.

E.17:2 - Problem frame

• Different readers often need different slices or presentations of the same accepted account, but a current task may need only one or two faces rather than the full quartet.
• Informal renderings can drift semantics, hide omissions, or sever source return; composite morphisms can also lose traceability when their publication claims are used compositionally.
• PlainView, AssuranceLane, and a packaged viewpointRef are easy to overread as U.View membership, assurance, or conformance even though none establishes those claims by itself.
• Exact publication identity, pins, carrier relations, and evidence references matter for some receiving uses, but putting all of them before the first readable face makes ordinary publication unnecessarily hard.

MVPK therefore starts from the current source, reader/use, and minimum useful face set. It then adds viewpoint conformance, E.24.PUB occurrence/form/carrier identity, pins, bridge records, evidence, or assurance only when a named use depends on those distinctions. The optional morphism profile retains the functorial publication discipline for Description epistemes, including Description epistemes admitted for specification use. Part E is conceptual: no machine-exchange formats are specified here.

E.17:3 - Problem

1. Semantic drift in publication. Unchecked presentations introduce claims not present in the exact C.2.1 source epistemes, including those about the arrow in the optional morphism profile. Each such episteme, including a Description episteme admitted for specification use, keeps its exact claim content, EntityOfConcern, and effective U.ReferenceScheme; publication form, viewpoint reference, scope, or carrier supplies none of those identity discriminators.
2. Non‑compositionality in the morphism profile. Publishing g∘f yields faces that do not match composing the faces of f and g.
3. View, viewpoint, and face confusion. A template or face is treated as the view or viewpoint, with no exact conformance relation between two claim-bearing epistemes.
4. Unpinned numbers. Numeric claims lack unit, scale, reference‑plane, and edition pins from Part F or Part G, undermining auditability.

E.17:4 - Forces

E.17:5 - Solution — the MVPK Kit

E.17:5.0 - Publication-scope and face-profile binding (normative)

• Ordinary selection. Start with the current source account, intended reader/use, and the smallest publication-form set needed now. A one-form result is valid; adding another form requires another current reader/use or a material distinction that the first form cannot carry safely.
• Bounded use before exact scope. Alongside each selected publication form, state the separate bounded-use declaration in ordinary prose. Identify an exact U.PublicationScope under A.2.6 when scope identity must travel across publication, comparison, exchange, dispute, or reliance. The scope establishes neither U.View membership nor permission, evidence, work, assurance, or release, and it encodes neither the selected source, viewpoint, publication-form profile, Publication Characteristics, nor carrier.
• Resolve before authoring. Reuse an existing viewpoint when its concerns and rules fit the reader/use. Author a new reusable viewpoint, or create a project-local family declaration under E.17.1, only when the current need cannot be served truthfully by an existing viewpoint or a simple bounded publication face. E.17.0 tests viewpoint conformance. Use E.17.1 to identify the catalogue edition, ordinary family designator, local declaration claim block, and needed U.ViewpointRef subset.
• Optional profile. A formal MVPK profile fixes exact publication-form designators, any declared partial order, Publication Characteristics and pins, and any cross-context or reference-plane constraints. These fields apply only to the optional formal or load-bearing branch, not to the ordinary first result.
• Canonical labels. PlainView, TechCard, InteropCard, and AssuranceLane are historical MVPK face designators. None identifies a U.View, U.Viewpoint, evidence object, assurance result, or gate. Use only the designators needed by the current readers; MVPK-Max is the optional profile in which all four have an actual use.

E.17:5.1 - Terminology (normative)

• View (U.View): the same C.2.1 episteme individual for which EpistemeViewpointConformanceRelation(E,P) obtains under E.17.0 for an exact U.Viewpoint episteme P. A publication-form label, viewpointRef, direct authoring, A.6.3 construction, or publication occurrence does not establish that membership. An ordinary publication form exposes its current source reference and separate reader/use declaration; add the exact publicationViewpointRef, conformance relation, scope, occurrence, carrier, or pins only when those identities change publication or reliance.
• Publication vs expression vs bearing vs presentation vs rendering vs representation (guard):
  • Publication occurrence = the E.24.PUB EpistemePublicationRelation among the selected episteme edition, audience declaration, bounded-use declaration, publication form, and U.PresentationCarrier. Ontically these participants stay distinct; spell out their exact identities when availability, recurrence, dispute, cross-context exchange, or reliance depends on them. Preparing or inspecting an ordinary face need not begin with a five-participant dossier. A.6.3 construction and E.17.0 conformance remain separate.
  • Form expression = PublicationFormExpressionRelation among the selected edition, exact publication form, and bounded-use declaration. It states that the form expresses enough of that edition for the use; omission, coarsening, or changed admitted operations can end it without changing the carrier.
  • Carrier bearing = PublicationFormBearingRelation between the exact U.PresentationCarrier and exact publication form. It states that this carrier bears the recoverable form; it is neither publication availability nor episteme identity.
  • 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; performed rendering is separate U.Work on its exact carrier, not a publication-face kind or publication occurrence.
  • Representation = a C.29 representation and its exact correspondence to independently recovered objects or relations; it is not a publication occurrence, publication form, view-membership rule, or carrier. Publication or representation does not by itself make any represented object or relation exist.
• Architecture-description mapping note. An architecture viewpoint maps to one exact U.Viewpoint episteme; PublicationVPId or EngineeringVPId designates it and a U.ViewpointRef resolves it. An architecture view maps to one exact episteme that passes E.17.0 conformance. An MVPK face is the separate publication form through which that episteme may be exposed for a separately declared bounded use and, when material, in an exact publication occurrence.
• Publication work: Build, rendering, upload, or delivery may be actual U.Work performed by an exact System recovered through A.13. When such Work is current, A.15.1 independently identifies the Work, performers, Method, time, and containing System. Add F.6 only when the publication account expressly consumes precise assignment-bound attribution through the same obtaining A.13 assignment; missing or failed F.6 leaves the Work intact. Name a carrier relation separately only when the claim or downstream use depends on it.
• Viewpoint (U.Viewpoint) - an exact claim-bearing episteme edition recognized under E.17.0’s dependent-kind rule. Resolve an existing viewpoint when it already states the relevant concerns and conformance rules. Author a new reusable viewpoint, or create an E.17.1 local family declaration inside an exact catalogue episteme edition, only when the current reader/use cannot be served truthfully without that separate result. The declaration packages exact U.ViewpointRef values; it is not another bundle entity. PublicationVPId designates the viewpoint episteme; U.ViewpointRef resolves it.
• Explanation-use profile values. An existing publication form can be paired with a bounded explanation-use profile value such as SourcePinnedExplanation, SourceLinkedExplanationReconstruction, DidacticRetelling, or SpeculativeRetelling; the profile value is neither the form nor a new face, explanation, or carrier-rendering kind. Pins, provenance references, and no-new-A.6.B-boundary-claims discipline apply only when the exact source, transformation, or receiving use makes them material.

E.17:5.1a - Episteme-publication relation-position binding (normative)

For functional-description publications, E.17 covers only the publication relation.

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, a work claim, gate passage, evidence, assurance, engineering justification, supervisory relation or control relation, authority, 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 that operational claim with its project claim set and exact reference. Apply the boundary, interface, protocol, or transformation rules in A.6.B, A.6.C, or E.18 as the concrete claim requires; do not absorb it into the 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 a project-side object or relation beyond the publication face, first recover the existing reference that actually carries that claim. The bullets below are different concrete checks, not one grouped route or generic pattern relation:

• source wording, publication construction, carrier-relation construction, source relation, project-side reference, or explicit non-use disposition under C.2.P;
• appearance-based reliance repair 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;
• supervisor-subholon feedback record under B.2.5, control-structure-view record under C.30.LCA, or a record of the exact architecture claim under C.30 or selected-structure claim under A.22, as applicable;
• carrier, export, OCR, or front-end distinction under A.7, followed by the applicable carrier, front-end, or Work pattern;
• 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 FPF kind and reference named by value 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 missing-source-relation 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 separates the source U.Episteme or episteme-side U.View, the exact publication form (the MVPK face), any present carrier or rendering work, the separate bounded-use declaration, 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 distinction among U.Episteme, contingent published-episteme use, publication occurrence, publication form, U.View, U.PresentationCarrier, and authority-reference relation. It introduces no durable published-episteme kind or other generic semio kind. A publication face does not define another relation’s claim, supply authority, or become the source claim merely by being published; use the exact source or authority relation when one is current.

When a morphism publication is encountered or reused, name only the relation positions needed by the current use:

• the selected source U.Episteme, D episteme, or S episteme edition and the claims actually exposed; identify its exact ClaimGraph only when claim identity must travel;
• the exact PublicationFormExpressionRelation occurrence among that selected edition, exact form, and exact bounded-use declaration;
• the exact PublicationFormBearingRelation occurrence between the presentation carrier and form;
• the exact five-participant EpistemePublicationRelation occurrence when that selected edition is available to the declared audience for the bounded use;
• the selected episteme’s independent E.17.0 U.View membership when the publication use calls it a view, plus any separate A.6.3 construction history when current;
• the exact system-performed carrier or rendering Work; any A.10 evidence/provenance path or G.6 path citation needed to replay it; and any G.11 currentness result, only when those neighboring facts are current; and
• the exact project-side object, reference, or authority relation when the next work or reliance claim depends on it.

Changed claim content, EntityOfConcern, or effective reference scheme identifies another episteme edition under C.2.1. Re-evaluate PublicationFormExpressionRelation only when its selected edition, form, bounded-use declaration, or obtaining predicate changes; re-evaluate PublicationFormBearingRelation only when its carrier, form, or obtaining predicate changes. Independently, changing any of the five EpistemePublicationRelation participants identifies another publication occurrence without reidentifying an otherwise unchanged episteme. Publication availability lost and later restored creates a later occurrence; a file rename or layout change alone proves none of those changes. The practical payoff is that a reader can recover which object or relation is available for reliance: the episteme claim, the published form, the view, the carrier, the typed project-side FPF kind and reference named by value, 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 establish the source claim or effect, gate decision, evidence relation, assurance claim, local system-role kind, separate System-classification judgment, assignment occurrence or state, direct status predicate, responsibility or authority predicate, Work occurrence, or permission. If its source uses role or status without making one of those claims clear, treat that phrase as unresolved recognition wording and route it through E.10.ROLE; then use the recovered direct pattern or return the exact missing governor.

Source-exposure rule. A face, carrier, rendering, dashboard tile, credential view, status view, comparison unit, explanation, signed memo, release record, approval publication, or gate dashboard exposes another project-side object only when that exact object and its direct relation are recoverable. Readability, layout, title, color, fluency, proximity, copying, generation, or reuse establishes none of them. If a real SpeechAct, GateDecision, evidence path, credential or status source, U.Work occurrence, U.Episteme, or publication occurrence is recoverable, rely on that object and relation; otherwise use the face only for orientation or source-finding.

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 missing-source-relation 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.

E.17:5.1b - 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 neither an ordered source-stage scale nor a source-record or authority taxonomy, and it does not substitute for evidence, assurance, gate, or work records. A missing source relation blocks only the unsupported use; it does not prove the underlying world claim false. If independent-verification-present is relied on, name the exact separate evidence, assurance, decision, work, or bridge record that supplies the independent basis.

E.17:5.1c - 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.

E.17:5.1d - 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 that claim recoverable. This compact boundary aid applies only to the present claim or effect; it does not classify the whole unit. The same unit can expose several typed records; handle one claim or effect at a time instead of assigning one source relation to the whole 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 the interpretation of its primary subject is unstable, apply E.17.AUD or E.17.AUD.OOTD before using E.17.ID.CR or E.17.EFP. Use EntityOfConcern(E) for that subject only when the unit carries one identified claim-bearing episteme E and both name the same exact entity.
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 path, including one that cites attestation, freshness, or a G.11 currentness result, 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 FPF kind and reference named by value 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 exact GateDecisionResult is recoverable with its decision subject, bounded action, profile application, check-application references, decision, action consequence, scope, window, and recheck condition under A.21. Add evidence, currentness, replay, or audit references only when the applicable rule or receiving use requires them. Without the required result and basis, the display remains orientation or source-finding only; color, label, layout, or proximity establishes neither gate passage, release permission, nor performed Work.

E.17:5.1e - 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 aids for one case. They are not U.Kind, RelationKind, evidence, gate, authority, work, publication face, or another project-side object unless the pattern that defines that exact object establishes its membership. When a local field starts carrying such a claim, cite the exact object and say whether the cited pattern defines it, constrains it, or supplies its test.

E.17:5.1f - Shared anti-overread invariants for publication-facing units

Use the FPF pattern that defines, constrains, or tests the claim being made or effect under use. Keep any local review field local, preserve reduced bounded use, and address only the unsupported wider claim or effect through the source relation it requires.

Source-relation minimality. Name the smallest direct relation sufficient for the live use. A source reference, publication occurrence, evidence path, engineering-justification record, gate decision, and release decision are different objects or relations; choosing one licenses none of the others. Do not apply A.10, B.3, A.20, or A.21 when the use needs only source-finding, orientation, or inspection of an existing source episteme, publication occurrence, 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 and bounded use. A visible Approved head needs a visible GateDecision or a different head; sorted output needs its comparator or sorting relation visible if no recommendation is intended; 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 can imply evidence, readiness, preference, equivalence, approval, or verification. Green can suggest readiness; top position preference; grouping equivalence; proximity to evidence an evidence relation; a badge approval; and a lock or checkmark verification. If that implication would change the next action, recover the exact evidence, assurance, gate, decision, recommendation, bridge, approval, or other record or relation that actually carries it, or redesign the face so the unsupported 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 face can carry orientation or source-finding cues. It carries no evidence, authority, gate, approval, engineering justification, work, currentness, or release relation unless the exact corresponding object and relation remain recoverable for that use.

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 face can keep the same layout, name, or carrier while its source pins, data window, source-relation status, currentness, EditionId, or bounded use changes. Visual sameness is not source, evidence, or use-boundary sameness. Beyond orientation, identify 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, use the face only for orientation/source-finding or reissue it from the source under E.17 and the concrete downstream rule that the new use needs.

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 changes, narrow the bounded use or apply the concrete definition, constraint, decision, evidence, work, gate, or authority rule that carries it. Comparison does not become recommendation or decision; explanation does not become evidence; a 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 a project system-role kind or assignment. Reader position, audience, target user model, verifier position, review-reader position, and learner position do not become project system-role kinds, U.SystemRoleAssignment occurrences, decision authority, gate authority, issuer relations, responsibility relations, or Work contexts by publication. If any of those values is current, cite its typed project-side reference and direct predicate separately; otherwise record the exact missing governor rather than inferring it from a reader label.

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; or mismatch among the source-maintenance System, any maintenance Work whose exact performer is recovered through A.13 and which A.15.1 admits independently, the status register, and a separately established responsibility relation. Add F.6 only when the source-maintenance comparison expressly consumes precise assignment-bound attribution; its failure leaves the maintenance Work intact. Assignment establishes neither source-maintenance responsibility, classification, nor status-register authority. Block only the unsupported effect and keep any reduced bounded use available.

Measure and display overread. Before relying on a displayed number, score, percentage, color, rank, confidence, similarity, or status, recover the exact claim and its source. Retain the characteristic or criterion, scale, scope, window, aggregation rule, calibration, or evidence basis only where the applicable pattern requires it or it changes the value’s interpretation. A status or ordinal judgment does not become a measurement by display. If the basis required for the intended use is missing, keep only the supported orientation or source-finding use. Use A.10 for evidence reliance, B.3 for assurance, A.20/A.21 for an actual constraint or gate claim, and F.9 only for a separately claimed Bridge or its bounded use; F.9.1 may add a stance note about an already constituted claim.

World-contact stop. When a source update, revocation, policy change, holon-state change, incident, model update, environmental change, or new observation changes a premise required by a downstream use, revalidate that affected use before it continues. Refresh the source, reissue the publication, or recover a changed project-side result as that use requires. Reuse unaffected results; a changed label or edition alone does not establish changed meaning or invalidate every publication use.

Functional-description boundary. A functional, architectural, descriptive, representational, or explanatory fit claim creates no permission, obligation, approval, gate passage, release relation, performed-work evidence, or engineering justification. Those uses need the exact separate work, authority, evidence, decision, gate, release, or assurance object and relation that carry the claim.

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 residue. It does not select an option, approve release, pass a gate, or create bridge or substitution relation unless the corresponding C.11, A.20/A.21, F.9, or other exact decision relation carries that result.

Same publication-facing unit, multiple interpretations. A green release dashboard can be one MVPK face for source-finding, an A.10 evidence/provenance path that cites a G.11 currentness result when the source 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. Recover the exact A.21 gate result and the source basis required by its profile application before using the tile as gate passage. A release claim also needs its own decision or authority basis. Without those, retain source-finding and status orientation only; green color or placement supplies neither result.
• 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 a Bridge needs F.9, while F.9.1 may add only an optional stance note about an established bounded-use claim.
• 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 FPF kind and reference named by value.
• 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 that interpretation when the exact gate result, its applicable profile and required check results, or the release decision or authority basis is not recoverable. Useful publication use remains: source-finding and status orientation, followed by inspection of the missing source when release 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 use A.10 for the evidence path or B.3 for the engineering-justification claim.

• 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 subject, 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 under A.6.3.CR or A.6.3.RT.

Concrete reopen trigger. Name the condition and the nearest source-bearing side or the concrete definition, constraint, test, decision, evidence, work, or authority relation to revisit. A vague reopen if needed does not preserve the source relation.

E.17:5.2 - Declared publication-face kind values at Part E