Four ordinary starts before a PatternID

Preface node heading:four-ordinary-starts-before-a-patternid:816

What this page is

This is generated FPF reference text from the specification preface or supporting sections. It helps interpret FPF; it is not FPF Reference product documentation.

Methodology

Use it to understand how the specification wants to be read, then return to a route, pattern, or work packet for active work. Cite generated IDs only when the wording changes the task decision.

Content

Sometimes the obstacle is not choosing among pattern titles. A familiar phrase already hides the project object that the next claim needs. The four direct starts below are independent: use the one whose situation is current, take its smallest useful result, and stop. They are not a lifecycle or a form to complete.

  • “We need to refer to the relation that actually holds, and perhaps to tell one episode from another.” Name the exact participants and the ordinary relation first, then open the pattern that directly owns it. If a readable assertion that the relation obtains is enough, stop there. Only when later history, comparison, another relation, or an operation application must distinguish repeated occurrences should A.6.REL apply the direct owner's same-versus-new-occurrence rule and return one recoverably individuated occurrence. A table row, edge, identifier, report, or assertion does not make the relation obtain. If exact recovery finds no current direct relation for the needed claim, the neighboring exit is A.6.RCD; missing participants, facts, predicate, identity rule, or governor remain explicit blockers.
  • “The project, process, or case report no longer tells us what the decision is about.” Use A.15.6 to recover the subject. An actual project is one qualifying composite U.Work; a process question concerns one reusable U.Method, one exact selected U.Structure, or one TransformationFlowStructure; a case follows one exact affected referent or claim through only the change history and closure basis needed now, while naming one later use that remains outside the closed case. Treat target system as an ordinary cue for the exact project system-of-interest question. Keep an intended future system in a plan or description, and keep plan or decision designation, actual work-to-system facts, role interpretation, and role assignment as separate claims. Stop when the direct subject and bounded claim answer the decision; if systemhood of the recovered entity still matters, the neighboring exit is A.1.SCR. A suffix, team, plan, dashboard, or case file does not identify the subject.
  • “Someone drew or named a bounded context, but we do not yet know what organization the decision may rely on.” Use A.1.1 to recover one exact model edition, use locus, and the direct applicability, assigned-Work use, or fixed-content coherence relation that answers the question. Select the optional BoundedModelUseStructure under A.22 only when their joint organization changes the decision and its exact constituents, obtaining relations, applied constraints, and named selection-use frame are all present. Otherwise stop at the direct relation or state the missing discriminator. This structure is not a holon, subsystem, team, label, scheme, scope, viewpoint, view, representation, or diagram. Context Mapping remains a U.Method, and a cross-context organization needs its own selection. If the real question concerns an episteme under a viewpoint, the neighboring exit is E.17.0.
  • “We have a problem card, assessment, or serious concern, but do not know whether an actual problem exists.” Use C.22.PFR only for an obtaining ProblematicForRelation: one exact actual-condition occurrence and one exact criterion-applicability occurrence whose selected input is actually adverse for the named entity and use. A predicate, applicability occurrence, assessment, assertion, evidence posture, ProblemCard, forecast or modal concern, and current-solvability or continuation claim remain different objects. Stop with the ordinary actual-problem sentence or the exact missing condition, applicability, adverse input, or governor. If the useful object is instead reviewable problem-side formulation, the neighboring exit is C.22.2. One card may describe no actual PFR, and selecting a method changes current solvability or continuation, not the PFR's participants, obtaining, identity, or adverse condition.

Ordinary bounded use does not begin by filling a shortlist, candidate form, five fit findings, or recommendation record. Those epistemes become useful only when a named receiving use relies on addressable comparison history, transfer between people or agents, automation, audit, durable reuse, delayed feedback, expensive feedback, or costly reversal. Even then, materialize only the candidate, fit, recommendation, closure, or provenance records that the receiving use needs. The semantic schemas are reference models, not user-interface forms or serialization instructions.

The first useful result is governed by the selected direct pattern. It may be a changed physical or clinical state, a capability, an episteme, a relation, dated U.Work, or another exact subject-governed value. A note, measurement, dashboard, or card is the result only when producing that episteme was the intended result. Working product is not a durable FPF term because it does not identify one governed value across these cases.

Keep three coupled flows distinct. Pattern-selection Work may produce its own governed episteme: a fit finding, recommendation, or selected candidate. Following the selected pattern's Solution guides action and checking; the subject result exists, or its relation obtains, only under its own direct governor and basis. That result may later be used as an input, tool, context, constraint, or other governed participant in downstream subject work without becoming the result of that later flow. Treat those role words as ordinary cues, not relation kinds: name the exact source position, exact receiving position, and directly governed relation occurrence. With no direct relation kind or predicate, return missing-governor; with undecided facts, keep the relation open; with a false predicate, assert no occurrence; with an obtaining occurrence but a missing endpoint binding, return missing-endpoint-binding. Across these flows, an acting U.System under a U.RoleAssignment may select, construct, or refine a U.Method, plan dated work when preparation is current, and perform U.Work that affects the real EntityOfConcern. Public and project epistemes can guide that line without becoming the acting system, method, plan, work, or subject result. Use E.18 to recover each TFS-local position; use E.18.NET only when independently identified TFS values must be treated together as a network. Otherwise that apparatus stays absent. A plan or selection episteme does not become machining, treatment, organizational change, learning, or another downstream subject result.

A quick three-way test is: same TFS, different valuation; one parent-relative internal portion, subflow; independently identified TFSs, network. A valuation gives different state, path, or run values over the same exact TransformationFlowStructure. A subflow keeps every selected position and already obtaining internal U.Transfer occurrence inside one exact parent TFS. A TransformationFlowStructureNetwork selects independently identified TFS or nested-network members together with exact obtaining relation occurrences whose participants are bound across their positions. DesignRunTag stays local to one exact position binding in one TFS; it is never a network-wide phase label. Use E.18 for a valuation or subflow, and E.18.NET for a network.

FPF can repeat this use as the project changes: ask the current question, compare when needed, inspect a direct pattern, follow its Solution, retain its independently governed result and direct basis—or a truthful stop when that basis is missing—and return when a stronger claim, changed basis, or unresolved relation becomes current. A mantra is Plain didactic wording for a repeatable attention aid. A local mantra keeps one bounded result, often one pattern's Solution, in attention; a long mantra keeps the dependency from a recognizable difficulty to a distant intended result, its checking, and its later use across direct patterns. For example, A.6.P's bounded reminder to restore the exact relation, its participants, and its direct owner is a local mantra, while A.1.STM's outside-use-to-recursive-builder attention map is a long mantra. Phrase length does not decide the scope. Choose a long mantra by its intended final result; in ongoing work, place supported results on its readable attention map and enter at the first absent, stale, disputed, or unsupported result. Keep didactic order, logical dependency, planned or actual Work order, and the subject relations that obtain distinct. A.22.CGUS enters only when separately recovered positions, conditions, branches, returns, and stops warrant an admitted ConstraintGovernedUnfoldingStructure@Context; a shown traversal may then be a DemonstrativeUnfoldingSlice@Context. Ordinary long and local mantras need no kind, F.17 row, registration, plan, authority, or performed Work. Use A.1.STM when the current problem is loss of the system-thinking long-map connection.

This Preface explains why these practical uses belong to one framework. The Table of Contents supports search when the reader already knows the pattern family. The pattern body governs the actual project claim and carries the exact Solution, boundaries, and checks. README and ToC references point to those direct patterns and published term rows; they do not become alternate schema or finding stores.

This Preface is also a reader-facing rendering of FPF's first-principles architecture. It is written for people who need the whole-framework picture before entering exact patterns. It foregrounds holons, descriptions, architecture, evidence, publication, choice, improvement, source-publication and source-use currentness, and domain or local framework growth; it deliberately coarsens, omits, or defers individual pattern detail, source publications, source-use history, and many relation records. When a Preface claim becomes load-bearing, return to the governing pattern body.

Use the readme when a current project question needs a practical-use card and a direct pattern. Use this Preface when you need the whole-FPF picture. Use the Table of Contents when you already know the pattern family or need a search-oriented overview. Use the pattern body for the exact Solution and the claim it governs.

The large areas of the specification can be read as one conceptual architecture. You do not need every name in this list yet; it is a map for later lookup:

  • Part A gives the kernel: holons, contexts, roles, capabilities, methods, work, time, scope, signatures, architecture, characteristics, measurement, comparison, and foundations for choosing from candidate sets.
  • Part B gives transdisciplinary reasoning, emergence, evidence, assurance, trust, canonical reasoning, creativity, problem-side records and cues, and bridge discipline.
  • Part C gives major extension patterns: characterization, measurement, mathematical modeling, architecture, temporality, causality, option portfolios, quality, problem shaping, and precision restoration in specialized domains.
  • Part D keeps ethics, conflict, and multi-scale value questions visible where they are live.
  • Part E gives the FPF constitution: pillars, guard rails, pattern form, lexical discipline, description and publication discipline, transformation-flow structures for carrying results through work, admission, review, and design-rationale discipline.
  • Part F gives unification and naming: local meaning units, concept sets, bridges, term sheets, local-first naming, and technical prose repair.
  • Part G gives state-of-the-art work, option portfolios, option selection, benchmarks, shipping, evidence, bridges, dashboards, and refresh disciplines for reusable domain work.
  • Later publication units carry glossaries, expanded cases, annexes, or other supporting units when the compact pattern body is not enough.

That orientation list is only for lookup. The exact rules remain in the pattern bodies.


Last Updated: 2026-08-03 — upstream FPF commit 9dd92159 (github.com/ailev/FPF)