#First-Practical Entry and Pattern-Use Discoverability Discipline

E.11 · Stable · Pattern-language governance pattern (E) · Normative for FPF entry, projection, and discoverability publication units. · 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 entry, projection, and discoverability publication units.

At a glance. E.11 governs how FPF helps a working practitioner find the first useful pattern family without turning entry material into a shadow table of contents, universal method sequence, conformance authority, or second pattern body. The public first-entry publication unit is the FPF readme section: it starts from ordinary project needs and first useful results. The Preface explains the cross-cutting ideas behind those entries in plain engineering language before it relies on FPF terms. Local pattern Problem frame sections carry the high-precision recognition role. Separate duplicate first-entry indexes are not maintained when they repeat the readme scenario set.

Use this when. Use this pattern when a first-entry publication unit, table-of-content cue, readme section, Preface text, retrieval card, lexical query row, or pattern-local recognition text could change which FPF pattern family a user should inspect and apply first.

First output. A discoverability arrangement that names the public first-entry scenario, the first admissible governing pattern or small candidate pattern set, the local wrong-pattern boundary, and the publication unit that carries each piece.

Primary EntityOfConcern. One entry or discoverability publication unit in FPF: readme first-entry scenario text, Preface principle explanation, ToC query row, expanded entry-disambiguation case, retrieval cue, or pattern-local Problem-frame recognition text.

What this buys. A practitioner can start from a real project question instead of from FPF's internal topology, while FPF keeps pattern authority in the governing pattern body and avoids a duplicate navigation canon.

FPF has many patterns. New users do not usually arrive saying "I need A.15" or "I need C.30.AD." They arrive with project questions:

#Relations

#Content

#Problem Frame

FPF has many patterns. New users do not usually arrive saying "I need A.15" or "I need C.30.AD." They arrive with project questions:

• "I need to design or review architecture."
• "I need to write a regulation, method, boundary, contract, API, or work-process document."
• "I need to compare options without jumping to one favorite."
• "I need to turn a vague situation into a problem."
• "I need to say what better means before improving."
• "I need to know what evidence or assurance is missing."
• "I need to keep a temporal, freshness, rate, or action-window claim honest."
• "I need to use causal claims, model outputs, interventions, or responsibility claims safely."
• "I need to publish, compare, or rely on descriptions, views, dashboards, or explanations of the same entity."
• "I need better names for project entities."
• "I need to repair a technical text."
• "I need to know whether mathematics would help."
• "I need the field of current options or state of the art."

Those project questions need public first-entry scenarios. They should not be forced through a compact internal index before the user has recognized what FPF can do.

At the same time, first-entry text is dangerous when it becomes too powerful. A readme blurb, table row, search cue, or example can start acting as if it defines the pattern, prescribes a universal method sequence, or grants authority that belongs only in the governing pattern.

#Problem

Entry material fails in three recurring ways.

First, it becomes too internal. It starts with FPF diagnoses such as "roles and methods are mixed" even though a working practitioner only knows that they need an architecture review, a regulation, a decision, or a better name.

Second, it becomes a duplicate corpus. A separate first-entry index repeats readme scenarios, then each pattern repeats the same related-pattern fanout list, and soon FPF carries several slightly different entry arrangements.

Third, it becomes too authoritative. A projection row, heading, card, or readme paragraph starts answering as if it were the pattern body. That is projection drift: a finding aid becomes a shadow source.

#Forces

#Practice Grounding

#Solution - Assign Each Entry Publication Unit One Job

Use this distribution.

A separate first-entry index is not maintained when it repeats the readme scenario set. If one first-entry row has value not carried by the FPF readme section, ToC, a pattern Problem frame, or an expanded case, place that value in the appropriate publication unit instead of maintaining a duplicate index body.

#readme First-Entry Scenario Rule

The public first-entry scenario set starts from working project questions and stabilizing results.

A conforming first-entry scenario has this shape:

FirstEntryScenario:
  projectQuestion:
  practicalUse:
  typicalFirstResult:
  firstPatternFamily:
  blockedOverreadOrBoundary:

The public scenario text may be prose rather than a visible form. It should still make those fields recoverable.

Good scenario heads name recognizable project work:

• develop or review architecture;
• write rules, methods, and work-process documents;
• compare alternatives and make a local choice;
• turn a vague situation into a usable problem statement;
• define what "better" means and run improvement;
• prepare evidence, assurance, or gate decisions before commitment;
• check timing, freshness, rhythm, and action windows;
• use causal explanations, interventions, responsibility, and model outputs safely;
• compare descriptions, dashboards, explanations, and views of the same thing;
• give things better names;
• repair wording in technical documents before it changes action;
• decide whether mathematics or formal modeling would help;
• build a state-of-the-art or option portfolio.

Wording repair may be one scenario. It must not dominate the public first-entry set. FPF should not look like a commission for checking admissible technical speech when it is also a framework for architecture, problem shaping, work-method publication, comparison, evidence, mathematics, quality, and improvement.

#First-Time Engineer Readability Rule

Public first-entry text is tested against a first-time engineer, engineer-manager, or assisting agent who has not studied FPF.

The title and first sentence must name a recognizable working problem before FPF taxonomy, pattern ids, internal kind names, quality or projection vocabulary, or conformance vocabulary appears. The first practical result must be something the reader could imagine producing or asking for in the project: an architecture question note, regulation outline, comparison note, problem card, quality-and-improvement note, evidence-readiness note, timing note, causal-use note, description-use note, naming card, repaired paragraph, modeling note, or option portfolio.

FPF precision remains required. It is introduced after the plain recognition hook and stays recoverable through the pattern ids and later wording. If the same sentence cannot be translated into ordinary engineering Russian or ordinary engineering English without FPF slang, it is probably not public first-entry text yet.

#Public Value Claim And Grounding Rule

A first-entry scenario may state substantial project value, but that value claim must be grounded. The scenario is not bare marketing copy. It should let an unfamiliar practitioner or assisting agent recognize a project situation, imagine a first useful result, and see the substantive FPF mechanism behind that value claim.

A conforming public first-entry scenario therefore:

• starts from a concrete project need in ordinary engineering language;
• names the first useful written result or decision aid before it names internal FPF apparatus;
• names the first pattern family as the means, not as the headline;
• shows at least one substantive distinction, object, comparison, or decision that FPF will make usable;
• avoids cards, forms, pattern ids, quality vocabulary, projection vocabulary, and conformance vocabulary until the working use is already recognizable;
• keeps wording repair and description repair visible but below half of the public scenario set, so FPF does not present itself mainly as speech policing.

The public first-entry set should read like "here are typical ways FPF can help a working project first", not like "here is the internal topology of FPF" and not like "here are slogans about better thinking."

#Preface Principle Rule

The Preface explains why the readme scenarios are possible. It names cross-cutting ideas once, in narrative order, without copying the readme scenario table.

The Preface is read by people and agents who may still be deciding whether FPF is worth the cost of opening the heavier pattern bodies. It therefore has a didactic job: show that the public first-entry value claims are not empty marketing and not a loose collection of tips. The Preface should make the reader see the underlying engineering ideas that allow FPF to help with architecture, problem shaping, evidence, comparison, naming, mathematical modeling, quality, and improvement.

The Preface should cover at least:

• transdisciplinary use without collapse of local meanings;
• local closure inside an open world;
• holons, systems, epistemes, and the fact that architecture applies wherever holons have structure;
• EntityOfConcern and description, including description episteme, publication form, carrier, and multi-view publication separation;
• thinking-through-writing through patterns, cards, records, views, and publication forms;
• architecture as structure and epiplexity as an architecture characteristic;
• first-principles-to-work through E.18 transformation-flow structure and E.18.1 P2W;
• mathematical lenses, formal-substrate declarations, mechanism import, and first-principles carry-through as distinct claims;
• ontology-first wording repair through E.10, E.10.ARCH, F.18, and F.19;
• evidence, assurance, gate, decision, and work separation;
• characteristic spaces, quality, NQD/OEE, and improvement loops;
• novelty, diversity, and state of the art;
• didactic primacy and plain explanation paired with technical fields.

The Preface may narrate across many pattern families, and it may discuss FPF as a whole project, including companion explanations, worked cases, tools, and project-local adaptations when those help explain the Core Specification. This is not leakage from one pattern into another. A Preface is allowed to explain the project-level idea that several patterns implement together.

The Preface may point to pattern families, but it should not become a second first-entry index.

#Preface Plain-Engineering Narrative Rule

Preface prose is written in plain engineering language first and FPF vocabulary second.

A conforming Preface:

• states the working idea before the FPF term;
• gives a plain gloss before a strict FPF term carries the main explanatory point;
• uses pattern ids as addresses for stricter treatment, not as the main explanatory language;
• keeps vivid explanation and didactic force when precision repair removes overread;
• shows how the first-entry scenarios are grounded in real concepts, not only how they are distributed across patterns;
• can be understood before the reader has studied the pattern bodies, even though the pattern bodies remain the source of exact governance.

FPF-specific terms such as EntityOfConcern, episteme, publication form, carrier, viewpoint, DRR, math lens, FormalSubstrate, NQD, OEE, Plain, or Tech may appear in the Preface only when the ordinary engineering distinction is already visible or immediately glossed. A Preface paragraph that cannot be understood without prior FPF vocabulary is not yet in Preface style, even if every term is technically lawful.

#Pattern Problem-Frame Rule

A pattern's own Problem frame is the local high-precision first-recognition section.

It should let a working practitioner recover:

• the pattern's primary EntityOfConcern;
• the working problem;
• what goes wrong if the pattern is missed or misread;
• the first admissible action;
• the practical result that action buys;
• the ordinary not-this-pattern boundary.

Add candidate-pattern comparison only when a real entry-discoverability problem exists. Otherwise, keep cross-pattern comparison out of the pattern body and use ordinary Relations, ToC query phrases, or expanded cases.

#First-Entry Terminology

Preserve the first-entry terminology.

Avoid route, workflow, lifecycle, entry neighborhood, semantic area, ontological neighborhood, map, owner, load, posture, support, and other broad heads as entry terms unless the relevant governing pattern has recovered their specific FPF kind and admissible use.

#Public readme Section Single-Source Rule

The FPF readme section carries the public first-entry scenario set.

If the same public first-entry content is exported into another publication form, export it from the FPF readme section instead of maintaining a second public first-entry version.

#Projection and Authority Boundary

Entry and projection publication units help a user find the governing pattern. They do not govern the claim by themselves.

When a projection is used, it must be clear whether it is:

• public orientation;
• table-of-content query material;
• pattern-local recognition text;
• expanded entry-disambiguation case;
• retrieval card;
• quality or projection evidence for an FPF artifact;
• ordinary citation or relation.

If a projection needs to answer a substantive claim, use the governing pattern body or the pattern that governs that claim. Do not strengthen the projection.

#Worked Slices

#Public Entry From A Project Question

A project team says: "We need to review the architecture of our AI-agent platform before choosing a vendor."

The public readme first-entry scenario points to architecture, comparison, and evidence:

• architecture: what holon is being architected, which structures matter, and which architecture characteristic is under concern;
• comparison: which vendor, build, fine-tune, or hybrid alternatives remain in the candidate set;
• evidence: what tests or assurance arguments are needed before commitment.

The first governing pattern family is not a wording-repair pattern. It is C.30 for architecture, with A.19, C.11, A.10, or B.3 applied when the project question narrows to comparison, local choice, evidence, or assurance. E.10 is used only if the text hides the kind of architecture, evidence, decision, or publication claim being made.

#Duplicate First-Entry Row Discharge

A compact first-entry index row says:

Architecture and diagrams:
  start with C.30, C.30.AD, evidence, and dashboard patterns;
  remember that diagrams are not proof;
  compare alternatives before choosing.

Do not keep this as a second entry canon. Discharge its useful content by kind:

After discharge, the remaining row is deleted because it only duplicates the readme scenario set and creates a second canon. The deletion preserves value because every claim being made has a publication unit or governing pattern that matches its kind.

#Conformance Checklist

#Common Anti-Patterns

#Relations

• The FPF readme section carries public first practical entries.
• Preface carries cross-cutting ideas and principles behind the public first practical entries.
• E.8 governs pattern form and pattern-local Problem-frame discipline.
• E.19 checks entry, projection, and pattern-use discoverability during review and refresh.
• E.21 evaluates whether corpus entry and projection material preserve quality without becoming pattern content.
• F.17, F.18, F.19, E.10, and E.10.ARCH govern lexical, naming, and wording precision when entry cues hide FPF kinds or relations.
• I.2 carries expanded entry-disambiguation cases only when compact public first-entry scenarios and local Problem frames are insufficient.
• ToC rows provide query and dependency cues; they do not replace public first-entry scenarios or governing pattern bodies.

#E.11:End

Last Updated: 2026-06-08 — this section last modified in upstream FPF commit 9b1cb920 (github.com/ailev/FPF)