#First-Practical Entry and Pattern-Use Discoverability Discipline

E.11 · Stable · Architectural pattern · Normative unless marked informative · Part E - The FPF Constitution and Authoring Guides

#About this pattern

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

#How to use this pattern

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

Type: Architectural pattern Status: Stable Normativity: Normative unless marked informative

One cold reader often enters FPF with one burden phrase rather than one pattern ID. The reader may see several plausible patterns, one search result, one Preface blurb, one J.4 row, or one local pattern opening, but still not know which authoritative pattern to inspect first, which nearby pattern is only support or a tempting wrong first stop, and where it is lawful to stop reading for entry purposes.

#Relations

#Content

#Problem frame

One cold reader often enters FPF with one burden phrase rather than one pattern ID. The reader may see several plausible patterns, one search result, one Preface blurb, one J.4 row, or one local pattern opening, but still not know which authoritative pattern to inspect first, which nearby pattern is only support or a tempting wrong first stop, and where it is lawful to stop reading for entry purposes.

Pattern-entry discoverability is the discipline that makes that first recognition honest without turning the pattern language into workflow.

Use this pattern when the reader can name the burden in ordinary work language but still cannot tell which pattern to inspect first, which nearby pattern is only support, and where the first lawful entry stop belongs.

What goes wrong if this pattern is missed:

• Preface, README, J.4, one search result, or one local top is treated as if it were the authoritative pattern rather than one projection or support role;
• one plausible nearby pattern becomes a hidden required next step because entry language turns into workflow language;
• lexical support turns into synonym stuffing instead of governed query cues;
• readers repeat the same wrong first guesses because the corpus never publishes one explicit entry-neighborhood discipline.

What this pattern buys:

• the first honest burden becomes nameable near the point of use;
• candidate patterns, tempting wrong patterns, and lawful entry stops become visible without minting a workflow;
• support/projection roles can help the reader recover the right pattern without competing for semantic authority.

Ordinary not-this-pattern boundary:

• not when the real burden is first-contact recognition of one single encountered description; use A.6.RSIG;
• not when the real burden is already one published route, language-state cue, endpoint publication line, or work sequence;
• not when the authoritative pattern is already known and the remaining job is only didactic order or lexical repair;
• not when a formal quality claim about discoverability is being made; route that burden through C.25 / A.6.Q as applicable.

#Problem

Pattern-entry discoverability burdens are spread across Preface, J.4, I.2, local pattern Problem frames, table-of-content query rows, and lexical-support patterns. Without one governing pattern for their split, readers can infer false sequence, wrong pattern, wrong strongest home, or shadow projection authority because the support roles are under-governed.

#Forces

#Solution

#Governed object, non-goals, and non-minting boundary

E.11 governs pattern-entry discoverability for FPF and FPF-conformant pattern-language authoring: the coordination law by which one reader can bring plausible authoritative patterns into view, compare them, reject tempting wrong patterns and wrong strongest homes, use lawful projection/support roles, and reach one lawful entry stop or burden reclassification without reading the pattern language as workflow.

In E.11, the live governed case is pattern-entry discoverability. Description discoverability remains routed through A.6.RSIG; E.11 mentions it only to preserve the semantic-name settlement and support-role partition.

E.11 does not govern:

• discoverability trigger-word repair or naming assets that belong to A.6.P / F.18 / E.10;
• description-recognition signatures in general, which belong to A.6.RSIG;
• local first-reading placement and form, which belong to E.8;
• didactic order, learning order, cognitive-load ramping, tutorial sequence, progressive mastery, and teaching examples after the relevant pattern family has already been identified;
• workflows, process routes, control-flow graphs, prescribed method sequences, work handoffs, or runtime execution stops;
• the semantic content of referenced patterns;
• formal quality treatment, which belongs to C.25 / A.6.Q when the claim becomes evaluative;
• graph ontology in E.18.

This pattern does not mint one new U.Discoverability, RelationKind, PatternKind, StatusKind, SurfaceKind, graph node, or workflow state.

#Pattern-entry discoverability claim and FPF strata

Pattern-entry discoverability is one composite quality-facing concern over whether one reader can:

• bring the right candidate patterns into view, together with any lawful support roles needed for comparison;
• recognize applicability or non-applicability;
• avoid common wrong patterns, wrong strongest homes, or projection-only fragments answered as if they were authoritative;
• reach one lawful entry stop or burden reclassification.

This pattern keeps these semantic heads distinct:

None of those heads is a synonym for the others. This pattern routes each effect to its strongest home or strongest projection role rather than letting discoverability become one semantic swamp.

Reader-facing entry language speaks primarily in pattern-language terms: candidate pattern, nearby pattern, tempting wrong pattern, burden reclassification, lawful entry stop, thin echo, and strongest home.

owner and ownership are not default reader-facing terms here. Use them only in process-law owner-set contexts or explicit authority-conflict diagnostics.

#Pattern-language navigation stance and case-orientation snapshot

An entry neighborhood is one case-relative editorial grouping of plausible candidate patterns, nearby patterns, common misclassifications, burden reclassifications, and lawful entry stops under one first honest burden.

candidate patterns here are case-plausible patterns to inspect under one named burden. They are not OptionSets, candidate pools, selected sets, or selector outputs unless another authoritative pattern explicitly promotes that structure.

nearby pattern means case-near for recognition, disambiguation, or burden reclassification. It does not mean next, required, dependent, broader, narrower, or pedagogically prior.

Authors can use one lower-case case-orientation snapshot as an editorial lens over the current cues, current burden hypothesis, plausible candidate patterns, tempting wrong pattern, disambiguating fact, lawful entry stop, and current reading role. It is not one canonical persisted object and does not create a transition history.

Minimal example:

case_signal = "we need a shortlist, not one winner"
current_burden_hypothesis = selected-set publication or candidate-pool policy
plausible_candidate_patterns = C.19; G.5 only when selected-set publication is live
nearby_patterns_or_reclassifications = C.11, C.24, A.19 comparator/selector supports
tempting_wrong_pattern = C.11
disambiguating_fact = output remains a governed set, not one local choice
lawful_entry_stop = inspect C.19 if pool policy is live; inspect G.5 if publication is live; inspect C.11/C.24 only after the burden narrows

#Entry-orientation labels and burden reclassification discipline

The local FPF application of this pattern is the coordination law for first-practical entry orientation over the FPF pattern language: support-role partition, entry-bearing vs nearby-pattern discipline, burden-reclassification presentation, thin-echo discipline, entry-lexeme-support hooks, and review hooks.

Route-shaped wording can blur entry orientation with lawful publication seams, early language-state routing, endpoint publication, A.6.B routed claim structure, DRR claim routing, or actual method/work sequencing. Repair that blur by typing the live burden explicitly rather than by treating every route-shaped phrase as entry guidance.

Use this placement test whenever one pattern-entry discoverability-bearing claim or wording repair is being placed:

E.11 uses only lower-case editorial labels when reviewers need a compact diagnostic vocabulary:

• entry-orientation labels: candidate-pattern, nearby-pattern, burden-reclassification, common-misclassification;
• projection-support labels: lexical-support, worked-reading-expansion;
• entry-posture labels: entry-bearing, participant-only, burden-critical;
• projection-purpose labels: global-entry orientation role, catalogue-search support role, entry-neighborhood index role, worked-entry-reading support role, Problem-frame recognition surface, entry-lexeme support role, review-profile role, assurance surface.

These labels are optional reviewer/editor vocabulary. They are not exported kind families and are not required authoring dimensions for ordinary pattern repairs.

#Support-role partition, Problem-frame first-reading discipline, and README boundary

The concrete FPF application uses distinct support/projection roles:

• Preface gives coarse global orientation;
• Table of Content Keywords & Search Queries gives sparse catalogue-search and lexical-query support;
• J.4 gives compact entry-neighborhood comparison;
• I.2 gives worked entry readings for high-risk or compact-insufficient cases;
• the pattern's own Problem frame gives the primary local first-reading role;
• F.17 / F.18 / E.10 carry entry-lexeme support;
• README can echo the Core entry architecture and point to Preface, J.4, I.2, and selected pattern families.

README remains downstream of Core and does not introduce entry neighborhoods, candidate patterns, or lexical names absent from Core. It changes when public entry claims change materially, not for every internal local wording repair.

Canonical entry neighborhoods can use compact lexical-query support when the lexical burden is real. Query cues are retrieval aids, not aliases, Bridges, equivalence claims, or semantic twins. A query cue becomes an alias only through the relevant lexical/naming home.

Minimal visible lexical-query shape:

canonical_label
plain_twin_if_governed
visible_query_cues
domain_query_examples
deprecated_cues
false_friends_or_forbidden_synonyms

Ordinary lexical-query support stays sparse:

• ordinary Table of Content rows: prefer 2-5 high-signal query phrases;
• ordinary J.4 neighborhoods: keep only the strongest domain phrases and false friends;
• fuller lexical sets belong under F.17 / F.18 / E.10 only when one real naming, alias, bridge, or collision burden exists.

#Fanout, thin-echo discipline, and semantic parity

Each entry/discoverability claim names one strongest home or strongest projection role. Other mentions remain thin echoes.

Support-role parity means semantic consistency of first-use burden, strongest home or strongest projection role, wrong-pattern boundary, projection-only status, and no claim stronger than the Core pattern body. It does not require identical wording, identical examples, identical rows, or exhaustive coverage across all support/projection roles.

#Change propagation, compact host-note discipline, and PCP-ENTRY hook

Authors do not introduce Entry-orientation account as a standalone artifact family.

For material entry/discoverability changes, the author leaves one compact host note inside the DRR, PCP record, patch note, or equivalent host record. Ordinary wording repairs do not require a separate note when candidate-pattern force, first honest burden, strongest home or strongest projection role, and support role remain unchanged.

Allowed host-note shape:

Entry-change note:
changed projection or support role:
changed first-use burden:
strongest home / projection role:
wrong-pattern or parity risk:
selected check, if any:

If the note takes more than a few lines for an ordinary material entry change, the change is probably too large for a local note or should escalate to a real DRR / PCP record.

PCP-ENTRY is the narrow additive review profile for material pattern-entry-discoverability changes. It is risk-triggered rather than universal and reviews only entry-facing effects.

A pattern does not need a J.4 row merely because it exists. A J.4 row is needed only when the pattern or neighborhood is a likely first practical entry, a common wrong first guess, or a public/retrieval-facing entry point.

I.2 worked readings are rare-depth. A compact-index-only posture is a complete lawful entry result when the J.4 row plus pattern Problem frame are enough for the burden.

#Minimum viable entry discipline

For an ordinary entry-bearing pattern change, the minimum is:

1. the Problem frame names the working situation;
2. it names or implies the first candidate pattern/home;
3. it rejects one tempting wrong reading if that risk is live;
4. it does not imply workflow, handoff, or route order;
5. any support role remains a thin echo.

Everything else is triggered:

• J.4 row: only if it is a likely first entry or common wrong first guess;
• I.2 worked reading: only if compact guidance repeatedly fails or risk is high;
• ToC lexical cues: only if search/query support is material;
• README/Preface echo: only if public entry changes materially;
• host note: only for material entry-force changes;
• evidence mode: only for high-risk, disputed, retrieval-facing, repeated-failure, or measured-improvement claims.

#Archetypal grounding

#System-side worked entry repair: shortlist burden, not one-off choice

Live reader phrase:

"We need a shortlist, not one winner."

Why the phrase is easy to mishandle:

• C.11 looks tempting because a local decision may eventually happen;
• G.5 looks tempting because publication may happen later;
• C.24 can be nearby when the missing object is a tool-call plan;
• one reader can mistake the live burden for a required next step in a hidden selection workflow.

Entry repair:

1. first honest burden = selected-set shaping, candidate-pool policy, or selected-set publication, not automatically one-off local choice;
2. plausible candidate patterns = A.19.CN, A.17-A.19, C.18, C.19, G.0, and G.5 when selected-set publication is already live;
3. nearby / burden-reclassification patterns = C.11 only after the burden narrows to one local decision doctrine, C.24 only when the next honest artifact is a call plan or checkpoint return, and A.19.CPM / A.19.SelectorMechanism when comparator/selector structure is live;
4. disambiguating fact = the desired output remains a governed set or shortlist rather than one local winner;
5. lawful entry stop = inspect C.19 if pool/candidate policy is live; inspect G.5 if selected-set publication is already live; inspect C.11 or C.24 only after that narrower burden is actually live.

#Episteme-side anti-case: partly-said cue is not yet a claim

Live reader phrase:

"This phrase matters, but it is not yet a claim."

Plausible but wrong first reading:

• the reader jumps straight to A.6.P, A.6.Q, A.6.A, or C.25 because the phrase sounds conceptually important.

Entry repair:

1. first honest burden = cue preservation and burden typing, not endpoint claim publication;
2. plausible candidate patterns = C.2.LS, A.16, A.16.1, B.4.1, B.5.2.0;
3. tempting wrong pattern = any endpoint claim, action, or quality pattern that assumes the cue is already stable enough to publish as a claim;
4. lawful entry stop = cue preserved, entry plurality opened, or burden reclassified honestly; if the phrase is already a boundary claim, inspect A.6.B / A.6.C instead.

#Episteme-side worked entry repair: same-entity rewrite

Live reader phrase:

"We need to explain the same thing for another audience."

Entry repair:

1. first honest burden = same-entity retextualization, representation-scheme transition, explanation-facing rendering, or bounded comparative reading;
2. plausible candidate patterns = A.6.3.CR, A.6.3.RT, E.17.EFP, E.17.ID.CR;
3. tempting wrong pattern = minting one second semantic object or parallel rule lane;
4. disambiguating fact = the governed object stays the same; only rendering, reading posture, or explanatory framing changes;
5. lawful entry stop = same-entity rewrite opened or explanation-facing rendering stabilized with source pins.

#Quick compact-index-only examples

• Project alignment. If the first burden is responsibility/method/plan vs run confusion, A.15 and neighboring work/role patterns are likely first homes; F.17 is a typical vocabulary stabilizer when vocabulary is unstable. This can stay compact-index-only unless repeated readers confuse it with the whole FPF method.
• Generator / SoTA / portfolio kit. If the first deliverable is a reusable search/harvest/portfolio scaffold, inspect A.0, G.0, G.1, G.2, and G.5. This can stay compact-index-only unless portfolio/generator entry is repeatedly misclassified as one-off recommendation.

#Bias-Annotation

This pattern counters:

• workflow bias;
• programmer's-bias graph language;
• front-door centralization bias;
• synonym-soup bias;
• support-projection authority bias;
• owner-bias in reader-facing entry language.

#Conformance checklist

• CC-E11-0 Affordability. Entry guidance is non-conforming when it becomes more expensive to author, review, or read than the discoverability risk warrants.
• CC-E11-1 No workflow. Entry prose does not imply mandatory sequence, handoff, route execution, baton transfer, control state, or artifact pipeline.
• CC-E11-2 Pattern authority. Entry support roles do not redefine the semantic content of the authoritative pattern.
• CC-E11-3 Strongest home / thin echo. Each entry/discoverability claim has one strongest home or strongest projection role; other mentions remain thin echoes.
• CC-E11-4 Pattern-language vocabulary. Reader-facing entry prose uses candidate patterns, nearby patterns, tempting wrong patterns, burden reclassification, and lawful entry stop rather than next-step vocabulary.
• CC-E11-4a Editorial labels only. Entry labels in E.11 are editorial projection labels over existing patterns, sections, rows, or publication faces. They do not create PatternKind, RelationKind, StatusKind, SurfaceKind, Role, U.Type, graph node, or workflow state.
• CC-E11-5 Problem-frame first-reading role. Local first-use recognition remains in the pattern's Problem frame; J.4, I.2, lexical support, and README do not become competing local recognition homes.
• CC-E11-6 Quality boundary. Formal quality claims about discoverability or recognition route through C.25 / A.6.Q as applicable; E.11 coordinates pattern-entry use, not quality authority.
• CC-E11-7 Semantic parity. Multi-role changes keep burden, authority, boundary, and projection-only status compatible without requiring identical wording or exhaustive coverage.
• CC-E11-8 Worked reading threshold. High-risk, often-misclassified, repeatedly failed, retrieval-facing, or materially new entry neighborhoods have either one worked entry reading or one explicit compact-index-only posture.
• CC-E11-9 Lexical-query support. Material lexical divergence is handled through governed lexical-query support, not synonym stuffing or alias equivalence.
• CC-E11-10 Retrieval-facing claim. Retrieval fixtures are used only when retrieval behavior is explicitly claimed, observed to fail, or machine-facing projection support is in scope.

#Common Anti-Patterns and How to Avoid Them

• Problem-frame absence. The pattern body is lawful, but the first-use situation is still unclear. Repair by rewriting the Problem frame for the first-reading role.
• Top overgrowth. The opening carries architecture placement, token guards, route fields, or law before the working situation is clear. Repair by moving heavy material to Solution, Relations, Conformance, or I.2.
• Route smuggling. Local text says Start here, next owner, handoff, or reroute as if it were a sequence. Repair by replacing it with candidate patterns, nearby patterns, burden reclassification, and lawful entry stop.
• Shadow projection. J.4, README, or another projection defines pattern semantics. Repair by moving that definition back to the authoritative pattern and leaving only one thin echo.
• Lexical stuffing. Pattern bodies fill themselves with synonyms for findability. Repair by routing lexical support through F.17 / F.18 / E.10.
• Entry-block-as-ontology. A temporary map of neighborhoods is frozen as if it were one stable ontology. Repair by keeping neighborhoods case-relative and projection-scoped.

#Consequences

This pattern gives FPF one explicit coordination law for pattern-entry discoverability instead of leaving the burden fragmented across Preface, J.4, I.2, pattern tops, query rows, and lexical support lanes.

It also imposes discipline: entry support becomes thinner, more explicit about its authoritative patterns and support roles, and less tolerant of workflow-shaped wording. The cost stays bounded because worked readings, host notes, parity scans, retrieval fixtures, and evidence modes are triggered by risk rather than required for ordinary wording repairs.

#Rationale

This pattern is needed because the burden is no longer only local pattern form and not only lexical repair. E.8 governs local first-reading form; A.6.RSIG governs the neutral description-recognition-signature substrate; E.19 reviews risk-triggered entry changes. The cross-pattern entry law still needs its own governing pattern.

#SoTA-Echoing

This pattern is an FPF-local pattern-entry discipline. It adopts current discoverability, documentation-mode, taxonomy, pattern-validation, human/AI-facing, and retrieval practices only where they preserve one burden-oriented entry reading over a pattern language. It rejects turning that reading into one workflow, front door, route graph, synonym store, or retrieval-tooling ontology.

#Relations

• Builds on: A.6.RSIG, E.8
• Coordinates with: E.19 / PCP-ENTRY, J.4, I.2, F.17, F.18, E.10, E.6, E.7, E.12, F.16, C.25, A.6.Q
• Constrains: reader-facing entry support roles for FPF and FPF-conformant pattern languages

#E.11:End