#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 cue, 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, comparison account, 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 useful result or an honest missing-basis stop. Use E.11.PUR to judge applicability, recommendation, coordination, or ordering among candidate pattern uses, and to stop on an earlier result that still answers the concern. 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 entries 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:

The framework Readme is the single editable public entry set. If another publication form needs the same guidance, project it from that 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.

Use E.11.PFP when one public FPF, DPF, or LPF edition needs the shared reader-facing publication form: a compact product-declared opening, separate declared product title and Readme H1, Readme and Preface represented in the product's established ToC grammar before one logical pattern index, Readme entry fields, a front-only development-metadata boundary, language boundary, and deterministic source-hazard plus rendered-structure checks. E.11 still tells the reader how to state the practical question, obtain a first useful result, use the direct pattern, and stop or return. Do not copy the form grammar here or treat a form-valid carrier as a usable framework.

Use E.11.DSG when the reader may need results from several DPF product series, cannot yet tell which DPF applies, needs Suite-wide commonality or relations, or needs an honest ecosystem gap. Start with the recognizable situation and four truthful return classes. The DPF Suite Reference returns to the Suite collection and each product series, edition, result, state, or source that changes the answer; it uses an optional configuration description only when needed. When one DPF result is already known, use that DPF directly. An absent, unavailable, stale, or unneeded Reference neither erases the Suite nor blocks direct DPF use, but it cannot supply a current cross-DPF route. E.11.DSG is a non-framework publication specialization; do not apply E.11.PFP to it.

Pattern count is only a diagnostic. A one-pattern edition asks whether the result is instead a seed, candidate, or contribution to an existing framework; a larger count still does not establish a pattern language. Use E.4 and E.4.PFAD to decide framework architecture, E.4.DPF.DA or E.2.DA for the applicable package or whole-FPF adequacy, and E.21 for pattern quality.

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, how several uses relate, or whether an earlier result already answers the concern, 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, practical entries, an all-in-one carrier, a skill pack, retrieval, or a callable access service may expose the entry. That publication or access use neither decides framework architecture nor supplies authority, and the carrier is not the pattern body merely because a reader reaches it first. Use E.4 to identify the framework family and member. Only when a downstream-used framework-architecture question is live, record its selected answer in one E.9 DRR using the E.4.PFAD profile; use E.4.PFR separately when a named relation or edition maintenance use needs its representation.

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

Keep three reader-facing jobs distinct. A compact locator points to a direct pattern when retrieval is enough and carries no mandatory mantra. An ordinary practical entry makes the five values above recoverable when one direct pattern, with at most a plainly conditioned next use, can answer the difficulty, provide a first result or blocker, and say when to stop or return. A Practical-Use Card is a selected Readme example for a recurring complex difficulty whose useful answer normally spans several direct pattern contributions, checks, and returns. Its visible mantra keeps that longer dependency in attention during repeated or interrupted use. The card is a publication unit that publishes practical-use guidance: the guidance is what it tells the reader, while the card unit is the entry that carries it. Neither is the shared form, a pattern body, a Method, performed Work, a project result, authority, or a CGUS demonstration.

When a Card or mantra is useful because it keeps material dependencies among several independently reusable recurring problem–move–result contributions in attention, return to the candidate-recognition move in [E.4.DPF:4](/generated/patterns/E.4.DPF#solution) before treating the Card as only an access front. Its form is a cue for that comparison, not proof of framework scale or product membership. When no live framework question remains, continue choosing or maintaining the entry form under the tests below.

The displayed entries are examples of how the pattern language can help, not a catalogue or coverage boundary. When both uses matter to discoverability, show at least one ordinary example of cheap direct help and a few cards that demonstrate extended cross-pattern use. Say plainly that many other questions can start from the index, a guide, search, or a small plausible set of direct patterns. Do not turn every useful topic, pattern, or reader-entry set into a public example merely to prove breadth.

Before selecting a card, compare the proposed entry with the same truthful content but no mantra. If a cold reader can still recognize the situation, choose the direct pattern and any plainly conditioned next use, recover the first result or blocker, and return after interruption or repetition just as reliably, keep a locator or ordinary entry. Select a card only when, without the repeatable formula, the reader is materially more likely to lose a choice-changing question, intermediate result, check, branch, or return, and repeating the mantra restores that reasoning. Immediate recognition, repeated exposure, fluent recitation, pattern count, heading depth, an existing label, a quota, or a wish to avoid validation is not evidence. If the mantra crowds out the first result or return, or adds no recall advantage over the same content without it, use the ordinary entry or locator instead. Check declared cards and plausible non-card entries under the same test; the number of cards is an outcome, not a target.

Keep four claims separate. A product selects a card unit for a reader use. The unit publishes practical-use guidance. The product gives every selectable example one stable semantic key and assigns that key one ordinary-entry or card form in one product-wide declaration. The visible card applies the shared form from [E.11.PFP](/generated/patterns/E.11.PFP). A key, heading, form, or mantra establishes none of the other claims by itself.

A local mantra may keep one bounded result or one direct pattern contribution in attention. It belongs in the direct pattern, an ordinary entry, or other teaching material when useful; it does not by itself select a Practical-Use Card. A card mantra keeps the reasoning from the recognizable difficulty to a more distant intended result in attention across several pattern contributions. Include only the intermediate questions, results, checks, branches, and return conditions that change how the reader continues. Phrase length does not decide either use. The mantra remains Plain, repeatable action or judgement wording. It does not replace a direct pattern's Solution, create Work, or establish a CGUS structure. An optional same-key expansion explains only the branch choice or result support that the compact card cannot omit truthfully; an ordinary walkthrough remains an explanation, and a demonstrative slice still requires independent [A.22.CGUS](/generated/patterns/A.22.CGUS) admission. [E.11.PFP](/generated/patterns/E.11.PFP) defines the required visible field and heading grammar rather than this section. When an entry must show how one pattern use may lead to another, name the starting cue, direct pattern or plausible set, first result or blocker, each condition that makes another pattern use current, and the stop or return. Do not imply that those references prescribe a workflow. For recurring multi-pattern use that needs mnemonic continuity, use a Plain mantra as above. Only after [A.22.CGUS](/generated/patterns/A.22.CGUS) independently admits the represented conditional structure, name its loci and bindings or potential continuation candidates when they change which continuation is available. An entry, card, mantra, or readable continuation creates neither the selected U.Structure nor its CGUS membership.

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 yet clear. Give such readers an ordinary-language recovery entry before asking them to compare PatternIDs. These entries are independent alternatives, not stages, a required form, or another card set.

Keep four moments distinct. Recognize why the ordinary situation matches this entry. Select the direct pattern whose Solution tells the practitioner how to obtain the expected first object. Use only the branch needed now. Return the smallest usable result or a named blocker. A direct result exists, or a relation obtains, only when the applicable pattern's conditions are satisfied; the entry cue creates neither.

Apply the same compact entry shape each time: recognizable situation; practical distinction; expected first object; direct pattern; smallest usable result or honest blocker; ordinary stop; and one neighboring exit. Stop before signatures, card schemas, full Methods, pattern 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 subject before using the management label. An actual project is qualifying composite U.Work; a process concern may be a reusable U.Method, a structure selected under A.22, or a TransformationFlowStructure; a case follows one affected referent or claim through the change history needed for closure and keeps the relevant downstream use outside that closure. The smallest result names that subject, the pattern used to identify or constrain it, and the claim the current decision may make—or the missing identity, relation, closure basis, or information. Treat target system as a cue for the project system-of-interest question, not as proof of identity. Keep plans, decisions, work-to-system relations, system-role classifications, assignments, participation, responsibility, and authority separate. If role still hides the claim, use E.10.ROLE. Stop when the recovered subject and claim answer the decision; use A.1.SCR only if systemhood still changes the answer.
• 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 FPF pattern episteme whose content is needed; classify it as a U.MethodDescription only when the A.3.2 criterion passes and the current use depends on that classification.

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 defining or constraining ClaimGraph in the pattern episteme used for 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 continuation 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.

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

For a selected card, also compare the same truthful entry without its mantra. The card passes only when repeating the mantra materially improves repeated or extended use under the test in E.11:4.1. After one read, a cold engineer or manager can repeat the formula in their own words, name the first useful result or honest blocker, follow Start with to the direct pattern and any conditioned next use, and use the same key to recover any optional expansion. The direct pattern remains authoritative. A short slogan that loses a choice-changing distinction fails, and a form-valid card that provides no mnemonic gain returns to ordinary-entry or locator form.

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.

#Stable practical-use keys and selected forms

Give every selectable public entry one stable semantic key so the reader can return to the same situation after wording, grouping, or presentation changes. The product maintains one declaration that assigns each key exactly one ordinary-entry or card form. An optional expansion repeats its enclosing card key only to remain findable; it is not another selectable occurrence. This rule creates no universal entry kind or second key registry.

E.4.FPF carries the current FPF example-key and form declaration plus its language-appropriate reading-burden measure and two maxima. A DPF or LPF carries its own product declaration under E.4.DPF. E.11 therefore does not maintain another FPF key list or treat displayed examples as product coverage.

E.11 records one F.13-form historical read path: splits(SYSTEM-IN-CONTEXT -> {SYSTEM-RECOGNITION, SYSTEM-DELIMITATION, WORDING, ARCHITECTURE}). 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 entry use names only the four resulting keys. A.1.STM is a conditional continuation with a dedicated readable README guide, not a fifth resulting key. The split creates no U-kind, relation kind, record kind, result kind, or generic Context claim.

The FPF Readme carries a selected, explicitly non-exhaustive set of current public examples and their optional expansions. Preface explains why FPF's distinctions work together. ToC locates pattern families and questions outside the examples. Full patterns carry Methods, conditions, costs, consequences, and result semantics. None is a second entry store or a claim that the examples bound FPF use.

#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 selectable entry 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:

PracticalUseEntryComparisonRationale@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 entry has enough recognition and first-result advantage to justify direct pattern inspection, when no remaining entry 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:

PracticalUseEntryComparisonAccount@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..*]: PracticalUseEntryComparison@Context
  selectedStartingGuidanceRef?: PracticalUseGuidance@FPFReadme
  inspectionStopBoundaryRef: PatternUseBoundaryCondition@Context
  returnBoundaryRef: PatternUseBoundaryCondition@Context

PracticalUseEntryComparison@Context <: U.Episteme:
  entityOfConcernRef: U.EntityRef, referencing one PracticalUseGuidance@FPFReadme
  claimGraph: U.ClaimGraph by value
  effectiveReferenceSchemeRef: U.ReferenceSchemeRef
  editionId
  comparisonAccountRef: PracticalUseEntryComparisonAccount@Context
  recognizableSituationFitRationaleRef: PracticalUseEntryComparisonRationale@Context
  firstResultTemplateRefs[]: PublicPatternUseResultTemplate@FPFReadme
  resultPromiseBlockerRefs[]: PublicPatternUseBoundaryConditionTemplate@FPFReadme
  firstResultDifferenceRationaleRef: PracticalUseEntryComparisonRationale@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 separate references under their direct patterns; 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 the named scope or model-use structure changes the reliance being recorded. Several plausible entries 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. Use G.11 for edition, telemetry, currentness-window, and decay orchestration; E.11 supplies the entry-specific values and change conditions that orchestration inspects.

#Archetypal Grounding

#Architecture or working document?

A team says, "Our diagram no longer explains the system." ARCHITECTURE and WORKING-DOCUMENTS both look plausible. The first card can return an architecture question, candidate set, or selected-structure result. The second can return the smallest description-use, representation, publication, or other working-document result for a named reader use.

The team compares those first results and sees that the selected structure itself is unsettled. It starts with ARCHITECTURE. No comparison account 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 a team compared the ordinary MATHEMATICAL-MODELING entry, OPTION-COMPARISON, and SYSTEM-DELIMITATION with the ordinary SYSTEM-RECOGNITION entry before a hazardous test. New measurements will later reopen the choice. The four examples ask different first questions: what a model can support, which comparison or readiness result is needed, which parts or crossings matter, and whether the exact entity must be treated as a System at all.

That named reliance admits a PracticalUseEntryComparisonAccount@Context with four comparison rows, the stop boundary, and the return condition. The account 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 guidance first asks what a named reader must decide, do, check, or rely on and returns the smallest truthful document-side result or blocker. Use the direct pattern to determine whether the useful result is a MethodDescription, WorkPlan, claim, permission, publication, or another document-side result and what relation makes it useful for the later project work.

The card does not promise a machined component. When actual machining later becomes current, use A.15.1 to identify the exact performed Work occurrence; use A.15 as well only when the broader System-Role–Method–Work Alignment question is 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 restores a progressive representation result: an ordinary target representation plus source-comparison note first, exact endpoints only when a named receiver makes their identity material, and a historical transition occurrence only when actual transition Work and all required participants are current. Repair only the affected WORKING-DOCUMENTS branch so its first result and escalation triggers match the direct pattern. The card heading and general question remain unchanged when readers still recognize the same situation.

After the repair, compare the same truthful entry with and without its mantra after a delay or interruption. Keep the card only if the mantra materially helps a cold reader reconstruct the choice-changing cross-pattern path and its first result or return. If the two forms perform alike, use an ordinary entry or locator; if the mantra hides the result or return, repair or drop it.

#A better first-click rate can make discovery worse

Suppose retrieval ranks WORKING-DOCUMENTS first whenever a diagram is mentioned and the first-click rate rises. Follow-up comparison shows that more readers now open document-use patterns while the architecture subject or 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. 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 alternative comparison. Do not keep it as another public example merely to display topic coverage. Put architecture design or review in ARCHITECTURE; put description, view, dashboard, and rendering use in WORKING-DOCUMENTS and the direct E.17/C.30.AD patterns; put costly evidence or commitment questions in OPTION-COMPARISON and their direct A.10/B.3/A.21 patterns; put useful search phrases in the ToC or retrieval. Open an I.2 case only if those 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-entry bias. Entry order is read as Method order. Use semantic keys and condition-specific continuations.
• Record-first bias. Comparison emits a comparison account 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 defines, constrains, or tests that claim.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

Benefits. FPF gains a human-readable entry from working questions to direct patterns without losing the result and boundary support that matters. A few ordinary examples show that one pattern may answer a bounded difficulty; selected cards show that the language can sustain longer reasoning across pattern contributions. Readers can stop cheaply, inspect a small plausible set, and recover from wrong turns, while explicit non-exhaustive wording keeps the examples from becoming a coverage catalogue. 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 choices below apply E.8:11 to first entry, recovery from a wrong turn, and recall. The selected answer is bounded guidance that a reader can test against a cheaper entry; it is not a claim that a recent paper validates FPF.

Navigation question. How can a reader choose a useful first pattern without inspecting the whole corpus, and recover when the first cue was misleading? The best-known line for this use is sequential, bounded inspection with an explicit return: compare the result or blocker offered by a few plausible entries, open one direct pattern, and stop or backtrack when its boundary rules it out.

The serious alternative is familiar-title or ranked-result lookup with a short topical snippet. It is cheap and remains sufficient when the direct pattern is already known. For an ambiguous question, however, the same small reading budget can be spent on a situation, first-result difference, and return instead of another topical label. This deliberately trades some snippet brevity for a recoverable wrong-turn decision; it does not promise fewer clicks or faster task completion. Adapt: E.11:4.1, 4.1.2, 4.4, 4.6, and 4.7 keep that bounded inspection and cheap exit; case 5.5 rejects a better first-click metric when the reader reaches the wrong use.

Jin, Bai, and Oulasvirta, Modeling Trial-and-Error Navigation With a Sequential Decision Model of Information Scent, arXiv:2603.11759v1, supplies a best-known-line candidate and counterexample to treating navigation as fully informed, one-shot selection. Its model reproduces partial inspection, premature choices, and backtracking; it does not test FPF entries or require the reader to run a navigation model. The first-result comparison and reliance-conditioned history are FPF adaptations. Reopen this choice if a same-budget title/snippet or other entry preserves result discrimination and wrong-turn recovery with less burden, or if reader evidence shows that the added return cues distract from the first useful choice.

Mnemonic question. When is a repeatable formula worth the extra space in a cross-pattern entry? The selected line is conditional mnemonic support tested against the same truthful content without the mantra, not an acronym or repetition by default.

Cue question. When a reader's familiar wording or language hides another useful target, should the entry merely translate the same label, show more results, or explain the choice nearby? The selected line is the smallest situation-and-result cue that lets this reader distinguish the targets, with an expansion only for a distinction that cannot fit truthfully. The serious alternative is a concise translated title or ordinary search snippet. Keep that alternative when it already distinguishes the use; otherwise prefer a short explanation of what the reader can obtain over extra synonyms. This trades a little reading space for a visible choice, without requiring full translation, a multilingual interface, or another public scenario.

Zhu, Reinecke, and Mitra, Language Scent: Exploring Cross-Language Information Navigation, arXiv:2604.03604v2, supplies bounded evidence for considering such proximal cues: its multilingual system exposes information value and interpretation cues, and its lab study involved 16 English–Chinese speakers. It does not compare FPF names or establish that two labels have the same referent. Adapt as a local probe: E.11:4.1.1, 4.1.2, and 4.5.1 test recognizable wording against the direct result; E11-9/10/11 keep cue, entry, and direct content distinct. Reopen if a shorter label works equally well for the actual readers, if the cue invites the wrong result, or if stronger evidence changes the transfer from multilingual navigation. No universal benefit from contextual wording is inferred.

For a cross-DPF entry, E.11.DSG supplies the direct four-return, exact-source, and known-DPF-bypass rules used in E.11:4 and E11-13. These are semantic inputs to the entry, not another competing navigation theory: Suite membership follows E.4's inclusion rules, a reader or assisting System performs lookup Work, and cross-DPF entry requires no Suite edition. E.8, E.17, F.17, F.18, and E.11.PUA retain their direct authoring, publication, naming, and pattern-use functions. Reopen the affected entry when those direct results or boundaries change; use G.11 only when a currentness or telemetry question is actually current.

#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: E.11.PFP for the shared ordinary-entry and card forms; E.4.FPF and E.4.DPF for each product's selected non-exhaustive example keys and forms plus its reading-burden measure and two limits, with E.4.DPF:4 governing the return from a contribution-spanning Card or mantra to candidate recognition; A.22.CGUS for independently admitted demonstrative slices; E.18 for flow-local results; G.11 for currentness orchestration; E.11.DSG for cross-DPF entry, direct-known-DPF bypass, and return to the Suite collection and the product series, editions, results, states, or sources that change the answer; and each direct pattern cited by a public entry.

#E.11:End

Last Updated: 2026-09-10 — upstream FPF commit a87d0ef4 (github.com/ailev/FPF)