NSTD.5:5.1 - Worked example: a failure story that teaches a usable distinction

A learning narrative about FPF uses a dramatic failure story: a team blindly follows a pattern checklist and damages its project. The story is engaging, but it may over-persuade if it implies that FPF prevents all such failures or that the named team is evidence. NSTD.5 keeps interest useful and bounded.

NarrativeEngagementBoundary@FPFFailureStory:
  narrativeRenderingRef: FPFLearningRoute@v1
  engagementDevice: failed-use contrast with tension and repair
  protectedSourceStructureRefs:
    - pattern conditions
    - forces
    - neighboring exits
    - evaluation and improvement route
  intendedEffect: keep attention and make misuse recognizable
  persuasionOrHarmRisk: reader treats story as proof of FPF superiority or as blame of a real group
  sourceFidelityRisk: checklist failure hides the actual source relation being taught
  precisionBackoff: identify the fictional example and point to the pattern's conditions of use
  evaluationReturn: `NSTD.6` checks reconstruction, not emotional agreement

Before:

This disaster proves why teams must use FPF.

After:

In this fictional case, the team’s checklist still assumed a stable workload after demand had changed. Before repeating the old action, compare its conditions with the present workload. The example illustrates that mismatch; whether FPF improves actual projects is a separate question.