#First-Practical Entry and Pattern-Use Discoverability Discipline

E.11 · Stable · Pattern-language governance pattern (E) · Normative for FPF public entry, discoverability, and the publication units that carry them. · Part E - The FPF Constitution and Authoring Guides

#About this pattern

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

#How to use this pattern

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

Type: Pattern-language governance pattern (E) Status: Stable Normativity: Normative for FPF public entry, discoverability, and the publication units that carry them.

#Relations

#Content

#Problem frame

#Use this when

Use E.11 when a README scenario, Preface explanation, ToC cue, retrieval card, lexical query row, expanded case, or pattern-local recognition passage could change which FPF pattern a working reader should inspect first.

The ordinary reader does not arrive with a PatternID. They arrive with a project question: architecture, a working document, a comparison, a vague concern, an improvement, evidence, timing, causal use, a description, a name, wording, mathematics, state of the art, a local framework, system recognition, or system delimitation. E.11 gives that reader a recognizable entry without turning entry material into a second pattern body or universal method sequence.

First useful result. The reader can name the working situation, the first useful result or honest blocker, one direct pattern or small plausible set to inspect, and the ordinary stop or wrong-turn return. That is enough for ordinary entry; no card form, shortlist record, or project-local value is required.

Primary EntityOfConcern. One public entry or discoverability publication unit: README first-entry guidance, Preface principle explanation, ToC query material, retrieval cue, expanded entry-disambiguation case, or a pattern-local Problem frame.

Author and reader remain different. An FPF author or maintainer publishes or refreshes the public guidance. A practitioner, manager, or assisting agent reads it and opens the direct pattern; that reader is not thereby performing E.11 publication work.

What this buys. A cold reader starts from a real project question rather than FPF topology, while exact pattern authority stays in the direct pattern and duplicate navigation canons do not grow.

Not this pattern when. After one direct pattern is selected, use E.11.PUA to follow its Solution to the smallest independently governed result or an honest missing-basis stop. Use E.11.PUR when applicability, recommendation, coordination, or ordering among candidate pattern uses is the current question. Use the direct pattern for the actual result, plan, work, evidence, decision, authorization, or publication claim.

#Problem

Pattern libraries are difficult to enter from a working situation. A reader may see a long table of contents, search by a familiar word, or choose the first appealing pattern title. That choice can be premature because nearby cards may lead to different first results and different stop conditions.

Attempts to help can create a second problem. Public guidance becomes a numbered method, a shadow pattern body, or a form that asks the reader to fabricate project-local values before the direct pattern has been inspected. The discovery aid then competes with the patterns it should expose.

#Forces

#Solution - Give Each Entry Publication Unit One Job

Write the short public entry first: recognizable working situation, practical question, first useful result or honest blocker, direct pattern or small plausible set, and ordinary stop or wrong-turn return. If that prose is truthful and sufficient, stop. Add an expansion, exact result basis, or durable comparison only when ambiguity or a named receiving reliance needs it.

Use this distribution:

README is the single editable public entry set. If another publication form needs the same guidance, project it from README rather than maintaining a second version. Put any unique cue in the publication unit whose job matches it, then remove the duplicate row or index.

When discoverability has become use of one selected pattern, continue with E.11.PUA. When the live question is which applicable pattern use to recommend or how several uses relate, continue with E.11.PUR. Neither continuation turns a public entry order into a universal workflow.

For an FPF-grounded domain or local practice framework, README, Preface, ToC, cards, an all-in-one carrier, a skill pack, retrieval, or a callable access service may expose the entry. E.4, E.4.PFAD, and E.4.PFR still decide framework architecture and authority; the access carrier is not the pattern body merely because a reader reaches FPF through it.

#Public first-entry scenario and optional expansion

A public entry may be ordinary prose. It is sufficient when these values remain recoverable:

FirstEntryScenario:
  recognizableWorkingSituation
  practicalQuestion
  firstUsefulResultOrHonestBlocker
  directPatternOrSmallPlausibleSet
  ordinaryStopOrWrongTurnReturn

The sixteen semantic keys in E.11:4.5 identify situations, not steps. A reader may inspect any finite plausible set and stop as soon as one direct pattern is worth opening or no remaining entry can change that starting choice.

When an entry must show how the first move may continue without prescribing a workflow, make only these values recoverable: the starting cue, direct pattern or plausible set, first result or blocker, likely next readable outputs, continuation condition, and stop or return. Name candidate loci or an unfolding-family reference only when they change the reader's route. Reference an [A.22.CGUS](/generated/patterns/A.22.CGUS) UF.* family only when the represented conditional structure is actually admitted there; a readable continuation does not become a CGUS structure by being useful.

Use this internal explicitness ladder only when it helps decide where the explanation belongs; do not persist a score for every entry:

The ladder is a placement aid, not a completeness target. Higher is not automatically better.

The following context-free schemas are optional authoring support for a card whose result promise, boundary, or later reuse cannot remain truthful from the short prose alone. They are not a public form and contain no reader-project instance:

PracticalUseGuidance@FPFReadme <: U.Episteme:
  practicalUseKey: PracticalUseKeyValue
  publicSituationDescriptionRef: U.Episteme
  publicPracticalQuestionRef: PublicPracticalUseQuestion@FPFReadme
  publicObstacleDescriptionRef?: PublicPatternUseObstacleDescription@FPFReadme
  publicFirstResultSummaryRef: U.Episteme
  cardExpansionRef: PracticalUseCardExpansion@FPFReadme

PracticalUseCardExpansion@FPFReadme <: U.Episteme:
  guidanceRef: PracticalUseGuidance@FPFReadme
  candidateUseTemplateRefs[1..*]: PublicCandidatePatternUseTemplate@FPFReadme
  publicStopBoundaryRef: PublicPatternUseBoundaryConditionTemplate@FPFReadme
  publicReturnBoundaryRef: PublicPatternUseBoundaryConditionTemplate@FPFReadme
  publicWrongTurnRecoveryBoundaryRef: PublicPatternUseBoundaryConditionTemplate@FPFReadme
  publicStrongerNeighborBoundaryRefs[]: PublicPatternUseBoundaryConditionTemplate@FPFReadme
  publicCoarseningRows[]: PublicResultCoarseningRow@FPFReadme
  demonstrativeSliceRef?: DemonstrativeUnfoldingSlice@Context
  ordinaryWalkthroughRef?: PublicOrdinaryWalkthrough@FPFReadme

PracticalUseCardPublicationUnit@FPFReadme:
  conformsTo: E.17.AUD
  publishes: PracticalUseGuidance@FPFReadme
  linksTo: PracticalUseCardExpansion@FPFReadme

Use demonstrativeSliceRef only when the example independently passes A.22.CGUS admission in its declared illustrative bounded context. Otherwise use an ordinary walkthrough; no rationale record is required merely to say that an explanation is not a CGUS slice.

#Cold-reader recognition and grounded public value

Test every public entry against a first-time engineer, engineer-manager, or assisting agent who has not studied FPF. The heading and first sentence name a recognizable working situation; the next useful sentence names an imaginable first result or honest blocker and one direct-pattern distinction that changes the next action. PatternIDs, FPF kind names, internal quality language, and exact assurance fields remain later.

A public value claim is grounded when the reader can recover the project need, first useful result or blocker, why one direct pattern can help, and the ordinary boundary. Add the exact potential-result kind, identity or obtaining basis, result-relative object, or conditional receiver only when omitting it would change the truth, the starting choice, the stop, or a named later reliance. The entry may stay readable prose; the reader never has to fill a card before opening the direct pattern.

Keep the public set representative of FPF's range. Wording and description repair remain visible but do not dominate architecture, problem shaping, work, comparison, evidence, timing, causal use, mathematics, quality, improvement, framework authoring, system recognition, or system delimitation.

#Recover the direct object before a PatternID is known

Some readers arrive before a practical-use key is recognizable: a familiar relation, project, process, case, context, or problem phrase is already blocking the work, but its direct object is not exact. Give such readers an ordinary-language recovery route before asking them to compare PatternIDs. These routes are independent entry alternatives, not stages, a required form, or another card set.

Keep four moments distinct. Recognition says why the ordinary situation matches this route. Selection chooses the direct pattern whose Solution owns the expected first object. Use inspects and applies only the branch needed now. The direct result exists or the relation obtains only under that selected pattern; the entry cue returns either its smallest usable result or an exact blocker and creates neither.

Apply the same compact route shape each time: recognizable situation; practical distinction; expected first object; exact direct pattern; smallest usable result or honest blocker; ordinary stop; and one neighboring exit. Stop before signatures, card schemas, full methods, owner catalogues, or copied Solution prose.

• An obtaining relation must be referred to, and perhaps distinguished from a repeated episode. First name the exact participants and the readable direct relation, then open the pattern whose content defines or tests that relation. A current assertion can stop there when later work only needs to know whether the relation obtains. If history, comparison, another relation, or a declared operation application must distinguish this occurrence from another of the same kind, use A.6.REL and the relevant direct pattern's same-versus-new-occurrence rule before naming or referencing it. The smallest result is the readable direct assertion or, only when consumed, one recoverably individuated occurrence; a missing participant, predicate, current fact, identity rule, or relation rule is an honest blocker. Stop as soon as the named receiving use can use that result. If no current direct relation can state the needed claim after exact recovery, require A.6.RCD; a row, edge, identifier, report, or mention makes no occurrence obtain.
• Project, process, or case wording no longer reveals the subject of the decision. Open A.15.6 and recover the direct subject before using the management label. An actual project is one qualifying composite U.Work; a process concern selects one reusable U.Method, one exact U.Structure selected under A.22, or one TransformationFlowStructure; a case follows one exact affected referent or claim through the governed change history needed for closure and keeps one named downstream use outside that closure. The smallest result is that exact subject, the direct pattern used to identify or constrain it, and the bounded claim the current decision may make, or a missing identity, parthood, relation, closure basis, or information blocker. Treat target system as an ordinary cue for the exact project system-of-interest question. Keep an intended future system in plan or description content; keep plan or decision designation, every work-to-system fact, role interpretation, and role assignment separate. Stop when the direct subject and claim answer the decision. Use A.1.SCR only if whether the recovered exact entity is a U.System still changes that decision; a project suffix, team, plan, dashboard, or case file supplies no subject identity.
• A claimed bounded context may be only a label, boundary picture, team, or subsystem. Open A.1.1 with the engineering decision, one exact model edition, and its exact use locus. Recover the smallest direct applicability, assigned-Work use, or fixed-content coherence relation first and stop there when it answers the decision. Select a BoundedModelUseStructure under A.22 only when the joint organization itself changes the decision and all four discriminators are exact: independently identified constituents, selected obtaining relation occurrences, applied constraints, and one named selection-use frame. The smallest result is therefore one direct relation or that optional selected structure; a missing constituent, occurrence, constraint, or use frame is an honest no-structure blocker. Context Mapping remains a U.Method; any cross-context structure needs its own A.22 selection; and a scheme, scope, viewpoint, conforming view, representation, or diagram remains a different object. Stop at the direct relation or selected organization. Use E.17.0 only when the actual question is whether an exact episteme conforms to a viewpoint and is thereby a view. A bounded-context phrase creates no holon, subsystem, team, structure, relation, viewpoint, view, or representation.
• Problem-side material may describe a concern without identifying an actual Problem. Open C.22.PFR only when the claim may concern one obtaining ProblematicForRelation: an exact actual-condition occurrence and exact problem-criterion-applicability occurrence whose selected input is actually adverse. Keep that occurrence distinct from the predicate, applicability occurrence, assessment or evaluation, assertion and reliance, ProblemCard, forecast or modal concern, and current-solvability or continuation claim. The smallest result is an ordinary actual-problem sentence naming condition and value, criterion, entity and use, and applicability window, or an honest non-PFR classification or blocker when the condition, applicability, adverse input, or required PFR rule is missing. Stop as soon as the later use can distinguish actuality from problem-side claim material. Use C.22.2 when the useful object is a reviewable problem-side card or formulation rather than the world-side relation. One ProblemCard may describe no actual PFR; selecting or discovering a method changes only the current solvability or continuation claim, not PFR participants, obtaining, identity, or the adverse condition.

#Public helper epistemes

These helper epistemes are optional authoring or named-reliance support. Do not open them when the short public entry and direct pattern already make the result and boundary truthful. A pattern reference locates the exact FPF pattern episteme whose content is needed; it asserts U.MethodDescription membership only when A.3.2 establishes that membership and the current use depends on it.

PublicPracticalUseQuestion@FPFReadme <: U.Episteme:
  situationRef: U.Episteme
  questionDescriptionRef: U.Episteme
  likelyDirectResultDescriptionRef?: U.Episteme

PublicPatternUseObstacleDescription@FPFReadme <: U.Episteme:
  situationRef: U.Episteme
  obstacleDescriptionRef: U.Episteme
  obstacleEffectOnUseRef: U.Episteme

PublicPatternUseResultTemplate@FPFReadme <: U.Episteme:
  readableResultDescriptionRef: U.Episteme
  exactResultKindRef: U.Kind
  resultIdentificationQuestionRef: U.Episteme
  resultPatternLocator: U.EntityRef, locating one exact FPF pattern episteme
  resultIdentityOrObtainingBasisTemplateRef: U.Episteme
  resultRelativeGovernedObjectKindRef: U.Kind
  resultRelativeDirectBasisKind: directRelationOccurrence | operationApplicationBinding | localRelationBearingClaim
  resultRelativeDirectBasisTemplateRef: U.Episteme
  minimumUsableResultDescriptionRef: U.Episteme
  conditionalNextQuestionPatternRef?: U.EntityRef, referencing one exact FPF pattern episteme

PublicPatternUseBoundaryConditionTemplate@FPFReadme <: U.Episteme:
  boundaryConditionKind: recognizableCondition | stop | return | wrongTurnRecovery | strongerNeighbor | missingGovernor | missingInformation
  conditionDescriptionRef: U.Episteme
  relationFunctionClaimRef: U.EntityRef, referencing the exact pattern content that defines or constrains the boundary
  conditionalNextQuestionPatternRef?: U.EntityRef, referencing one exact FPF pattern episteme
  conditionalReceivingPatternPositionDescriptionRef?: U.Episteme

PublicResultCoarseningRow@FPFReadme:
  readableResultPhraseRef: U.Episteme
  exactResultKindRef: U.Kind
  resultIdentificationQuestionRef: U.Episteme
  resultPatternLocator: U.EntityRef, locating one exact FPF pattern episteme
  resultIdentityOrObtainingBasisTemplateRef: U.Episteme
  resultRelativeGovernedObjectKindRef: U.Kind
  resultRelativeDirectBasisKind: directRelationOccurrence | operationApplicationBinding | localRelationBearingClaim
  resultRelativeDirectBasisTemplateRef: U.Episteme

An expanded public template asserts no project result and contains no project value. It names only the exact positions needed to keep its promise or blocker truthful: the potential result and how it would be identified, the direct pattern whose content defines or constrains it, and any identity, obtaining, relative-basis, continuation, or receiving-use distinction that changes the branch. Method, plan, dated Work, transformation, evaluation, decision, and receiving-use identities remain absent unless the current promise or later reliance actually depends on them.

The result-relative basis template has exactly one category. A direct-relation template asks for predicate, participants, applicability, obtaining, occurrence identity, and direct governor. An A.6.1 template asks for operation, application, argument or result binding, and direct governor. An A.6.RCD local-claim template asks for one C.2.1 claim episteme with polarity, substrate or constructor, base predicates and their direct patterns, participants, case facts, and any support or warrant required by the later receiving use. The claim does not obtain, and A.6.RCD does not replace the base patterns. Result identity or currentness and result-relative basis are different public questions; they coincide only when the potential result is the same direct relation occurrence used to close the later application.

conditionalNextQuestionPatternRef is present only when the public branch itself promises a continuation or names a downstream reliance. A result template without such a continuation leaves it absent. A public stop, missingGovernor, or missingInformation boundary has no receiver. return, wrongTurnRecovery, and strongerNeighbor name a receiver only when that route is part of the branch. The optional obstacle names a recognizable obstacle only when one matters. Practical use may begin from an object to inspect, a result to evaluate, or an existing method to improve without first inventing a problem.

#Candidate-use templates and basis completeness

This section applies only when an optional exact expansion has been opened because the short public entry cannot carry a truthful promise, blocker, or named reliance on its own.

PublicCandidatePatternUseTemplate@FPFReadme <: U.Episteme:
  templateKey: PublicCandidateUseTemplateKeyValue
  recognizableConditionRef: PublicPatternUseBoundaryConditionTemplate@FPFReadme
  directPatternRef: U.EntityRef, referencing one exact FPF pattern episteme
  directSolutionSectionRef: PatternSolutionSectionRef
  expectedResultTemplateRef?: PublicPatternUseResultTemplate@FPFReadme
  resultPromiseBlockerRef?: PublicPatternUseBoundaryConditionTemplate@FPFReadme
  candidateBasisCompletenessConditionRefs[1..*]: CandidatePatternUseBasisCompletenessCondition@FPFReadme

CandidatePatternUseBasisCompletenessCondition@FPFReadme <: U.Episteme:
  candidateBasisPosition: entityOfConcernKind | practicalQuestion | optionalProblemCard | resultIdentificationQuestion | resultRelativeGovernedObjectKind | candidateSpecificBasis
  admittedBasisValueKindRef: U.Kind
  completenessConditionDescriptionRef: U.Episteme

PatternSolutionSectionRef is an edition-pinned reference to the cited pattern's Solution. A broad result family or pattern title is insufficient.

Exactly one of expectedResultTemplateRef and resultPromiseBlockerRef is present in an expanded candidate branch. A result promise is admissible only when its potential-result kind, identification question, direct pattern, identity-or-obtaining basis, relative object and category-correct basis, minimum usable result, and any actually current continuation are stateable. A blocker states the missing rule or information and carries no fulfilled result template. Optional omissions cannot masquerade as a weak passing promise.

The completeness condition inherits C.2.1 constitution. Its EntityOfConcern is the reusable candidate-basis position declared by the template; its ClaimGraph states the admitted filler kind and positive completeness condition; its ReferenceScheme explains how later current project fillers satisfy that position. It contains no project value and orders nobody to fill a form.

#Ordinary walkthrough

An ordinary walkthrough may remain readable prose. Use the following optional helper only when exact result, boundary, or continuation references are needed to keep that explanation truthful:

PublicOrdinaryWalkthrough@FPFReadme <: U.Episteme:
  guidanceRef: PracticalUseGuidance@FPFReadme
  situationDescriptionRef: U.Episteme
  firstResultTemplateRef?: PublicPatternUseResultTemplate@FPFReadme
  resultPromiseBlockerRef?: PublicPatternUseBoundaryConditionTemplate@FPFReadme
  walkthroughRowRefs[2..*]: PublicOrdinaryWalkthroughRow@FPFReadme
  fullPatternTransitionBoundaryRef: PublicPatternUseBoundaryConditionTemplate@FPFReadme

PublicOrdinaryWalkthroughRow@FPFReadme <: U.Episteme:
  actionOrProposedUseDescriptionRef: U.Episteme
  expectedResultTemplateRef?: PublicPatternUseResultTemplate@FPFReadme
  resultPromiseBlockerRef?: PublicPatternUseBoundaryConditionTemplate@FPFReadme
  directPatternRef: U.EntityRef, referencing one exact FPF pattern episteme
  directSolutionSectionRef: PatternSolutionSectionRef
  continuationConditionRef: PublicPatternUseBoundaryConditionTemplate@FPFReadme

Where an exact row is used, it carries one result template or public blocker. A walkthrough is still an explanation, not a project method, work order, or recommendation. It may contain a short repeatable formulation of the direct pattern's Solution. Call it a CGUS demonstrative slice only when [A.22.CGUS](/generated/patterns/A.22.CGUS) independently admits the represented conditional structure; an ordinary walkthrough needs no record explaining why it is not such a slice.

#Practical-use carry-through check

Read each published entry first in the form the public will see. A passing ordinary entry exposes the recognizable situation, practical question, first useful result or honest blocker, one direct pattern or small plausible set, and the stop or wrong-turn return. This check creates no project instance, applicability verdict, result entity, relation occurrence, receiving use, or separate positive record.

When an entry needs the optional exact expansion because a promise, ambiguity, or named reliance cannot otherwise remain truthful, use this conceptual view over the already published values:

PracticalUseCarryThroughCheck:
  practicalUseKey: PracticalUseKeyValue
  practicalUseGuidanceRef: PracticalUseGuidance@FPFReadme
  publicSituationDescriptionRef: U.Episteme
  publicPracticalQuestionRef: PublicPracticalUseQuestion@FPFReadme
  publicObstacleDescriptionRef?: PublicPatternUseObstacleDescription@FPFReadme
  candidateUseTemplateRefs[1..*]: PublicCandidatePatternUseTemplate@FPFReadme
  publicStopBoundaryRef: PublicPatternUseBoundaryConditionTemplate@FPFReadme
  publicReturnBoundaryRef: PublicPatternUseBoundaryConditionTemplate@FPFReadme
  publicWrongTurnRecoveryBoundaryRef: PublicPatternUseBoundaryConditionTemplate@FPFReadme
  publicStrongerNeighborBoundaryRefs[]: PublicPatternUseBoundaryConditionTemplate@FPFReadme
  publicCoarseningRows[]: PublicResultCoarseningRow@FPFReadme
  demonstrativeSliceRef?: DemonstrativeUnfoldingSlice@Context
  ordinaryWalkthroughRef?: PublicOrdinaryWalkthrough@FPFReadme
  principalBlockedOverreadRef?: PublicPatternUseBoundaryConditionTemplate@FPFReadme

The view is not a form to complete or a durable check object. Inspect only positions that the expansion actually uses. If an example is needed, use at most one ordinary walkthrough or admitted demonstrative slice for that branch. The demonstrative form must satisfy [A.22.CGUS](/generated/patterns/A.22.CGUS); the ordinary form needs no non-admission rationale. State a principal blocked overread only when the public wording otherwise invites a consequential false project claim.

For each expanded candidate-use template, exactly one result promise or exact public blocker is present. A promise identifies the direct pattern and Solution, potential-result kind, local identification question, the identity or obtaining basis and result-relative basis that actually make the promise true, the minimum usable result, and a receiver only when that continuation is current. A blocker states the missing rule or information and carries no fulfilled result template. A broad family, generic result relation, omitted value disguised as a weak promise, fabricated project occurrence, or PatternID list without selection conditions does not pass.

#Sixteen stable practical-use keys

E.11 records one F.13-form historical read path: splits(SYSTEM-IN-CONTEXT -> {SYSTEM-RECOGNITION, SYSTEM-DELIMITATION, WORDING, ARCHITECTURE}). The unchanged F.13 body does not contain this row. The old card had no single surviving public-guidance identity: system recognition, system delimitation, lexical recovery, and architecture have different referents, relations or evaluations, receiving uses, first results, and direct governors. Older writing remains readable through this one read path; current card use names only the four successor keys. A.1.STM is a conditional continuation with a dedicated readable README guide, not a fifth successor key. The split creates no U-kind, relation kind, record kind, result kind, or generic Context claim.

README owns the current public cards and their expansions. Preface explains why FPF's distinctions work together. ToC locates pattern families. Full patterns carry methods, conditions, costs, consequences, and exact result semantics. None is a second card store.

#Preface, local recognition, and first-entry terminology

The Preface explains why the README entries are credible. It uses plain engineering language before FPF vocabulary and narrates the cross-cutting ideas once rather than copying the scenario set. Its coverage includes transdisciplinary use without collapsing local meaning; local closure in an open world; holons, systems, epistemes, and architecture as structure; EntityOfConcern and description/publication/view separation; thinking-through-writing; epiplexity; first-principles-to-work; mathematical lenses and FormalSubstrate distinctions; ontology-first wording repair; evidence/assurance/gate/decision/work separation; characteristic spaces, quality, NQD/OEE, and improvement; novelty, diversity, and SoTA; and didactic primacy. A strict FPF term that carries the explanation receives an immediate plain gloss. Pattern IDs are addresses for stricter treatment, not the main explanatory language.

A pattern's own Problem frame is the local high-precision recognition section. It makes recoverable the primary EntityOfConcern, working problem, failure if missed, first admissible action, practical result, and ordinary non-use boundary. Add candidate-pattern comparison only when a real discoverability ambiguity exists; otherwise keep cross-pattern comparison in README, ToC, Relations, or an expanded case.

Keep these terms stable:

ToC and lexical-query phrases remain finding aids, not alternate names, semantic equivalences, or authority relations. A projection that needs to answer a substantive claim must return to the direct pattern or the pattern for that claim; do not strengthen the projection.

#Bounded comparison

When more than one card remains plausible, compare four things: recognizable-situation fit, difference among first results or exact public blockers, direct pattern, and stop or return condition. Keep the comparison in conversation for ordinary bounded use. Open the most promising direct pattern before constructing a project candidate.

Keep the rationale in conversation for ordinary comparison. Materialize it only when a named later use needs addressable comparison history; then it has one public-guidance subject and no fabricated project result:

PracticalUseCardComparisonRationale@Context <: U.Episteme:
  entityOfConcernRef: U.EntityRef, referencing one PracticalUseGuidance@FPFReadme
  claimGraph: U.ClaimGraph by value
  effectiveReferenceSchemeRef: U.ReferenceSchemeRef
  editionId
  recognitionReasonDescriptionRef: U.Episteme
  firstResultDifferenceDescriptionRef: U.Episteme
  comparisonRationaleDescriptionRef: U.Episteme

Stop inspection when one card has enough recognition and first-result advantage to justify direct pattern inspection, when no remaining card can change the starting choice, or when the inspection budget opens an explicit return. No fixed maximum of three is inferred.

Materialize comparison history only when a named receiving use relies on it:

PracticalUseCardShortlist@Context <: U.Episteme:
  entityOfConcernRef: U.EntityRef, referencing the exact PracticalUseQuestion@Context being compared
  claimGraph: U.ClaimGraph by value
  effectiveReferenceSchemeRef: U.ReferenceSchemeRef
  editionId
  claimScopeRef?: U.EntityRef, referencing one U.ClaimScope
  modelUseStructureRef?: U.EntityRef, referencing one BoundedModelUseStructure
  namedRelianceConditionRef: U.Episteme
  receivingUseDescriptionRef: U.Episteme
  receivingUsePatternLocator: U.EntityRef, locating one exact FPF pattern episteme only when its identity matters to the named reliance
  comparisonRefs[1..*]: PracticalUseCardComparison@Context
  selectedStartingGuidanceRef?: PracticalUseGuidance@FPFReadme
  inspectionStopBoundaryRef: PatternUseBoundaryCondition@Context
  returnBoundaryRef: PatternUseBoundaryCondition@Context

PracticalUseCardComparison@Context <: U.Episteme:
  entityOfConcernRef: U.EntityRef, referencing one PracticalUseGuidance@FPFReadme
  claimGraph: U.ClaimGraph by value
  effectiveReferenceSchemeRef: U.ReferenceSchemeRef
  editionId
  shortlistRef: PracticalUseCardShortlist@Context
  recognizableSituationFitRationaleRef: PracticalUseCardComparisonRationale@Context
  firstResultTemplateRefs[]: PublicPatternUseResultTemplate@FPFReadme
  resultPromiseBlockerRefs[]: PublicPatternUseBoundaryConditionTemplate@FPFReadme
  firstResultDifferenceRationaleRef: PracticalUseCardComparisonRationale@Context
  inspectionDisposition: keep | defer | discard | startHere

Guidance, practical question, compared result templates or blockers, first-result differences, named reliance, stop, and return remain ClaimGraph content or separately governed references; none replaces the C.2.1 identity. Each comparison cites at least one result template or exact blocker from the guidance it evaluates. claimScopeRef or modelUseStructureRef is present only when its exact direct relation changes the named reliance. Several plausible cards alone do not make this record current. The named reliance may be a later review, replay, audit, automation, or another use that needs addressable comparison history. Retain only the rows that use needs.

#Replay and currentness

Replay one public entry first from its recognizable situation, practical question, first useful result or blocker, direct pattern or plausible set, boundary, and readable walkthrough. Consult the exact helper fields only when that entry actually uses them for truth, disambiguation, or named reliance. The guidance remains current only while its situation and question still point to the same use.

Recheck the smallest affected entry slice when its recognizable situation, question, first result or blocker, direct Solution, selection condition, stop, return, or true consumer changes, or when use evidence shows a recurrent wrong turn. Recheck exact result and basis fields only when the changed entry uses them. G.11 governs edition, telemetry, currentness-window, and decay orchestration; E.11 supplies the entry-specific values and change conditions that orchestration inspects.

#Archetypal Grounding

#Architecture or description?

A team says, "Our diagram no longer explains the system." ARCHITECTURE and DESCRIPTION-USE both look plausible. The first card offers an architecture question and selected-structure result; the second offers a description-use or representation-transition result.

The team compares the first-result difference, opens C.30 and E.17.0, and discovers that the selected structure is unsettled. It starts with ARCHITECTURE. No shortlist record is needed because the comparison is local and reversible.

#A later safety review needs comparison history

The receiving safety review relies on an addressable rationale for why two teams considered TIME, COSTLY-ACTION, CAUSAL-USE, and SYSTEM-DELIMITATION before a hazardous test, because it will replay the selection after new measurements arrive. The fourth card remains plausible while exact parthood, the direct choice or architecture-decision result that makes one inclusion/exclusion claim current for the test object, or a crossing participation relation is unsettled.

In a separate systemhood fixture, “Could this stateful session or natural body be a system for this decision?” selects SYSTEM-RECOGNITION, because the exact entity and the A.1 evaluation can change what the decision may rely on. It does not select delimitation merely because an environment is mentioned.

That named reliance admits a PracticalUseCardShortlist@Context with four comparison rows, the stop boundary, and the return condition. The shortlist does not authorize the test or replace evidence, assurance, gate, choice, or WorkPlan relations.

#A card leads to a physical result without promising it

WORKING-DOCUMENTS can lead to a usable machining work instruction. Its public template first names the admitted U.MethodDescription or U.WorkPlan kind and asks how a later project use would identify the episteme under A.3.2 or A.15.2. It then asks separately which exact relation occurrence, A.6.1 binding, or category-correct local claim would make that episteme the result relative to the later document-use or machining-planning object. Any conditional pattern for the next question appears only when that continuation is part of the branch. The card does not promise a machined component.

The reader can therefore imagine useful progress without inferring that publication or planning performed the machining. When actual machining or other dated work later becomes current, use A.15.1 to identify the exact performed Work occurrence; use A.15 as well only when role–method–work alignment is itself current. The instruction or plan is neither that dated U.Work nor proof that it occurred.

#Repair the smallest card slice after a direct result changes

Suppose a new A.6.3.RT edition makes one exact RepresentationSchemeTransitionRelation@Context kind the potential first-result kind for one DESCRIPTION-USE condition. Repair that candidate-use template so it names the relation kind, its source and target participant kinds, A.6.3.RT predicate and obtaining test, occurrence-identification question, the governed-object kind relative to which a later PUA use would call it a result, its readable coarsening row, and any boundary whose condition changed. Recheck the linked walkthrough against that context-free basis template; only PUA later names a project occurrence.

The public card heading and question remain unchanged when readers still recognize the same situation. Preface and ToC remain unchanged when framework rationale and retrieval location did not move. The A.6.3.RT pattern body remains the authority for the relation; E.11 repairs only the public guidance that points to it.

#A better first-click rate can make discovery worse

Suppose retrieval ranks the most familiar title first and the first-click rate rises. Follow-up comparison shows that more readers now open DESCRIPTION-USE when the selected structure is still unsettled, so first-result mismatch and wrong-turn returns also rise.

The visible navigation measure improved while the intended value worsened: readers reached a less suitable direct pattern more often. Keep first-click rate as telemetry, apply E.13 to the substitution, and judge the guidance by recoverable situation fit, first-result fit, and wrong-turn cost rather than by the click measure alone.

#Discharge a duplicate first-entry row by function

Suppose a compact row combines “architecture and diagrams”, evidence, dashboard use, and “compare alternatives”. Do not keep it as a second entry canon. Put architecture design/review in the README ARCHITECTURE entry and C.30; put description, view, dashboard, and rendering use in DESCRIPTION-USE and the direct E.17/C.30.AD patterns; put evidence or commitment in COSTLY-ACTION and the direct A.10/B.3/A.21 patterns; put alternative comparison in OPTION-COMPARISON; put useful search phrases in ToC or retrieval; and open an I.2 case only if those compact cues still leave a genuine ambiguity. Delete the duplicate after every useful function has a matching home.

#Bias-Annotation

• Title-match bias. A familiar word selects a pattern before its Problem and first result are inspected. Compare situations and result differences, then open the direct pattern.
• Public-instance bias. A README example is filled with project values. Keep public templates context-free; project candidates belong to E.11.PUA.
• Numbered-route bias. Card order is read as method order. Use semantic keys and condition-specific continuations.
• Record-first bias. Comparison emits a shortlist by default. Materialize one only for a named receiving reliance.
• Card-as-authority bias. A public card is treated as an applicability verdict, recommendation, decision, or authorization. Use E.11.PUR or the direct pattern whose content governs that claim.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

Benefits. FPF gains a human-readable route from working questions to direct patterns without losing exact result and boundary support where it matters. Readers can stop cheaply, inspect a small plausible set, and recover from wrong turns. README, Preface, ToC, local recognition, expanded cases, and retrieval keep distinct jobs, so useful entry value does not become a duplicate canon.

Costs. Maintainers must keep each public entry aligned with the direct pattern's current result and boundary, and must repair its true consumers when those meanings change. A recurrent ambiguity or named later reliance may justify an exact expansion, worked case, or addressable comparison history; those deeper objects then need currentness care. Ordinary entries pay none of that record burden when readable prose is sufficient.

#Rationale

Discovery is a bounded decision under limited attention, not a one-time lookup. A recognizable situation and first-result difference let the reader choose what to inspect before learning the corpus topology. A recoverable return is more useful than pretending the first cue is always right.

Public guidance remains weaker than the direct pattern. It helps a reader choose what to inspect; it does not decide applicability, authorize work, identify a project result, or make a relation obtain. Precision is progressive: keep the public explanation simple while it remains truthful, and open exact result identity, basis, continuation, or reliance fields only when one of those distinctions changes the choice or claim.

#SoTA-Echoing

The practitioner implication is concrete: inspect a small plausible set, compare the first useful result or honest blocker each direct pattern can offer, and open exact identity or basis questions only when they change the choice or a named later reliance. Keep durable comparison history only when someone will use it.

Information-foraging is the lineage anchor, not by itself the current competitive claim. Familiar-title lookup and popularity ranking are the common comparator: they are cheap cues, but E.11 rejects either as the sole selection basis because neither exposes first-result differences or a recoverable return.

The two 2026 studies are current preprint anchors rather than settled consensus. Reopen the bounded-navigation adaptation when peer review, replication, or use evidence changes the observed role of inspection, memory, backtracking, or wrong-turn cost. Reopen the language-scent adaptation when broader studies show that in-situ cues obscure the governed target more often than they help readers recover it. G.11 orchestrates those currentness and telemetry checks; E.11 changes the affected card cues, comparison, or boundaries.

#Relations

• Builds on: E.8 for pattern recognition text, E.17.AUD for publication-unit discipline, F.17 and F.18 for published terms and naming, and C.2.1 for public helper epistemes.
• Leads to: E.11.PUA for applying one selected pattern and E.11.PUR for local applicability, recommendation, and coordination.
• Coordinates with: A.22.CGUS for demonstrative slices, E.18 for flow-local results, G.11 for currentness orchestration, and each direct pattern cited by a public template.

#E.11:End

Last Updated: 2026-08-04 — upstream FPF commit 67092138 (github.com/ailev/FPF)