#ExplanationFaithfulnessProfile - explanation classification 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 reviewers 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 / U.EpistemePublication, and not a second semantic track.

Governing move in plain terms. State how that rendering relates to already available source U.Episteme / U.EpistemePublication, source pins, traces, and provenance anchors, which explanation-use class it belongs to, and what downstream claim/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 / 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 unsupported downstream claim/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 exits 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 weakened rendering that now needs narrower allowed claim/effect, forbidden downstream claim/effect, and reopen to the fuller source U.Episteme / U.EpistemePublication (A.6.3.CSC), or downstream work/reliance, assurance, or gate-bearing content (A.15, A.20, A.21).

First output. One compact review note: explanation class, source anchor, allowed reader use, unsupported downstream use, and reopen or exit condition. MVPK face, pins, provenance, and source fields are inherited by reference unless ambiguity or load-bearing pressure makes them live.

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 -> hand off if reliance, evidence, work, gate, engineering justification, comparison, weakened-use, or new-claim pressure appears. Use E.17:5.1c for orientation use, reliance use, operative claim, unsupported 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/substitution, work/reliance, gate, evidence, assurance, retargeting, or carrier/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 unsupported downstream claim/effect is enough.

Load-bearing use. Open the fuller explanation review only when the rendering will guide work/reliance, be externally relied on, be disputed, cross context, affect person/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/reliance, evidence, approval, gate, or release.

Supported-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 allowed claim/effect, forbidden downstream claim/effect, and reopen to the fuller source U.Episteme / U.EpistemePublication; A.6.4 or OntologicalReframing govern changed described entity; and A.15, A.20, or A.21 govern the project records needed when explanation starts carrying downstream work/reliance, assurance, or gate-bearing claim/effect.

Common wrong escalations / exits. 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, move to E.17.ID.CR; if it is only same-entity rewriting or representation shift, move to A.6.3.*; if it is a deliberately weakened rendering whose narrower allowed claim/effect, forbidden downstream claim/effect, and fuller-source reopen now govern the case, move to A.6.3.CSC; if it is already making world, work/reliance, assurance, or gate-bearing claims, leave E.17.EFP for the more exact downstream pattern/source.

Generated-explanation repaired path. When a generated explanation is used to help reliance, this profile only states the explanation relation, source-finding posture, and E.17:5.1b source-support posture needed for the current use. 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 project source record that supports it in the relying context. If that path or source record is missing, create only a prospective repair/request/source-gap record or future evidence-work plan; it does not become retroactive support for the earlier explanation-based claim. 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, or work-occurrence support.

Derivative rendering/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 / 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 a typed project source record, but the support belongs to that exposed source record and source relation, not to the explanation rendering as a face. If the derivative rendering will guide work/reliance, A.10 must map every operative claim being relied on to the exact source passage, carrier path, or project source record that supports it; if the map or record is absent, only a prospective repair/request/source-gap record or future evidence-work plan may be created. If simplification or format change narrows allowed use, forbids downstream use, or requires return to the fuller source, use A.6.3.CSC rather than treating the derivative as ordinary explanation.

Placement. Profile governed by E.17.0 / 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.15; 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.

#Keywords

• explanation
• rendering
• derivative rendering
• adaptation source links
• source-pinned
• source-linked reconstruction
• didactic retelling
• speculative retelling
• generated-explanation source finding
• evidence binding
• admissible faces
• allowed use
• fuller-source return.

#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 / 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. 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 exit toward interpretation, retargeting, or world/gate governing patterns or authority sources.

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

#Informal definition

ExplanationFaithfulnessProfile is a review profile governed by E.17.0 / 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 / 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 / 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 / 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 reviewers state one published rendering's relation to the already pinned source U.Episteme / U.EpistemePublication.

#Local working vocabulary

This profile uses a small local vocabulary for review.

• Source U.Episteme / U.EpistemePublication = the already pinned source U.Episteme / 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 pressure is live: different classes across faces, source linkage dispute, connective reconstruction, reader-fit pressure, interaction/statefulness, derivative rendering, cross-context reuse, cited reliance, work/reliance, evidence, gate, engineering-justification, bridge, or coarsening pressure.

• profilePlacementRef = E.17/E.17.0-governed profile;
• governingPatternRef = E.17 / E.17.0;
• sourcePublicationOrRecordForm;
• targetPublicationOrRecordForm;
• changeTargetRef;
• describedEntityPolicy = preserve for explanation renderings over the same underlying source U.Episteme / 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? / downstreamAuthoritySourceRef?;
• admissibleFaces;
• SurfaceKind value when PublicationSurface / InteropSurface discipline is live;
• publicNamePolicy;
• explanationSourcePosture using the shared E.17:5.1b vocabulary when source pointer, source availability/retrieval, source use, source faithfulness, claim support, contradiction, omission, strengthening, 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 reader role or 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 source, publication face, or project source record unless another governing FPF pattern explicitly instantiates that object. The explanationClass value is a local source-relation/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-facing intervention claims, or a deliberately weaker source relation, 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 / U.EpistemePublication, and already published provenance anchors already fix a field honestly, the rendering may inherit that condition by explicit reference.

A fuller 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-allowed-claim/effect line, forbidden-downstream-claim/effect line, or fuller-source reopen rule because distinctions were deliberately weakened 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; move it to A.6.3.CSC Controlled Semantic Coarsening.

#What a reviewer checks first

A reviewer usually starts with four questions:

1. What exactly is the source U.Episteme / 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 weakened 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/effect would be wrongful (misuseRisk).

These fields do not create a new governance source. 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.

#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/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;
• move to SourceLinkedExplanationReconstruction when bounded connective prose is added but source linkage remains explicit;
• move to DidacticRetelling when reader-help dominates and some phrasing is intentionally more pedagogical than canonical;
• move to 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 deliberately weaker, narrower-use rendering 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, handoff, or fuller review.

Working rule:

• if addedLinkPolicy cannot be stated plainly, the rendering should drop to a weaker class, move to 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 weaker class, move to 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 packet

#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 / 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 be claim-attenuating but must stay source-linked; SpeculativeRetelling may widen explanatory language only when kept clearly off canonical faces and off gate-bearing claim/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 strengthened by more persuasive prose. Didactic and speculative renderings also state forbidden downstream uses whenever omissions, weakening, 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 handoff rule

This profile stays explanation-facing and episteme-facing. It does not govern bridge stance, retargeting, action selection, executable docking, gate-bearing claim/effect, or work enactment. If a case starts carrying one bounded comparative review case, rival interpretations, bridge-mediated comparison load, or world/gate consequences, it must move to the neighboring pattern or project source record that actually governs that claim/effect (E.17.ID.CR, F.9.1, B.5.2, A.6.4, A.15, A.20, A.21).

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

If a weakened explanation-like rendering needs narrower allowed claim/effect, forbidden downstream claim/effect, and fuller-source reopen to remain honest, the case hands off to 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 L/A/D/E claims on explanation faces (L/A/D/E here means A.6.B-governed law, admissibility, deontic/commitment, and effect/evidence claims);
• it does not replace bridge discipline, retargeting discipline, or world/gate handoff 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/provenance use requires a project evidence path governed by A.10; engineering-justification use requires an engineering-justification record governed by B.3; work-plan or work-occurrence use requires the project method/plan/work material governed by A.15; gate use requires the project gate/constraint decision governed by A.20 / 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 / 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 content.

#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 record or move to 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 exits 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 move to the project source record or neighboring pattern that governs that guidance rather than staying on an explanation face.

#Boundary to lighter explanatory note with fuller-source 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 allowed claim/effect, forbidden downstream claim/effect, and return to the fuller source U.Episteme / 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 handoff

If the rendering starts generating one bounded comparative review case, rival interpretations, bridge-mediated comparative claims, new hypotheses, or world/gate consequences, it must leave this profile and move toward the appropriate downstream source track (E.17.ID.CR, F.9.1, B.5.2, A.6.4, A.15, A.20, A.21).

#Bias-Annotation

Lenses tested: Gov, Arch, Onto/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, strong no-new-L/A/D/E discipline, A.6.3.CSC handoff when narrowed-claim source support becomes primary, and hard exits to interpretation, retargeting, work, and world/gate governing patterns or authority sources 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/reopen path needed for the declared safe next action.

Use core ordinary checks first. Conditional rows open only when reader-fit, bundle-local class difference, weakened class, connective reconstruction, derivative rendering, or downstream reliance pressure 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 unsupported downstream use are explicit. The compact note states source anchor, allowed reader use, unsupported downstream use, and reopen or exit condition.
3. CC-EF-5 — No new L/A/D/E claims on explanation faces. The no-new-boundary-claims rule is explicit on explanation faces; L/A/D/E refers to A.6.B-governed law, admissibility, deontic/commitment, and effect/evidence claims.
4. CC-EF-7 — No second face family. A 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 pin/provenance boundary explicitly.
3. CC-EF-6 — Boundary to interpretation, retargeting, coarsening, and world/gate handoff is explicit. The handoff boundary is explicit, including A.6.3.CSC Controlled Semantic Coarsening when a narrower allowed claim/effect, forbidden downstream claim/effect, or fuller-source 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 — Weakened classes publish forbidden downstream uses. Didactic or speculative renderings, and any rendering with downgraded reliability transport, 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/reliance maps each operative claim to the exact source passage, carrier path, or project source record that supports it, or else downgrades to reader help / A.6.3.CSC as appropriate.

#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/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 move because the rendering has stopped being only explanation-facing support.

#SoTA Alignment: Adopted/Adapted Invariants And Rejected Shortcuts

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

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

#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.20, A.21
• Primary governing-pattern relation and main exits: this profile stays governed by E.17.0 / E.17; any move toward new semantics, coarsened narrowed-claim rendering, or gate-bearing claim/effect exits the profile
• Boundary notes: comparative-interpretation cases exit to E.17.ID.CR ComparativeReading; deliberately weaker explanation-like renderings whose narrower allowed claim/effect, forbidden downstream claim/effect, and fuller-source reopen are primary move to A.6.3.CSC Controlled Semantic Coarsening; retargeting exits to A.6.4; world/gate-bearing consequences exit to A.15, A.20, or A.21.

#E.17.EFP:End

---

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