#ExplanationFaithfulnessProfile — explanation-use discipline over existing MVPK faces

E.17.EFP · Stable · Architectural (A) · Normative unless marked informative · Part E - The FPF Constitution and Authoring Guides

#About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a fpf-memory product feature page.

#How to use this pattern

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

Type: Architectural (A) Status: Stable Normativity: Normative unless marked informative

One-line summary. ExplanationFaithfulnessProfile states how explanation-facing renderings over already available claims, traces, and pins on existing MVPK faces may be used. It helps a publication-side reviewer or explanation reader distinguish source-pinned rendering, source-linked reconstruction, didactic retelling, and speculative retelling without creating a second face family or a second semantic rule track.

Governed object in plain terms. One explanation-facing rendering on an existing MVPK face; not the whole face family, not the whole source U.Episteme or source U.EpistemePublication, and not a second semantic track.

Governing move in plain terms. State how that rendering relates to already available source U.Episteme or source U.EpistemePublication, source pins, traces, and provenance anchors, which explanation-use class it belongs to, and what downstream claim or effect still stays outside the profile.

Use this when. Use this profile when one note, memo, sheet, screen, table, or short section is trying to help a reader understand an already available source U.Episteme or source U.EpistemePublication on an existing face and you need to say what kind of explanation it is without turning that help into a second semantic rule track.

Start here when. The first decision is about one explanation-facing rendering on an existing MVPK face, and the real question is whether it stays source-pinned, becomes bounded reconstruction, is openly didactic, or has already shifted into speculation or non-admissible downstream claim or effect.

What goes wrong if missed. Helpful explanation quietly turns into a second semantic rule track, hidden bridge-comparison load, or unsupported downstream guidance because the rendering is read as if it were canonical content.

What this buys. One honest explanation class on an existing face with visible source anchors, admissible-use boundary, and explicit neighboring-pattern boundaries when the rendering has stopped being merely explanatory help.

Not this pattern when. Not this profile when the real job is same-entity rewrite (A.6.3.CR), representation change (A.6.3.RT), bounded comparative reading (E.17.ID.CR), changed described entity (A.6.4), deliberately coarsened rendering that now needs narrower admissible claim or effect, non-admissible downstream claim or effect, and reopen to the source U.Episteme or source U.EpistemePublication (A.6.3.CSC), downstream work or reliance (A.15, A.15.4), assurance or engineering justification (B.3), or gate-bearing content (A.20, A.21).

First output. One compact explanation-use note: explanation class, source anchor, admissible explanation-reader use, non-admissible downstream use, and reopen or boundary condition. MVPK face, pins, provenance, and source fields are inherited by reference unless ambiguity or a load-bearing source-relation question makes them live.

Ordinary-output claim inventory. After ExplanationFaithfulnessProfile, the author has claimed only that this explanation-facing rendering has this explanation class, this source relation, this source anchor posture, and this admissible use. The author has not claimed model truth, evidence path, assurance, safe reliance, gate passage, work occurrence, release support, or source replacement unless the exact neighboring FPF pattern and exact project-side FPF kind and reference are named.

Working action spine. One explanation-facing rendering is helping a reader -> separate source-pinned rendering, bounded reconstruction, didactic retelling, and speculative retelling -> use the explanation for understanding, source navigation, bounded restatement, teaching, or exploration according to class -> output one class plus safe next action -> apply the neighboring FPF pattern if reliance, evidence, work, gate, engineering justification, comparison, narrower-use rendering, or new-claim load appears. Use E.17:5.1c for orientation use, reliance use, operative claim, non-admissible downstream use, and reopen trigger; use E.17:5.1d when the primary live question may be same-entity rewrite, representation change, coarsening, comparison, bridge or substitution, work or reliance, gate, evidence, assurance, retargeting, or carrier work or front-end work instead of explanation-facing rendering.

Ordinary use. If the explanation only helps reading, source-finding, review, comparison, or planning preparation, one compact review note naming the explanation class, source anchor, and non-admissible downstream claim or effect is enough. Plain wording remains ordinary unless it changes admissible use, support, evidence, gate, assurance, work, decision, or neighboring-pattern exit.

Load-bearing use. Open the fuller explanation review only when the rendering will guide work or reliance, be externally relied on, be disputed, cross context, affect person or team status, or be cited as evidence, approval, engineering justification, gate, or release support.

Stop condition. Stop once the explanation class changes no next reading, review, source-finding, comparison, or planning-preparation move and blocks no concrete overclaim about source support, work or reliance, evidence, approval, gate, or release.

Admissible explanation-use examples.

Neighboring project records and governing patterns. E.17.ID.CR governs bounded comparative reading; A.6.3.CR or A.6.3.RT govern same-entity rewrite or representation change; A.6.3.CSC governs a rendering that stays honest only through narrower admissible claim or effect, non-admissible downstream claim or effect, and reopen to the source U.Episteme or source U.EpistemePublication; A.6.4 or OntologicalReframing govern changed described entity; A.15 and A.15.4 govern downstream work or reliance, B.3 governs assurance and engineering justification, and A.20 or A.21 govern gate-bearing claim or effect.

Common wrong escalations and boundary transfers. Do not use this profile to hide new claims, bridge-comparison load, action-selection pressure, or gate-bearing guidance inside helpful prose. If the rendering is really a bounded comparison, apply E.17.ID.CR; if it is only same-entity rewriting or representation shift, apply A.6.3.CR or A.6.3.RT; if it is a deliberately coarsened rendering whose narrower admissible claim or effect, non-admissible downstream claim or effect, and source-bearing reopen now govern the case, apply A.6.3.CSC; if it is already making world, work or reliance, assurance, or gate-bearing claims, leave E.17.EFP for the more exact downstream FPF pattern or project-side record.

Generated-explanation repaired case. Use this case when a generated explanation is being relied on beyond reading help. The first E.17.EFP move is to classify the rendering as source-pinned rendering, source-linked reconstruction, didactic retelling, or speculative retelling. The profile only states the explanation relation, source-finding posture, source anchors, admissible explanation-reader use, non-admissible downstream use, and reopen condition for the current rendering. The explanation becomes usable for an operative claim only when an A.10-governed evidence path maps that claim to the exact source passage, carrier path, or exact project-side FPF kind and reference that supports it in the relying context. If the operative claim would raise assurance, release confidence, safety, trust, gate passage, work occurrence, work authorization, or approval, the receiving pattern must be opened for that exact claim: B.3 for assurance, A.21 for gate decision, A.15/A.15.1 for work, A.2.8/A.2.9 for commitments or speech acts, or another exact source when live. If the map or exact project-side FPF kind and reference is missing, keep only a prospective repair request, source-gap note, or narrower explanation-use note; if operative reliance is still attempted, the receiving A.10, B.3, A.21, or other exact relation may return evidence-needed, abstain, or no-supported-current-use for that attempted reliance. Do not open an A.10 path for ordinary reader help; otherwise the generated explanation remains reader help, not approval, authorization, evidence, assurance, gate passage, release support, or work-occurrence support.

Common wrong first reading. A fluent, confident, source-linked, or reliable-looking explanation is evidence. First honest entry: classify the explanation rendering and use it for reading or source-finding; only an operative claim with an A.10 evidence path or another exact receiving source can support downstream reliance.

Negative result: if a generated explanation says "reliable" but no operative claim maps to source support, the E.17.EFP result is source-finding only or reader help only. If an attempted downstream reliance is still raised, the receiving A.10, B.3, A.21, or other exact relation may return evidence-needed or no-supported-current-use for that attempted reliance. It is not weak evidence by style, confidence, fluency, or citation-like wording.

Generated-retelling survival. A generated retelling preserves only the reader help, source-finding cue, quoted source pins, explicitly repeated source relation, and explicitly repeated admissible-use boundary that remain inspectable in that retelling. It does not become or preserve the source U.Episteme, source U.EpistemePublication, evidence path, assurance, gate passage, decision status, permission, or source replacement merely by fluency, completeness-looking wording, or citation-like links. If the generated retelling compresses, omits, strengthens, or changes source claims, treat the result as a new explanation-use case, a narrower-use rendering under A.6.3.CSC, or reader help only.

Derivative rendering and adaptation source-link rule. A fork, adaptation, abridged guide, translated rendering, generated explanation, tutorial, access-format conversion, or other derivative rendering of a source U.Episteme or source U.EpistemePublication may improve access or teaching, but it is not equivalent to the source by usefulness, fluency, or local adoption. It may expose or cite an exact project-side FPF kind and reference, but the support belongs to the exposed value and source relation, not to the explanation rendering as a face. If the derivative rendering will guide work or reliance, A.10 must map every operative claim being relied on to the exact source passage, carrier path, or exact project-side FPF kind and reference that supports it; if the map or exact value is absent, only a prospective repair request, explicit source-gap note, or prospective evidence-work plan may be created. If simplification or format change narrows allowed use, forbids downstream use, or requires return to the source-bearing side, use A.6.3.CSC rather than treating the derivative as ordinary explanation.

Explanation-rendering identity over revision and regeneration. A generated, translated, revised, or regenerated explanation-facing rendering is not the same explanation rendering merely because it uses the same source face, prompt, template, carrier, or title. For use beyond ordinary reader help, the rendering must name the preserved source anchors, changed claims, generation or production basis when live, and admissible use for this rendering. A translation or adaptation preserves admissible use only when the operative claims and source links survive the change; otherwise it becomes a new explanation-use case, a narrower-use rendering under A.6.3.CSC, or reader help only.

Placement. Profile governed by E.17.0 and E.17 review. Builds on. E.17.0 U.MultiViewDescribing; E.17 MVPK; A.7; E.10.D2; A.6.B; F.9; F.18. Coordinates with. ConservativeRetextualization; RepresentationTransduction; E.17.ID.CR ComparativeReading; A.6.4; A.10; A.15; A.15.4; B.3; A.20; A.21.

The same underlying claim set often needs explanation-facing renderings on more than one existing face:

• an engineer-manager-readable rendering of a technical claim set;
• a technical explanation that makes source linkage more visible than the original source prose;
• a didactic retelling for onboarding or review preparation;
• a clearly marked speculative retelling that helps discussion but does not pretend to be canonical content.

#Relations

#Content

#Problem frame

The same underlying claim set often needs explanation-facing renderings on more than one existing face:

• an engineer-manager-readable rendering of a technical claim set;
• a technical explanation that makes source linkage more visible than the original source prose;
• a didactic retelling for onboarding or review preparation;
• a clearly marked speculative retelling that helps discussion but does not pretend to be canonical content.

FPF already has E.17.0 for viewpoints, views, and correspondences, and E.17 for typed publication faces. A compact review profile is still needed to say what kind of explanation-facing rendering is being published, how its source tether to the source U.Episteme or source U.EpistemePublication is stated, and where it is admissible.

#Problem

Without a dedicated profile:

1. source-pinned rendering, reconstruction, didactic simplification, and speculation blur together;
2. explanation prose starts behaving like a second semantic rule track;
3. publication-side reviewers cannot tell which faces remain admissible for a given explanation class;
4. pins, provenance, and evidence binding become optional rhetorical extras instead of explicit publication conditions;
5. explanation work quietly shifts into new claims, hidden bridge work, or gate-facing misuse.

#Forces

• Clarity vs semantic restraint. Explanation may help readers, but it must not mint new semantic commitments on publication faces.
• Face discipline vs reader fit. The same source may need different renderings, but all of them still live on existing MVPK faces.
• Traceability vs accessibility. Simpler renderings are useful only if readers can still recover how they relate to the source.
• Didactic usefulness vs policy misuse. A didactic or speculative retelling may help humans, but it must not masquerade as assurance or gate-bearing content.
• Explanation vs interpretation. Some moves still belong to explanation rendering; others should use interpretation, retargeting, or world or gate governing patterns or exact project-side FPF kinds and references.

#Solution — review profile for explanation renderings on existing MVPK faces

#Informal definition

ExplanationFaithfulnessProfile is a review profile governed by E.17.0 and E.17 for explanation-facing renderings over already available claims, traces, and pins on existing MVPK faces.

It does not create a new face family. It states how an explanation relates to its source U.Episteme or source U.EpistemePublication, what kind of augmentation is allowed, which evidence binding remains source-bounded, and on which existing faces the rendering may admissibly appear.

#Profile, case, and published rendering distinction

ExplanationFaithfulnessProfile is an intensional review profile governed by E.17.0 and E.17. Concrete explanation-facing renderings are passive published renderings or reviewed cases classified under this profile; the profile itself does not act, decide, or publish.

This distinction matters because the profile governs how a rendering is related to its source and reviewed. It does not turn every explanatory paragraph into a giant standalone record, and it does not replace MVPK face governance with a second semantic track.

#How to read this profile

This profile does not decide whether a claim is true. It says how an explanation rendering relates to already available source U.Episteme or source U.EpistemePublication, source pins, traces, and provenance anchors, and where that rendering may admissibly appear.

• Faithfulness names the review question for the rendering, not a pass verdict for every class.
• Class names are source-relation and admissible-use labels, not merit labels or proof that all classes are faithful in the same sense.
• Faces stay governed by E.17; the profile only constrains what sort of explanation is admissible on them.
• If a rendering begins to add new semantic commitments, it has left this profile even if the prose still looks explanatory.
• It helps a publication-side reviewer state one published rendering's relation to the already pinned source U.Episteme or source U.EpistemePublication.

#Local working vocabulary

This profile uses a small local vocabulary for review.

• Source U.Episteme or source U.EpistemePublication = the already pinned source U.Episteme or source U.EpistemePublication, source claims, traces, notes, pins, or provenance anchors that the explanation rendering depends on. This is not the MVPK face, not the SCR/RSCR carrier, and not an arbitrary carrier or physical item.
• Rendering = one published explanation-facing text on one existing face.
• Class assignment = the explanation-class assigned to that rendering on that face.
• Bundle-local class difference = a case where two renderings in one bundle admissibly carry different explanation classes.

These are review aids, not new governance kinds. Faces remain governed by E.17; this profile only qualifies explanation behaviour on those faces.

#Core profile fields

Most renderings reviewed under this profile need only the compact review note:

The fuller field vocabulary below opens only when ambiguity or load-bearing use is live: different classes across faces, source linkage dispute, connective reconstruction, reader-fit dispute, interaction or statefulness, derivative rendering, cross-context reuse, cited reliance, work or reliance, evidence, gate, engineering justification, bridge, or coarsening boundary.

• profilePlacementRef = profile governed by E.17 and E.17.0;
• governingPatternRef = E.17 and E.17.0;
• sourcePublicationOrRecordForm;
• targetPublicationOrRecordForm;
• changeTargetRef;
• describedEntityPolicy = preserve for explanation renderings over the same underlying source U.Episteme or source U.EpistemePublication;
• boundedContextPolicy;
• viewpointPolicy;
• referenceSchemePolicy;
• representationSchemePolicy;
• groundingPolicy;
• referencePlanePolicy;
• claimPolicy;
• claimScopePolicy;
• publicationScopePolicy;
• reliabilityTransportPolicy;
• pinningPolicy;
• provenancePolicy;
• lossProfile;
• claimContinuityClass;
• microtheoryContinuityClass;
• onticContinuityClass;
• bridgeRequirement;
• worldContactPolicy;
• evidencePolicy;
• gatePolicy;
• workCrossing;
• upstreamGoverningPatternRef?, upstreamAuthoritySourceRef?, downstreamGoverningPatternRef?, and downstreamAuthoritySourceRef?;
• admissibleFaces;
• SurfaceKind value when PublicationSurface or InteropSurface discipline is live;
• publicNamePolicy;
• explanationSourcePosture using the shared E.17:5.1b vocabulary when source pointer, source availability or retrieval, source use, source faithfulness, claim support, contradiction, omission, claim widening, added linkage, independent verification, admissible use, forbidden downstream use, or reopen trigger could diverge;
• no generic source-relation field; source support is recorded through explanationSourcePosture;
• augmentationRelation;
• addedLinkPolicy when SourceLinkedExplanationReconstruction adds bounded connective prose;
• targetUserModel? when reader-fit materially shapes the rendering;
• interactionMode? when the explanation is more than one static explanatory paragraph;
• contrastiveQuestion? when the rendering is answering a specific user-facing contrast or why-question;
• allowedUse? when downstream use must be bounded by intended reader and task;
• misuseRisk? when over-reading pressure is part of the review load;
• evidenceRelation;
• noNewBoundaryClaims = true on explanation faces;
• compositionRule;
• reopenCondition.

These fields inherit the E.17:5.1e local-field rule. They classify one explanation-facing rendering for review; they do not create U.Kind, SurfaceKind, RelationKind, KindBridge, EvidenceKind, GateDecision, SpeechAct, Commitment, U.Work, authority reference, publication face, or exact project-side FPF kind and reference unless another governing FPF pattern explicitly instantiates that object. The explanationClass value is a local source-relation and admissible-use profile value, not ExplanationKind, not U.Kind, not EvidenceKind, not FaceKind, and not a truth certificate.

Where explanation crosses from source rendering into new claim production, hidden bridge work, gate-bearing semantics, world-changing claim or effect, or a source relation with declared source-loss mode, the profile no longer suffices and the case must leave this profile.

#Working-model first

Ordinary reviewed renderings do not need to restate every field from scratch. When the governing MVPK face, pinned source U.Episteme or source U.EpistemePublication, and already published provenance anchors already fix a field honestly, the rendering may inherit that condition by explicit reference.

A source-bearing review record becomes necessary when:

• explanation class differs across faces in the same publication bundle;
• the rendering relies on bounded connective prose that is not obvious from the source wording alone;
• didactic or speculative wording creates a real risk of policy, assurance, or gate misuse;
• source linkage, provenance, or reliability transport would otherwise become unclear;
• the rendering is a fork, adaptation, translation, generated explanation, tutorial, access-format conversion, or another derivative publication that may be mistaken for the source itself.

When one rendering needs its own narrower admissible claim or effect line, non-admissible downstream claim or effect line, or source-bearing reopen rule because distinctions were deliberately coarsened for reader fit, the issue is no longer only explanation class. Do not keep that case here as if it were merely one more helpful rendering style; apply A.6.3.CSC Controlled Semantic Coarsening.

#What a publication-side reviewer checks first

A publication-side reviewer usually starts with four questions:

1. What exactly is the source U.Episteme or source U.EpistemePublication for this rendering?
2. Which explanation class is being claimed for this rendering on this face?
3. Are the pins, provenance anchors, and evidence relation visible enough for that class?
4. Has the rendering quietly begun to add new semantic commitments, new face-like behaviour, derivative-source replacement, or a deliberately coarsened source rendering that needs A.6.3.CSC?

If these questions are answered clearly, the rendering often remains lightweight. If they are not, a fuller face-by-face review record is usually warranted.

#Interpretant-side block

This profile still governs explanation renderings on existing faces, not full interactive explanation systems.

However, when reader-help, onboarding, or contrastive explanation is doing real work, the rendering should also make visible:

• who the rendering is fit for (targetUserModel);
• whether the interaction is static, guided, contrastive, or another bounded mode (interactionMode);
• what question the rendering is helping answer (contrastiveQuestion);
• what interpretation or use remains admissible (allowedUse);
• and what downstream claim or effect would be wrongful (misuseRisk).

These fields do not create a new governing source relation. Their current role is narrower: stop explanation prose from pretending that every rendering is audience-neutral, and make misuse boundaries explicit when reader-fit is part of the explanation case. allowedUse is a local reader-fit field under admissibleUse; it is not permission, evidence support, or authority.

#Explanation class set

The explanation-class set used in this profile is:

• SourcePinnedExplanation
• SourceLinkedExplanationReconstruction
• DidacticRetelling
• SpeculativeRetelling

In field form, the local assignment is explanationClass = SourcePinnedExplanation | SourceLinkedExplanationReconstruction | DidacticRetelling | SpeculativeRetelling.

Class assignment is a source-relation and admissible-use classification. SourcePinnedExplanation is source-bound rendering, SourceLinkedExplanationReconstruction is bounded reconstruction with explicit added-link policy, DidacticRetelling is teaching and onboarding support, and SpeculativeRetelling is exploratory support. The last two classes do not assert the same kind of source faithfulness as SourcePinnedExplanation; they state the limits under which reader help remains admissible.

Safe next action by class:

These classes are publication-behaviour labels for one rendering on one existing face. They are not U.Kind values, not MVPK faces, and not semantic merit grades. They state how the explanation relates to the source, how much augmentation is tolerated, what reliability transport is still honest, and which faces remain admissible.

Class assignment is per published rendering on a face, not one blanket label for a whole multi-face bundle. If a PlainView rendering stays source-pinned while a TechCard rendering adds bounded connective prose, the bundle must state that class difference explicitly.

#Ordinary class-selection guidance

A practical reading order is:

• start with SourcePinnedExplanation if the rendering stays close to the source wording and keeps direct pins visible;
• choose SourceLinkedExplanationReconstruction when bounded connective prose is added but source linkage remains explicit;
• choose DidacticRetelling when reader-help dominates and some phrasing is intentionally more pedagogical than canonical;
• choose SpeculativeRetelling only when the rendering openly goes beyond source-backed explanation and remains confined to exploratory or didactic use.

The profile should not be used to make a rendering sound more respectable than its actual source relation warrants.

It should also not be used to keep one narrower-use rendering with declared source-loss mode inside explanation just because the prose is reader-friendly. If the rendering needs its own forbidden-use line and reopen rule to stay honest, explanation is no longer the primary question; use A.6.3.CSC Controlled Semantic Coarsening.

#SourceLinkedExplanationReconstruction added-link policy

When a rendering claims SourceLinkedExplanationReconstruction, it should publish a compact addedLinkPolicy whenever the connective move is not already explicit in the source wording.

Minimum reading load:

• addedLinkKind — what bounded connective move is being added;
• sourceAnchorSet — which pinned claims, traces, or notes support that move;
• boundednessReason — why the added link does not become an unsupported relation theory, modality lift, causal claim, bridge-comparison load, or policy-bearing reading;
• forbiddenLinkClass — which unsupported connective move is explicitly excluded;
• reopenTrigger — what would force downgrade, source-bearing return, or source-bearing review.

Working rule:

• if addedLinkPolicy cannot be stated plainly, the rendering should drop to a more restricted explanation class, use a more restricted MVPK face or named SurfaceKind value, or leave E.17.EFP;
• SourceLinkedExplanationReconstruction may not hide new relation theory, bridge equivalence, design-scope generalization, or policy-bearing guidance inside "bounded" connective prose.

#Working admissibility matrix

ExplanationFaithfulnessProfile ordinarily stays on PublicationSurface. Any appearance on InteropSurface must remain source-pinned and structure-preserving, and must never smuggle explanation-specific semantics into interop publication. Didactic or speculative restrictions are use-profile restrictions over existing faces, not new face kinds.

Source-pinned explanation on AssuranceLane-facing publication is exceptional rather than ordinary. Unless the governing face source explicitly permits that use with visible evidence carriers, source pins, and no added semantics, reviewers should treat AssuranceLane-facing explanation rendering as non-admissible.

DidacticRetelling and trace-free reader help are illustrative or analogical scaffolding only. Trace-free didactic material may carry analogy, scaffolding, or reader orientation, but any domain fact inside didactic prose must either be source-pinned or explicitly downgraded to non-canonical reader aid. It may not carry causal claims, policy claims, reliability claims, or canonical TechCard semantics. If didactic content appears near technical content, mark it as a boxed or otherwise clearly separated non-canonical reader aid rather than letting it merge into the technical source.

Every concrete explanation rendering must also publish the source claim IDs, pins, trace refs, or equivalent provenance anchors that justify its class on that face. If those anchors cannot be made visible on the chosen MVPK face or named SurfaceKind value, the rendering must drop to a more restricted explanation class, use a more restricted use profile, or leave the face.

When reader-help, onboarding, or contrastive explanation is part of the case, the rendering should also publish or inherit its targetUserModel, interactionMode, contrastiveQuestion, allowedUse, and misuseRisk so that user-fit does not quietly become policy guidance, assurance guidance, or gate-bearing guidance.

#Shared explanation rule set

#E.17.EFP:4.5.a. Preservation rule

Explanation-facing renderings under this profile preserve the same underlying described-entity line, bounded context, and source-pinned U.Episteme or source U.EpistemePublication. Viewpoint, reference scheme, representation scheme, grounding, and reference-plane handling must stay explicit rather than being left to prose. SourcePinnedExplanation and SourceLinkedExplanationReconstruction are expected to remain claim-conservative; DidacticRetelling may omit or simplify source claims but must stay source-linked; SpeculativeRetelling may widen explanatory language only when kept clearly off canonical faces and off gate-bearing claim or effect.

#E.17.EFP:4.5.b. Loss and reliability rule

A rendering assigned to one of these explanation classes declares what is omitted, reordered, simplified, or newly connected. Reliability transport may stay source-bounded or be explicitly downgraded, but it must never be silently widened by more persuasive prose. Didactic and speculative renderings also state forbidden downstream uses whenever omissions, declared source-loss modes, or trace-free additions occur.

When reader-fit is part of the explanation case, allowedUse and misuseRisk should be explicit enough that a didactic or contrastive rendering cannot be mistaken for assurance, policy, or gate-bearing guidance.

#E.17.EFP:4.5.c. Downstream-use and boundary rule

This profile stays explanation-facing and episteme-facing. It does not govern bridge stance, retargeting, action selection, executable docking, gate-bearing claim or effect, assurance, engineering justification, or work enactment. If a case starts carrying one bounded comparative review case, rival interpretations, bridge-mediated comparison load, world consequences, work or reliance consequences, gate consequences, assurance, or engineering justification, apply the neighboring FPF pattern and name the exact project-side FPF kind and reference that governs that claim or effect (E.17.ID.CR, F.9.1, B.5.2, A.6.4, A.15, A.15.4, B.3, A.20, A.21).

Interpretant-side fields do not weaken that boundary rule. They only bound reader use; they do not authorize unsupported downstream guidance.

If a coarsened explanation-like rendering needs narrower admissible claim or effect, non-admissible downstream claim or effect, and source-bearing reopen to remain honest, the case is governed by A.6.3.CSC Controlled Semantic Coarsening rather than staying in ordinary explanation-use discipline.

#E.17.EFP:4.5.d. Composition and reopen rule

Repeated SourcePinnedExplanation over the same pinned source may be idempotent. SourceLinkedExplanationReconstruction and DidacticRetelling are order-sensitive and must reopen when the source claim set, pins, provenance, or admissible-face assumptions change. SpeculativeRetelling must reopen whenever source binding becomes available or whenever the rendering starts to look like a canonical explanation rather than a clearly bounded exploratory retelling.

#Hard boundary rules

A rendering reviewed under this profile keeps the following explicit:

• it does not create a second face family;
• it does not turn faces into a second semantic rule track;
• it does not license new A.6.B boundary claims on explanation faces: law claims, admissibility claims, deontic or commitment claims, and effect or evidence claims;
• it does not replace bridge discipline, retargeting discipline, or world or gate boundary discipline;
• it does not let PublicationSurface and InteropSurface collapse into one undifferentiated explanation channel.

If explanation text starts carrying new semantic commitments instead of rendering or licensed explanation over existing ones, the case must leave this profile.

#Archetypal grounding

#Source-pinned explanation across multiple faces

Source claim slice. Claim D-14: Cooling loop CL-2 maintains the required temperature margin during standard load. Evidence pins: T-44, E-17.

PlainView rendering. Cooling loop CL-2 keeps the required temperature margin in standard operation. Source pins: T-44, E-17.

TechCard rendering. D-14 remains source-pinned to T-44 and E-17; this rendering only shortens and reorders the claim.

This stays within SourcePinnedExplanation because the rendering changes readability, not the semantic load.

#Source-linked reconstruction

Source slice. Claims D-14 and D-18 jointly constrain the safe operating window, but the relation is left implicit in the original note.

Published reconstruction. Claims D-14 and D-18 jointly bound the safe operating window; see the pinned source notes for the original wording and evidence anchors.

This stays within SourceLinkedExplanationReconstruction if the connective prose remains bounded and does not add new claims.

A minimal addedLinkPolicy for this slice would say:

• addedLinkKind = relation-explication only;
• sourceAnchorSet = {D-14, D-18};
• boundednessReason = makes an already implied joint constraint explicit without adding a new mechanism, policy conclusion, or unsupported modality lift;
• forbiddenLinkClass = design-scope robustness or gate-sufficiency claim.

#Selected-method explanation

Source slice. The method-selection note chooses method M-2 because the material stays below threshold T and resource window W is available. The same source says that work plan WP-17 and result measurement RM-4 are still required before and after execution.

Published explanation. Method M-2 is selected here because the material condition and resource window match the declared method family. Use WP-17 for planning and RM-4 for result measurement.

This may stay within SourceLinkedExplanationReconstruction when the explanation keeps its source anchors visible and only makes the already source-supported selection relation easier to inspect. It supports interpretation, source-finding, and selected-method inspection. It is not evidence that work occurred, not a gate decision, and not engineering justification. Evidence or provenance use requires a project evidence path governed by A.10; engineering-justification use requires an engineering-justification record governed by B.3; method-selection use requires project U.Method, work-plan use requires U.WorkPlan under A.15, and work-occurrence use requires a dated U.Work occurrence under A.15.1; gate use requires the project gate or constraint decision governed by A.20 or A.21.

#Mixed-face bundle with different explanation classes

Source slice. Claim D-31 and trace set T-8 jointly show that the reserve path remains available during the short overload interval.

PlainView rendering. The reserve path stays available during the short overload interval. Source pins: D-31, T-8.

TechCard rendering. D-31 and T-8 jointly support availability of the reserve path during the short overload interval; this rendering adds bounded connective prose to make the support relation explicit.

The PlainView rendering may stay SourcePinnedExplanation while the TechCard rendering is SourceLinkedExplanationReconstruction. The bundle is admissible only if that class difference is stated rather than hidden under one blanket label.

#Didactic retelling

Source slice. The pressure-control condition is satisfied whenever the reserve valve opens within 80 ms.

Didactic rendering. For onboarding: the system stays safe here because the reserve valve opens quickly enough; the exact threshold and source claim remain in the pinned technical note.

This stays in DidacticRetelling only if it is kept off TechCard or AssuranceLane faces where it could be mistaken for canonical semantics.

#Speculative retelling

Source slice. The pinned source notes record the observed recovery, but they do not explain why the recovery was so rapid.

Speculative rendering. One possible reading is that a temporary coupling effect accelerated recovery, but this is a reflective aid for discussion, not a source-backed claim.

This is admissible only as a clearly marked exploratory or didactic use on an existing face; it must not appear as policy-bearing, gate-bearing, or assurance-bearing claim material.

#Anti-example: explanation that quietly becomes a new claim

Source slice. The pinned source claims show the reserve path remained available during the short overload interval.

Overreaching rendering. The reserve-path design is therefore robust against short overloads.

This no longer stays inside explanation-use discipline. The rendering introduces a design-scope commitment that the pinned source does not state, so the case must reopen the appropriate source U.Episteme, source U.EpistemePublication, project record whose governing FPF kind is named, or apply the neighboring pattern that governs that commitment instead of hiding inside a face-local explanation label.

#Anti-example: reader help that quietly becomes policy-bearing use

Source slice. The onboarding note explains, in simplified prose, that the reserve valve usually opens quickly enough to keep the local pressure condition inside the tolerated window.

Overreaching rendering on an AssuranceLane-facing use. Operators may rely on this explanation as sufficient assurance that short overloads stay inside the tolerated window.

This also leaves the profile. The rendering is no longer only reader help over existing claims; it starts acting like policy-bearing or assurance-bearing guidance. The case must reopen, drop the explanation class, or use the neighboring pattern and exact project-side FPF kind and reference that govern that guidance rather than staying on an explanation face.

#Boundary to lighter explanatory note with source-bearing return

Source slice. The technical incident note says the reserve path remained available during the measured load band, but it also keeps one unresolved ambiguity about recovery latency.

Lighter explanatory rendering. In plain terms: the reserve path stayed available during overload recovery.

This does not remain ordinary explanation profiling. The lighter note suppresses the load-band condition and the unresolved ambiguity, so it can stay honest only through narrower admissible claim or effect, non-admissible downstream claim or effect, and return to the source U.Episteme or source U.EpistemePublication. Once those narrowed-claim conditions become primary, the case must leave ordinary explanation-use discipline and be governed as a coarsened rendering rather than as ordinary reader help.

#Class-specific reopen cues in the worked slices

• SourcePinnedExplanation reopens when the pinned source claim set, source pins, or admissible-face assumptions change so that the rendering can no longer remain omission-only and visibly source-bound.
• SourceLinkedExplanationReconstruction reopens when the connective prose begins carrying an unsupported relation, or when the source claim set changes enough that the bounded reconstruction is no longer plainly source-linked.
• DidacticRetelling reopens when the rendering moves onto TechCard or AssuranceLane-facing use, or when reader-help prose starts functioning as policy-bearing, design-bearing, or gate-bearing guidance.
• SpeculativeRetelling reopens when source binding becomes available, or when the rendering starts to behave like canonical explanation rather than clearly bounded exploratory help.

#Boundary to interpretation and world or gate use

If the rendering starts generating one bounded comparative review case, rival interpretations, bridge-mediated comparative claims, new hypotheses, world consequences, gate consequences, assurance claims, or engineering-justification claims, it must leave this profile and apply the neighboring FPF pattern and exact project-side FPF kind and reference that govern the claim or effect (E.17.ID.CR, F.9.1, B.5.2, A.6.4, A.15, B.3, A.20, A.21).

#Bias-Annotation

Lenses tested: Gov, Arch, Onto and Epist, Prag, Did. Scope: Universal for explanation-facing renderings that claim ExplanationFaithfulnessProfile on existing MVPK faces inside FPF. This profile intentionally biases toward explanation restraint on existing faces and against face inflation, second semantic tracks, and reader-help authority overread. The main mitigation is explicit admissibility by face, explicit no-new-A.6.B-boundary-claims discipline, A.6.3.CSC use when narrowed-claim source support becomes primary, and clear boundaries to interpretation, retargeting, work, and world or gate governing patterns or exact project-side FPF kinds and references when explanation stops being only explanation.

#Conformance Checklist

A conformance check is retained only if it changes the next admissible use of the explanation rendering, blocks a concrete overclaim, or preserves a source anchor or reopen condition needed for the declared safe next action.

Use core ordinary checks first. Conditional rows open only when reader-fit, bundle-local class difference, bounded explanation class, connective reconstruction, derivative rendering, or downstream reliance use is live.

#EFP-Core ordinary checks

1. CC-EF-1 — Explanation class is explicit. The explanation class is explicitly named.
2. CC-EF-3 — Source anchor and non-admissible downstream use are explicit. The compact note states source anchor, admissible explanation-reader use, non-admissible downstream use, and reopen or boundary condition.
3. CC-EF-5 — No new A.6.B boundary claims on explanation faces. The no-new-boundary-claims rule is explicit on explanation faces; the blocked claims are A.6.B-governed law claims, admissibility claims, deontic or commitment claims, and effect or evidence claims.
4. CC-EF-7 — No second face family. A publication-side reviewer can tell why the case remains explanation-facing rather than becoming a second semantic rule track.

#EFP-Conditional checks

1. CC-EF-4 — Interpretant-side block is explicit when reader-fit does real work. When onboarding, contrastive explanation, or other reader-fit shaping matters, targetUserModel, interactionMode, contrastiveQuestion, allowedUse, and misuseRisk are visible enough to review.
2. CC-EF-2 — Face and SurfaceKind boundary is explicit when live. When face placement, PublicationSurface, InteropSurface, pinning, provenance, or reliability transport is not already inherited by visible source reference, the rendering states the admissible MVPK face, SurfaceKind value, and required pinning or provenance boundary explicitly.
3. CC-EF-6 — Boundary to interpretation, retargeting, coarsening, and world or gate use is explicit. The boundary is explicit, including A.6.3.CSC Controlled Semantic Coarsening when a narrower admissible claim or effect, non-admissible downstream claim or effect, or source-bearing reopen condition becomes primary.
4. CC-EF-8 — Bundle-local class differences are explicit. When one publication bundle carries different explanation classes across faces, that difference is stated explicitly rather than hidden under one bundle-wide label.
5. CC-EF-9 — Source-loss or downgraded-reliability classes publish forbidden downstream uses. Didactic or speculative renderings, and any rendering with downgraded reliability transport or declared source-loss mode, state their forbidden downstream uses explicitly.
6. CC-EF-10 — Reopen triggers match the class. The published review note makes class-relevant reopen triggers visible when source claim set, pins, provenance, or admissible-face assumptions change.
7. CC-EF-11 — SourceLinkedExplanationReconstruction publishes addedLinkPolicy when needed. When bounded connective prose is doing real review work, the rendering states what link is added, why it remains bounded, and which unsupported link class is explicitly forbidden.
8. CC-EF-12 — Derivative renderings keep source links operative. A fork, adaptation, translation, generated explanation, tutorial, access-format conversion, or other derivative rendering that will guide work or reliance maps each operative claim to the exact source passage, carrier path, or exact project-side FPF kind and reference that supports it, or else downgrades to reader help or applies A.6.3.CSC as appropriate.
9. CC-EF-13 — Generated explanation reliance boundary is explicit. A generated explanation used beyond ordinary reader help states its explanation class, source-finding posture, operative claims, receiving pattern for each relied-on claim, and non-admissible downstream use. The explanation itself is not evidence, assurance, approval, gate passage, release support, or work authority.

#Common Anti-Patterns and How to Avoid Them

#Consequences

• Explanation classes become explicit and reviewable.
• Existing MVPK face discipline stays intact.
• Pins, provenance, and evidence-binding become structural, not rhetorical extras.
• The boundary to interpretation, retargeting, and world or gate work becomes easier to review.

#Rationale

Explanation help already appears on existing faces, and the nearest failure mode is to let helpful prose shift into hidden source claims, bridge-comparison load, or gate-bearing guidance. E.17.EFP gives the reader one practical benefit: they can tell whether a rendering is source-pinned, reconstructive, didactic, or speculative, and therefore whether it may stay as explanation help, must downgrade use, or must leave this profile because the rendering has stopped being only explanation-facing support.

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

Traditions covered. This profile binds itself to architecture-description governance, explainability and reliability guidance, and faithfulness evaluation for natural-language explanations.

Architecture-description governance tradition. E.17.EFP adopts the rule that reader-helpful renderings stay subordinate to the already governed source U.Episteme or source U.EpistemePublication rather than replacing it. Explanation therefore remains on existing faces and is judged against source claims, pins, and provenance anchors.

Explainability and reliability traditions. E.17.EFP adopts the distinction between source-bound explanation and merely plausible explanation prose. It rejects the still-popular shortcut in which fluent or pedagogically useful language is treated as sufficient evidence of explanation faithfulness.

Local stance. Best-known current practice supports a narrow rule: explanation renderings are admissible only when their class, source anchoring, evidence relation, admissible faces, and forbidden downstream uses remain visible enough that reader help does not become a second semantic rule track.

Action result from the explanation-faithfulness and retrieval-evaluation practice basis: fluent, source-linked, generated, retrieved, didactic, or pedagogically useful explanations do not become evidence, assurance, approval, gate passage, release support, work authority, or operative-claim support by fluency, plausibility, citation-like wording, or retrieved context. The local E.17.EFP result is explanation class, source anchor, admissible explanation use or source-finding posture, non-admissible downstream use, and operative-claim mapping to A.10 or another exact receiving pattern only when reliance is live. Reopen the explanation-use result when the source claim set, pins, provenance, retrieved context, generated rendering, admissible face, use escalation, or support for an operative claim changes.

#Relations

• Builds on: E.17.0, E.17, A.7, E.10.D2, A.6.B, F.9, F.18
• Coordinates with: ConservativeRetextualization, RepresentationTransduction, A.6.3.CSC Controlled Semantic Coarsening, E.17.ID.CR ComparativeReading, A.6.4, A.15, A.15.4, B.3, A.20, A.21
• Primary governing-pattern relation and main neighboring-pattern boundaries: this profile stays governed by E.17.0 and E.17; any shift toward new semantics, coarsened narrowed-claim rendering, or gate-bearing claim or effect leaves the profile.
• Boundary notes: comparative-interpretation cases apply E.17.ID.CR ComparativeReading; explanation-like renderings with declared source-loss mode whose narrower admissible claim or effect, non-admissible downstream claim or effect, and source-bearing reopen are primary apply A.6.3.CSC Controlled Semantic Coarsening; retargeting applies A.6.4; work and reliance consequences apply A.15 and A.15.4; assurance and engineering-justification consequences apply B.3; gate-bearing consequences apply A.20 or A.21.

#C.29 MLA relation

When an explanation-facing rendering uses a mathematical lens as part of an explanation, E.17.EFP still governs rendering class, source anchoring, evidence relation, admissible faces, and forbidden downstream uses. The applicable C.29 output for the stated use (MLA.LensCandidateNote, MLA.OneLine, MLA.MiniCard, or MLA.FullCard when required) may be cited only for the mathematical-lens adequacy part: candidate mathematical object, lens mapping mode, preserved and lost structure, exposed invariant or distinction, LensSupportPosture, admissible use, non-admissible use, and stop condition. It does not make the explanation faithful, evidence-bearing, or admissible for downstream use by itself.

#E.17.EFP:End

---

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