#Preface (non-normative)

Preface node heading:preface-non-normative:929

#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

#FPF.Preface:1 - What This Specification Is And How To Use It

This Core Conceptual Specification publishes the general pattern content of an edition of the First Principles Framework (FPF), together with this Preface and navigation. Its pattern language supports explicit, reviewable and improvable conceptual work in engineering, research, management, governance, and mixed human and AI projects.

The reader should not need FPF vocabulary before this Preface becomes useful. Here an FPF term should first name an ordinary engineering distinction, then point to the pattern that gives the stricter form.

FPF's Core brings together shared concepts, constitutional principles and reusable methods for reasoning. The Kernel is the defining content of universal meta-concepts within that Core; all eleven constitutional first principles in E.2 govern the Kernel and other contributions. Domain and local frameworks explain work in their own settings and state which Core content and editions they rely on. This Preface explains the overall arrangement. Pattern bodies give the definitions, methods and conditions needed for an exact use; files and websites make those publications available.

For an ordinary problem, use a known adequate domain method directly. Consult a supplying pattern when a missing distinction or operation prevents the needed result. Read the detailed distinctions below when their claim or action is your current question.

FPF is not a domain encyclopedia and not a project-management method. It is a framework for making hard project reasoning coherent when many project entities and relations are easy to mix: systems, bodies of knowledge and models, architecture, descriptions, publications, concern-specific views, local system-role kinds and assignments, methods, plans, performed work, evidence, decisions, options, commitments, and improvement criteria.

FPF starts from holons: project entities that can be treated as wholes and as parts. A holon can be a physical system, software system, organization-as-system, publication system, body of knowledge or model, research program, AI-agent arrangement, work occurrence, discipline, or another entity admitted by a pattern under part-whole treatment. U.Method is an admitted non-agentive holon kind: methods can be assembled from method parts into whole methods with whole-level preconditions, effects, constraints, and interfaces, and a whole method can become a part of a larger method. This does not make a method an actor, description, plan, or dated work occurrence. Systems can enact methods and can be classified by context-local system-role kinds. A local system-role kind classifies U.System candidates in one bounded context. The work-facing contribution grounds the kind's local identity and must be recoverable independently; the kind's non-circular KindSignature states how a candidate qualifies. The kind is not the contribution itself, a capability, required effect, participation or functioning relation, work position, assignment occurrence, classification judgement, responsibility, Method, or Work. Function wording alone establishes none of those claims. Eligibility for assignment, or the existence of an assignment, neither defines the kind nor classifies a System by itself. It is not a public root U-kind or a holon kind. Descriptions of methods or system-role kinds may be epistemes, but a description does not acquire the described value's kind.

In claim-bearing text, bare role selects no one FPF object. When the distinction matters, use E.10.ROLE to recover what the claim concerns—for example, a local system-role kind, an assignment occurrence, participation in a relation, or responsibility—while ordinary explanatory uses can remain ordinary.

Management words need the same discipline. An actual project is one qualifying composite U.Work, not a new project kind; process wording returns to a reusable U.Method or to the exact selected structure current in the question; case wording returns to the exact subject or claim, its bounded closure basis, and a named downstream use that remains outside the closed case. A system that exists only in a plan remains intended, and project designation, system-role-kind interpretation, and system-role assignment remain separate claims. Use A.15.6 when the familiar label still hides which subject or claim is current.

FPF is written as a pattern language. A pattern is not a tutorial, blog post, checklist bureaucracy, or local process script. It is a reusable action-guidance form. A mature FPF pattern lets a working practitioner recover:

• the working situation where the pattern is useful;
• the project entity under concern, which FPF calls the EntityOfConcern, and the relation, claim, or work object being handled;
• what goes wrong when the distinction is missed;
• the forces that make the problem hard;
• the solution and first useful result;
• the consequences and related patterns;
• the checks that keep the result reviewable.

The exact rule content located at E.8 states the standard pattern form. E.19 and E.21 support review, refresh, and pattern-quality evaluation. Decision-rationale records, or DRRs, are short records explaining why one bounded FPF content decision changed; E.9 gives their ordinary decision kernel and adds exact ClaimGraph, work, or result identities only when the decision or a named later reliance needs them. Those pattern descriptions matter because the FPF corpus itself evolves by the same discipline it asks other projects to use: explicit decisions, visible losses, recoverable meanings, and repeated improvement.

The FPF readme section presents the semantic practical-use cards maintained there. They are not numbered entrances or one route through the framework. Each card starts from a recognizable working situation and a current practical question, points to one or more direct patterns under explicit conditions, names the kind of first useful result, and says when to stop, return, or inspect a stronger neighboring pattern.

When several cards seem plausible, compare them by the situation they recognize, the difference between their first results, and their stop or reconsideration conditions. That comparison may remain in the conversation. Before selecting a pattern, inspect its Problem frame, Problem, Forces, Solution, Consequences, and ordinary non-use boundary. Once one direct pattern is selected, use E.11.PUA to follow its Solution to the smallest useful result or an honest blocker. If the expected subject result is absent, keep an honest interim result and leave that expectation open. Keep an ordinary reversible judgement conversational; introduce an exact assertion, result basis, method, work, or reliance support only when that distinction changes the truth or a named later reliance needs it. Name a dependent use only when an actual continuation or later reliance is current. Use E.11.PUR when applicability, recommendation, coordination, or ordering among candidate pattern uses is the current question.

#FPF.Preface:1.1 - Four ordinary starts before a PatternID

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 resolve its exact predicate and defining or constraining ClaimGraph. 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 an agent use the Method described at A.6.REL with the relation'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, use the A.6.RCD missing-basis disposition; missing participants, facts, predicate, identity rule, or established missing-governor result 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, system-role-kind interpretation, and system-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 identify the model edition and the place or entity about which it is used. Recover the relation needed for the decision: where the model applies, how it is actually used in assigned Work, or whether a concrete expression agrees with the model's fixed content. 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 to check whether an actual condition is adverse under the predicate applicable to the named entity, scope, and interval. An obtaining ProblematicForRelation relates one exact actual-condition occurrence and one exact criterion-applicability occurrence whose selected input is actually adverse for that 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 supported actual-problem or non-adverse-condition judgement, 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 one subject entity or obtaining relation under its defining or testing content and current basis. In ordinary use, name it in domain language; add a predicate, identity rule, assertion, pattern locator, ClaimGraph, or Method only when that distinction changes the truth, next action, stop, or named reliance. The selected pattern id locates action- or judgement-guiding content; it does not make the result exist or the relation obtain. The result may be a changed physical or clinical state, a capability, an episteme, a relation, dated U.Work, or another 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 value across these cases.

Keep three activities distinct: selecting a pattern, using its guidance to obtain a subject result, and later work that uses that result. Each can have its own result. Pattern selection may remain a conversational judgement or, when later reliance needs it, produce a fit finding, recommendation, or selected-candidate episteme. A person or assisting system then uses the selected pattern's action- or judgement-guiding content. Recover a separate Method only when the Solution actually describes one and the current claim depends on its identity. Claims about a performer, assignment, or dated Work need their own direct basis; they do not become optional merely because the Method identity is not needed.

The subject result exists, or its relation obtains, according to its direct predicate, identity or occurrence rule, applicability, and case facts—not because an assertion states it. A positive durable or reliance-bearing account additionally needs the appropriate current assertion and direct support. That result may later be used as an input, tool, context, constraint, or other needed participant in downstream subject Work without becoming the result of that later flow. Treat those positional words as ordinary cues, not relation kinds: name the source position, dependent-use position, and relation occurrence that the claim needs.

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, a U.System may select, construct, refine, or describe a U.Method without thereby creating a Work occurrence or assignment, and may plan dated work when preparation is current. If the account says that the System actually performs admitted dated U.Work, first recover that exact performer through A.13 and let A.15.1 independently admit the Work. Stop there for a Work-only account. Only when the account or receiving use also consumes precise assignment-bound attribution should it name the covering assignment occurrence and its declared U.SystemRoleAssignment species, retain every identity-bearing participant, check holder equality with the already recovered performer, and establish the F.6 relation. Missing or failed F.6 leaves the Work intact and lowers only the attribution. The assignment neither classifies the System, performs the Work, nor supplies the Method.

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, recommendation, or pattern sequence does not become machining, treatment, organizational change, learning, Transformation, or transformation-flow structure.

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 description, use its action- or judgement-guiding content, retain the exact subject result and direct basis—or a truthful stop when that basis is missing—and reconsider when a stronger claim, changed basis, or unresolved relation becomes current. Recover a separate Method identity only when the Solution actually describes one and the current claim depends on it.

A mantra is Plain didactic wording for a repeatable working reminder. It helps the reader recognize a relevant difficulty, recall a useful contribution and find the pattern that supplies it. A local mantra keeps one bounded result, often one pattern's contribution, in attention. A long mantra keeps the dependencies from a recognizable difficulty to a more distant intended result, its checking and later use across several patterns. A.6.P's reminder to recover a relation, its participants and its defining ClaimGraph is local; A.1.STM's map from outside use to recursive builders is long. Phrase length does not decide the scope.

For a group of jointly used patterns, a mantra works like a table of contents that also reminds the reader how their contributions connect. Its phrases may address the patterns through their Problem frame or Problem, or through their Solution. A question can recall what remains unresolved; an action phrase can recall how to obtain the needed result. Both can point to the same pattern use. For example, these two formulations recall the same contributions to the report-review inquiry developed in §16.1:

Use whichever formulation the intended reader can recognize and apply. A pattern whose title names a difficulty can still be recalled through its Solution. Wording such as “find what the trial establishes” can state both the difficulty and the action intended to resolve it; clarify the difference only when it changes the next useful action. There is no need to give both formulations every time.

A long mantra may arrange these contributions as a happy path for teaching: a deliberately simplified unfolding that makes their connections easy to follow. The order teaches those connections, not a required sequence of performed work. Enter where the needed result is absent, stale, disputed or unsupported. Reuse an adequate result, return when its conditions change, and stop when the intended result is available. On a diagram, name the teaching use and the omitted branches or returns that matter to its intended use; return to the fuller account when those omissions can change the choice. A customer-journey mantra, for example, may show one route to useful product use while omitting a return from an agreed purchase to securing missing operating support.

Keep this reminder, the possible continuations it describes, a work plan and the observed work history distinct. A.22.CGUS applies when the underlying structure has the required constituents, relations, constraints, local loci and potential continuations; a shown traversal of a qualified structure may then be a DemonstrativeUnfoldingSlice@Context. Qualification concerns that structure, not whether its labels are questions or solution phrases. Ordinary local and long mantras require no formal CGUS qualification. Use A.1.STM when the difficulty concerns the system-thinking long map; use E.10.MOVE only when wording about a mantra move still hides the intended contribution or claim.

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. A pattern body is a pattern episteme containing its exact Solution, boundaries, checks, action- or judgement-guiding content, and the definitions or constraints it actually asserts. It is a U.MethodDescription only when that membership is established and the distinction is current. The actual project claim remains a separate subject assertion. README and ToC references point to those rule-content loci and published term rows; they do not become alternate schema or finding stores.

This Preface gives a reader-facing explanation of FPF's first-principles architecture. It deliberately coarsens, omits or defers individual pattern detail, source publications, source-use history and many relation records. When a Preface claim becomes necessary for a decision, return to the relevant pattern for the exact claim, its conditions and the detail omitted here.

Use the readme when a current project question needs a practical-use card and a direct pattern locator. 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 its exact Problem frame and Solution; recover an exact predicate, ClaimGraph, or Method only when the current claim, action, or named reliance needs that distinction, and state the current project claim separately.

The following Parts organize the published material for lookup. Kernel membership follows the defining content of universal meta-concepts wherever their patterns supply it. Other content can develop a method or state a constitutional requirement. You do not need every name in this map before using a relevant pattern.

• Part A introduces foundational distinctions and their uses: holons, contexts, system-role kinds and assignments, 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 develops general patterns for characterization, measurement, mathematical modeling, architecture, temporality, causality, option portfolios, quality, problem shaping and precision restoration.
• 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.

#FPF.Preface:2 - FPF As A Project, Not Only A Pattern List

FPF is a project for improving how difficult reasoning is written, checked, taught, used by humans, and used by AI agents. The Core Specification is the normative center of that project, but it is not the whole project.

The Core Specification gives the pattern language: the named concepts, distinctions, pattern bodies, conformance checks, and relations that make FPF usable across domains. It says what the reasoning objects are and how exact claims are constituted and checked. When a project needs to know whether a diagram is architecture, whether a dashboard is evidence, whether a model output may be used for a decision, or whether a term is hiding several kinds, the Core pattern bodies provide the relevant action- or judgement-guiding content and the definitions or constraints the claim actually needs. A separate U.MethodDescription, admitted Method, or exact ClaimGraph locator is recovered only when that distinction is current. Evidence use depends on the relation between an exact episteme and a target claim (A.2.4), with reliance checked under A.10; publication alone does not establish that relation. Actor, ownership, and external-authority claims need their own direct basis.

Domain principle frameworks explain the methods and evidence practices of their fields and identify the FPF content and editions on which they rely. A local practice framework supplies guidance for a bounded local setting and may also rely on a domain framework. A local guide that simply applies existing guidance needs no new framework boundary. E.4 explains when a separate framework or adjacent product is useful and how its dependencies differ from its publication.

Other publications can teach, demonstrate or support this content: companion explanations, worked cases, tooling guides and research notes have different purposes. A companion may teach a method more slowly, and a tool may implement a publication form; the method, its explanation and the implementation retain their own identities. A useful explanation can be brought back into the supplying pattern when ordinary framework use needs it.

The Preface belongs to the framework edition it explains. A DPF Suite instead brings together separately constituted DPF product series. An optional, separately constituted DPF Suite Reference can explain how to use their contributions together and return readers to the supplying editions. It is a non-framework publication, not a required stage before using a known sufficient DPF result. E.4:4.2 and E.11.DSG give the full Suite and Reference rules.

One file or website can expose several such publications. Their shared carrier provides access; each framework, Reference or companion keeps the content, edition and change conditions established for it. Core meanings remain defined in Core. Authors can revise domain and local methods while preserving those dependencies. The Core can therefore remain tool-agnostic while companions, tools and domain explanations change for their intended uses.

#FPF.Preface:3 - Why FPF Exists

Many projects do not fail because nobody had an idea. They fail because the idea changes kind as it travels.

A sketch becomes a promise. A dashboard becomes evidence. A model output becomes permission. A selected set becomes one winner. A method description becomes performed work. A diagram becomes the architecture. A safety case becomes safety. A clever metaphor becomes an ontology. The sentence still sounds familiar, but the project has changed what it is allowed to claim or do.

FPF exists to prevent that kind of drift while preserving useful early inquiry and communication. It does not ask every team to speak in formal notation. It lets rough, early, useful language remain rough while it is still only recognition text. When the same language begins to influence work, commitment, evidence, assurance, architecture, or choice, FPF gives a way to recover the exact kind of claim, its predicate and assertion, and the pattern-description locator for its defining or constraining ClaimGraph.

The practical ambition is simple: keep difficult reasoning alive long enough to improve it. A project should be able to generate alternatives, preserve uncertainty, compare options, choose locally, publish decisions, reopen stale claims, and repair language without losing the EntityOfConcern the reasoning was about.

For humans, FPF gives a shared working memory for complex reasoning. For AI agents, FPF gives typed constraints, named distinctions, and checkable written forms so generated text can be tested against the kind of work it claims to perform. For organizations, FPF gives a way to make reasoning transfer across teams without pretending that all teams use the same local meanings.

#FPF.Preface:4 - Creativity And Assurance Mature Together

Many frameworks choose a side. Some optimize for assurance: audit trails, evidence, safety gates, confidence, compliance, and sign-off. Others celebrate creativity: exploration, novelty, pivots, abduction, and open-ended search. FPF is built to keep both rails alive at once.

Creativity without assurance drifts. Assurance without creativity calcifies. A project that only imagines produces attractive but untested possibilities. A project that only checks can become excellent at rejecting new options before it has generated any worth checking.

FPF treats creative work as governed search. It gives names to the early move where a team asks "what could be true?", to the generation of multiple candidate explanations or designs, to the preservation of novelty and diversity, to the comparison of alternatives, and to the point where exploration should narrow into refinement. The relevant families include abduction, problem shaping, novelty-diversity and open-ended exploration, set-returning selection, publications of current best-known options, and option portfolios.

FPF also treats assurance as more than a final audit. Evidence, assurance, source-publication currentness, source-use currentness, gate validity, and decision permission are different claims. They can mature while creativity is still active. An early idea can be preserved as a cue without pretending it is evidence. A candidate can be kept in a portfolio without pretending it has been selected. A promising mathematical way of looking at the problem can be recorded without pretending it validates the world.

This useful order does not define a project sequence. The practical stance is:

• generate enough candidate explanations or designs before converging;
• keep novelty, use value, constraint fit, and comparison characteristics visible;
• turn promising candidates into forms that evidence and assurance can inspect;
• publish selected options, Pareto-like fronts, or portfolios without hiding remaining uncertainty;
• reopen the work when evidence, source-publication or source-use currentness, context, or state of the art changes.

In a laboratory, an anomaly is not merely noise. It may be a prompt for candidate explanations, followed by evidence and model comparison. In a product team, a concept sketch is not a meeting souvenir. It can become a reviewable knowledge object, which FPF calls an episteme, with scope, candidate value, and evidence needs. In operations, an emergency workaround may be a useful abductive move; later reliance on it depends on connections to evidence, assurance, and work records.

This is one of FPF's central payoffs: a team can be inventive without losing its audit trail, and conservative without closing down imagination too early.

#FPF.Preface:5 - Local Closure Inside An Open World

FPF assumes an open world. New evidence can arrive. A better mathematical model may appear. A source publication, source-use record, or telemetry relation may become stale. A competitor may change the state of the art. A user need may shift. A new concern may reveal that the same system should be described differently.

Engineering and management still need local closure. A bridge cannot wait for all possible facts. A gate decision cannot cite the entire universe. A release, experiment, procurement, safety case, or architecture review therefore defines what counts as sufficient for the next action.

The old open-world versus closed-world distinction is a useful didactic picture. In an open world, absence of proof is not proof of absence. If a name is missing from a party guest list, the list may be incomplete. In a locally closed operational world, absence from the accepted manifest matters. If a name is missing from the aircraft manifest, the airline acts as if that passenger is not on the flight.

FPF does not transform the open world into a closed one. It lets a project build small closed worlds for declared purposes:

• the exact source, scope, model-use organization, working situation, comparison basis, or other subject-defined boundary states what is current for this decision;
• an EntityOfConcern states what project entity the reasoning is about;
• a description states what can be relied on and under what relation;
• evidence and assurance state what claim is credible enough for the local use;
• a gate or decision states what boundary is crossed;
• a reopen condition states when local closure is no longer enough.

This is why FPF patterns often look strict. The strictness is local. It lets a project act while keeping the wider world open. A local closure is not a claim that nothing else exists. It is a declared scope for responsible action.

Local closure also does not license ceremony. Before a method, route, or review makes an action mandatory, ask whether a materially plausible result can change a named substantive decision within the nearest substantive horizon, whether the action realizes an already selected result, or whether removing it changes an assurance or recovery condition on which the use relies. This contribution is necessary but does not by itself make a proposed inquiry obtainable or worth requiring. Use A.11.OP for that screen and its boundary with direct duties and assurance. When the demand's worth remains open, C.11.DUA compares its attainable contribution and whole burden; a current local choice uses C.11. The result can be a qualified answer on the present basis.

#FPF.Preface:6 - FPF As An Evolutionary Architecture For Thought

A team can organize its reasoning so that a changed model, new finding, or departing colleague leaves other useful results recoverable. Its participants, reusable Methods, shared descriptions, and actual Work each have a structure and a different way of changing. FPF helps the team keep those differences visible while improving the arrangement.

FPF is an evolutionary architecture for thought. It is not a static inventory of concepts. It is an architecture of patterns, relations, checks, publication units, and improvement loops that can evolve as new problems, domains, AI tools, and state-of-the-art lines appear.

The analogy with evolutionary architecture in engineering is deliberate. A good architecture does not freeze a system forever. It provides structures that make guided change possible. It names the characteristics that matter, the constraints preserved through change, the comparison basis for alternatives, and the records that explain why a change was accepted.

FPF applies the same idea to reasoning:

• patterns provide stable forms for recurring reasoning problems;
• DRRs record why normative FPF content changes;
• evidence and assurance patterns keep trust from becoming a feeling;
• characteristic spaces define what "better" means for the object under improvement;
• precision-restoration patterns repair language when it begins to carry work;
• state-of-the-art and option-portfolio patterns keep the frontier moving;
• review and refresh patterns let FPF itself improve.

The result is not one final answer. It is a way to keep producing, comparing, selecting, publishing, and improving answers without losing traceability or semantic integrity.

#FPF.Preface:7 - Architectural Characteristics Of Thought

If FPF is an architecture for thought, then thought has architecture characteristics. Some of them are familiar quality words, but FPF treats them as characteristics of reasoning arrangements that can be improved, damaged, compared, or inspected.

The table is not a checklist for every project. It shows the kind of quality FPF is trying to preserve in reasoning itself. A project may enter through architecture, naming, evidence, mathematics, or comparison, but the deeper benefit is that the reasoning becomes more auditable, evolvable, and usable.

#FPF.Preface:8 - Beyond Bias Hunting

Critical-thinking practice often focuses on cognitive biases: confirmation bias, availability bias, planning fallacy, fixation, groupthink, and many others. That work is useful. It gives names to predictable failures in human judgment.

But bias hunting is mostly corrective. It starts after a bad pattern of reasoning has appeared. It asks the thinker to remember a growing list of mistakes and avoid them by vigilance.

FPF takes a more constructive stance. It does not only say "do not confuse the plan with reality." It gives separate objects for method description, plan, performed work, evidence, and result. It does not only say "do not trust the dashboard too much." It distinguishes evidence, published dashboard rendering, assurance, gate, and decision. It does not only say "do not jump to a favorite option." It gives candidate sets, comparison characteristics, selected options, and portfolio refresh.

That is why FPF's discipline around wording and descriptions should not make FPF look like a commission for checking speech. The repair matters, but it is not the center. The center is constructive: build reasoning arrangements in which whole classes of mistakes become harder because the EntityOfConcern, claim kind, evidence path, publication use, decision, and work object are not allowed to collapse unnoticed.

This changes the tone of FPF. It is not a list of warnings. It is a design language for better reasoning. The user should come away not only knowing what not to say, but knowing what to build next: an architecture question note, problem card, comparison frame, characteristic space, evidence-readiness note, naming card, repaired paragraph, modeling note, option portfolio, or improvement loop.

#FPF.Preface:9 - Thinking Through Writing

FPF relies on written forms because serious reasoning needs objects that can be inspected. In everyday work, much reasoning stays inside conversation, memory, chat logs, sketches, or tool outputs. That is often enough for one short exchange. Addressable records become useful when reasoning is to survive delegation, review, reuse, publication, AI assistance, or time.

FPF's cards, records, tables, views, term sheets, characteristic spaces, pattern bodies, conformance checks, and DRRs are thinking instruments. They are not documentation after the fact. Writing the record is often the work of thinking:

• a problem card separates a complaint from a problem that later work can use;
• a TaskSignature makes an accepted problem usable by later eligibility, acceptance, and method-family selection without selecting the method or planning the work inside the problem record;
• a comparison frame forces the team to say what is being compared and by which characteristics;
• a characteristic space makes "better" visible before improvement starts;
• a term sheet keeps local meanings from being flattened across teams;
• a DRR exposes what decision changed the specification and why;
• a pattern body makes a recurring working problem reusable without hiding its boundaries.

The medium is not prescribed. A team may use paper, markdown, a wiki, a spreadsheet, a model repository, or a specialized tool. FPF is tool-agnostic. What matters is the conceptual structure of the durable publication unit and the relations it makes recoverable.

This is especially important for AI use. An AI assistant can generate fluent prose faster than a team can inspect it. FPF forms give generated outputs and proposals places to land: candidate set, evidence gap, description-use note, architecture question, term sheet row, source-basis return condition, missing-structure return condition, or blocked-use result. Without such forms, the output often remains persuasive text rather than project reasoning.

Thinking through writing is not paperwork. It is how thought becomes durable enough to challenge, improve, and responsibly act on.

#FPF.Preface:10 - Thinking-Oriented Architecture, Not A Descriptive Upper Ontology

FPF shares one ambition with upper ontologies: it tries to make reasoning travel across domains. But its primary task is different.

A descriptive upper ontology tries to give a consistent inventory of what exists. It asks "what kind of entity is this?" and gives a taxonomy, axioms, and relations. That work is valuable. FPF uses ontological discipline constantly. But FPF is not only an inventory of entities.

FPF is a thinking-oriented architecture. It asks:

• what project entity is under concern in this project moment;
• what claim, relation, decision, evidence path, work object, or publication use is being made;
• which distinction needs to remain visible for an action to be responsible;
• what action- or judgement-guiding content is needed for the next use, and, when actual method identity matters, what exact Method and pattern-description rule content are current;
• what would make the result reviewable and reopenable.

This is the difference between a catalogue and an instrument. A catalogue can tell you that a method description and performed work are different FPF kinds. FPF also asks what happens in the project when those two are confused, what written form should separate them, what evidence or decision remains blocked, and what pattern should be used next.

The ontology therefore serves action guidance. FPF does not replace domain ontologies, mathematics, standards, or evidence. It gives them a place in project reasoning so they can be used without collapsing local meanings or publication forms.

#FPF.Preface:11 - When A Scale Claim Calls For Comparison

FPF's Bitter-Lesson Preference in E.2:6 uses the empirical Bitter Lesson to motivate examination of claimed advantages from more compute, data or search capacity in computational work. When that scale or generalization claim is current, or a separately declared local generality policy applies, begin with C.19.1's cheap scale-claim probe. State the receiving task, usable budget range, conditions and evidence needed for the claim.

Compare admissible options by their usable performance and uncertainty over that range. A steeper improvement curve can still stay below the required performance. When neither option dominates under the applicable comparison, there is no scale-based preference; a separate local policy must state its own basis and cost if it chooses greater generality.

An ordinary bounded procedure can be used on its task-specific grounds. For example, a fixed procedure for summing a known finite list needs correct arithmetic and an adequate task budget; the existence of a general learner does not require a scale audit or an adaptation waiver. Independently applicable assurance and oversight still apply.

Positive procedures, prohibitions and autonomous sequencing follow the actual task, control requirements and authorized policy. Minimal prescription and autonomy do not follow from a scale comparison. Adaptation likewise needs its own objective, evidence, permission, change authority and safeguards. Use E.2:6–7 for the exact activation, comparison, heuristic-debt and precedence conditions.

#FPF.Preface:12 - From Flat Documents To Multi-View Truth

Traditional document practice often treats one file as "the truth". Contemporary projects rarely fit that shape. A product, organization, architecture, safety case, research program, model, or AI-agent arrangement may need many descriptions for different concerns.

FPF separates the pieces:

• the EntityOfConcern is the project entity under concern;
• a description is a reviewable knowledge object, or episteme, that describes it;
• a view is an identified episteme that conforms to the fixed rules of an identified viewpoint (E.17.0);
• a viewpoint states the concerns and fixed rules used to judge that conformance;
• a publication form makes a description, view, card, record, table, or dashboard available for use;
• a carrier is the physical or digital rendering or storage that makes the publication form available;
• a reliance boundary says what the publication may responsibly be used for.

This is why a diagram is not the architecture, a dashboard is not evidence by itself, a model card is not model safety, and a generated explanation is not the system it explains. They can all be valuable, but each has a kind and a relation.

Multi-view publication is therefore a strength, not a defect. A safety case, architecture description, dashboard, model card, evidence graph, and management summary may all concern the same project entity under different viewpoints. FPF's job is to keep them connected without letting one view silently replace another.

This is also how FPF can work with distributed and AI-generated representations. For a vector representation, solver model, graph, natural-language summary, or human-readable pattern, identify the claim-bearing episteme and its relation to the project entity. That episteme may be a description under E.10.D2; it is a view only when it conforms to the fixed rules of an identified viewpoint under E.17.0. Recover the source and the relation involved only when the current use depends on a claim about source use, derivation, or construction. Keep its publication and reliance boundary separate from those recognition conditions. The question is what claim the publication can responsibly carry.

A narrative or explanatory rendering is one such publication shape. Its source relation remains inspectable when it states what selected source structure it used, what it preserved, what it deliberately coarsened, abstracted, omitted, or lost, which viewpoint it uses, the source-return condition, and any unresolved neighboring assertion with its subject-pattern locator. If the rendering begins from an architecture description or view, that source basis may already be a coarsened account of actual, expected, or candidate structures; the rendering keeps that earlier loss visible. Narrative readability does not turn a rendering into evidence, assurance, permission, architecture, or the described object itself.

#FPF.Preface:13 - Architecture As Structure Of Holons

FPF treats architecture as structure of a holon in a context, not as a diagram, document, approval, promise, or implementation plan.

This makes architecture broad. There can be architecture of a physical system, software system, organization, work system, body of knowledge, publication system, research program, AI-agent arrangement, or FPF itself. Wherever holons have structure, architecture can be discussed.

Architecture descriptions, structural views, viewpoints, diagrams, models, and publication forms are descriptions or publications about architecture. They are valuable, but they do not replace the architecture itself.

The architecture pattern descriptions make this distinction usable without creating a second ontology. The defining or constraining ClaimGraph sources are located at C.30 for architecture as an EntityOfConcern, A.22 for selected structure, C.30.ASV for architecture structural-view assertions, C.30.AD for architecture-description assertions, and A.6.M for module-interface relation repair. C.31 and related architecture pattern descriptions locate exact rule content for modularity, reusable structure, scale, interlevel tension, and architecture-changing assertions. Architecture, selected structure, each description episteme, each view, each publication, and each change remain separate subjects.

This matters because architecture work is not only "draw the diagram". It is also "which structure matters", "what characteristic changes", "what tradeoff is visible", "what description is needed", "what interface claim is being made", "what evidence would make this architecture decision responsible", and "which move changes the architecture rather than merely changing a document about it".

Assess how hard a holon is to understand, change, control, reuse or improve under the declared architectural characteristics and concerns. Keep the structural dependencies that contribute to this difficulty visible in descriptions, including simplified diagrams.

A Method can be a constituent of another Method while having its own constituents. Performing an action can realize several levels of work at once. For example, updating a running total can be part of calculating a result and preparing a report. The report's purpose affects which updates are appropriate. A result that suffices for a final sum may fail a question about the first chronological limit crossing. Recover these connections with B.1.5.EW; compare a replacement across its encompassing uses with B.1.5.RS.

The Method's constituent–whole relations also help identify what performers must be able to do or obtain, and which shared resources must fit their combined work. C.30.ASV:4.5a separates composition, result use and other relevant structures; A.22:4.3a explains how a drawing can represent them vertically or horizontally under a stated convention. A practitioner may know a basic operation and understand the whole procedure while still lacking an intermediate operation needed to connect them. Practise that operation or obtain its performance from a capable participant, then return to the whole task. A.22.CGUS keeps these capability and resource conditions visible when judging an available continuation. Earlier completed work can supply a needed result without being enacted again now.

Extractable structural information is a reader-relative characteristic of a publication, assessed for the intended reader's preparation and available budget. It applies, for example, to a pattern's text, an explanation in a guide or an architecture description. Epiplexity formalizes structural information extractable from data by computationally bounded observers (Finzi et al., §3); C.29:4.2c governs the use of that mathematical lens. A.6.3.NAR supplies the source-to-narrative relation for narrative publications. What counts as an improvement depends on the named object and intended use.

#FPF.Preface:14 - Boundary Statements

Most of the time, teams can use fast compressed speech. "The service guarantees it." "The model is synced." "The dashboard proves it." "The interface is stable." "The process is compliant." In ordinary conversation, people often infer enough to continue.

That changes when the sentence crosses into an API, contract, safety case, evaluation protocol, dashboard used for commitment, SLO, SLA, compliance text, model card, dataset sheet, reproducibility checklist, or operational gate. At that point language is not merely communication. It can become system-relevant.

The danger is that one sentence may try to do several jobs at once:

• define a term or condition;
• say what a mechanism admits;
• assign a commitment or permission;
• claim evidence or work effect;
• publish a view or decision;
• move responsibility across a boundary.

If those jobs remain bundled, the sentence becomes hard to check. Later disagreement is then resolved by authority or politics rather than by the pattern that defines or constrains the claim.

FPF's boundary discipline, especially around the A.6 family, repairs such cases by separating claim kinds. A contract line, interface statement, API schema, compliance note, or safety-case sentence can be unpacked into definition, admissibility, commitment, evidence, work effect, publication, and decision components as needed. The point is not to force every document into a heavy form. The point is to keep boundary language from changing system behavior without an inspectable claim.

#FPF.Preface:15 - Raising Semantic Precision

FPF does not expect people to start with perfect terminology. Early thinking is often compressed, metaphorical, and useful. That is not a failure. It becomes a problem only when the compressed phrase begins to govern action, evidence, architecture, publication, decision, work, assurance, or mathematical modeling.

FPF therefore provides a semantic precision upgrade path:

1. Notice the wording that is doing too much. Broad heads, pronouns, metaphors, status words, level words, support words, function words, architecture words, and evidence words often signal a hidden claim.
2. Recover the project entity under concern, relation, claim, or project-side source-use relation being made.
3. Recover the ontology before changing the word. Name the kinds, slots, context, viewpoint, time, evidence, and use that matter.
4. Use mathematical modeling or a formal signature only when it helps. FPF calls these a math lens or formal substrate when a graph, order, signature, state space, topology, probability model, or variational principle makes the structure reviewable. Mathematics is not decoration.
5. Rewrite the wording as a plain reader line and, when needed, technical fields so the practical point remains readable and the claim remains checkable.
6. State what can now be done, what remains blocked, and which pattern defines or constrains a different claim.

This is why E.10 is a trigger scan rather than a synonym list. E.10.ARCH distributes repair to the pattern that can recover the ontology. A.6.P, C.2.P, C.16.P, C.16.Q, C.30.P, A.19.SPR, A.6.F, F.18, and F.19 carry major repair families. C.29 helps when a mathematical lens is needed. A.6.0 governs formal-substrate declarations when a formal signature is the right object.

The success condition is not "the text now sounds precise". The success condition is that after removing overread, the working reader still has a useful move: use the claim within its declared limit, repair it further, apply the related pattern that defines or constrains the remaining claim, or block the claim until the missing record, relation, evidence, or subject-pattern application is supplied.

#FPF.Preface:16 - Big FPF Storylines

FPF connects ways of asking a question, developing an answer, testing its support and using it in further work. The connection matters when one sound local result leaves the next participant unable to act: the measurement concerns a different population, a candidate needs unavailable support, or a useful explanation omits the condition under which it holds. Start with that receiving question and use only the contributions needed to answer it.

#FPF.Preface:16.1 - Follow one question through several contributions

When a question, surprising result or promising construction leaves the next useful reasoning contribution unclear, use B.5. State what an answer should let its recipient understand or do. If an available result already suffices for that use, return it and stop. Otherwise, identify and obtain the missing contribution, explain what it establishes for that use, and return the result with its conditions and limits. Continue with a further question only when its possible answers could change understanding or action and investigating it is worth the cost. If no question has yet been recognized, use B.5.PI on an ordinary work occasion, such as a handover, demonstration or explanation.

Consider a constructed example. A team is deciding how to help engineers review technical reports. A purchased assistant and a locally operated assistant remain candidates. The local candidate appears faster on the small set tried so far. The current question is whether that is enough to begin relying on the proposed review arrangement.

Use C.16 to make the reported speed interpretable: which reports, which part of review, which assistance, which result, and which uncertainty does it cover? A time for extracting passages leaves open the time for checking their relevance and correcting errors. Use B.3 when the next decision needs an assurance answer: what exact claim does that trial support, what could defeat it, and which reports or operating conditions remain outside its basis? If the trial omitted reports containing tables, retain its result for the tested class and identify the table-handling limitation. That missing comparison becomes a probe proposal only when the receiving choice and attainable contribution warrant the inquiry.

The proposed arrangement also needs extraction, independent checking and final release review. Suppose their estimated weekly demand on the same engineer is respectively 3, 8 and 4 hours, while only 10 hours are available. The estimates apply to the same workload and the hours cannot be shared between these activities. Each activity fits individually; together they require 15 hours. The useful whole-arrangement result is a five-hour shortfall. The team can reduce the workload, provide additional qualified capacity, or change the arrangement and compare again. A better extraction time alone does not close that resource condition.

B.1.5 becomes relevant if the team is also designing these contributions as one reusable Method: it asks how the part Methods, preconditions, results, order and failure handling make the whole action possible. For the present capacity question, the explicit workload and resource comparison are sufficient. The sequence written in a proposal supplies no additional evidence that the arrangement works.

With these two candidates and the missing table-handling comparison, use C.11 when the team must decide whether another bounded probe is worth its cost before choosing. The proposed probe must be able to change that choice; the current candidate descriptions and qualified results remain available. A different question arises when the team needs a continuing research archive, a front or generation of further possibilities: C.18 then supplies that contribution. Use C.19 when the team must decide or reassess the exploration or exploitation policy for its still-live pool, such as the allocation of effort across several continuing lines. The local choice can proceed directly when neither of those broader questions is current.

This example ends with three usable results: a qualified reading of the existing speed result, an explicit five-hour capacity shortfall, and a specific missing comparison. It leaves the deployment decision open. A later addition of qualified capacity changes the resource conclusion; a failure on tables changes the affected claim about report handling. Neither event erases the result on the original report class. This is how a reader can combine FPF contributions and then reopen only what a changed premise affects.

Inquiry can stop earlier. A laboratory may need to explain why several performances differ before it has any preferred intervention. A.3.1.MR helps recover a candidate reusable way from the performance evidence; a counterexample can leave the candidate unresolved and identify what to observe next. The useful result is then a sharper hypothesis and discriminating observation. Choosing or deploying a solution becomes current only when the research question and evidence make that next move useful.

#FPF.Preface:16.2 - Architectural Rationale

The organization supports several useful scales. A practitioner may apply one pattern, use several contributions together, or develop a recurring domain Method described by many patterns. A professional DPF supplies the domain difficulties, mechanisms, evidence and judgement; a local LPF supplies the arrangements of a particular practice. A narrower profile can reuse several broader contributions and explain its changed conditions. Further useful narrowing remains possible. Pattern reuse, Method composition, specialization and publication grouping therefore need their own stated relations. The depth of a heading or the number of patterns gives the reader no substitute for those explanations.

An individually addressable pattern lets a reader inspect the Problem frame and Solution at the point of need. The whole account explains the connections, shared conditions and reasons that would otherwise have to be reconstructed from many bodies. The two scales have different reading costs: a direct answer is cheaper for one familiar question; the broader explanation helps when a reader must adapt the arrangement or understand why several local answers fail together. E.11.PUA supports the selected direct use and E.11.PUR the current choice or coordination among uses.

A single prescribed project sequence is a serious alternative when the same regulated or reproducible procedure must be followed repeatedly. FPF instead keeps the contribution structure open to direct entry because research, engineering, operations and management repeatedly need different first results. A local practice can select a required procedure and its assurance conditions. A.11.OP screens additional mandatory actions for contribution to a real decision, selected result or relied-on assurance/recovery condition. A contribution alone does not justify the demand's cost or establish its force; the applicable choice, advice, assurance or authority method completes that question.

A shared vocabulary alone is another useful alternative when classification is the entire problem. FPF pairs the distinction with the difficulty, usable move, evidence and limits because a team usually needs to do something with the classification. A collection of independent best-practice summaries is cheaper to assemble, but the receiving user must then reconcile their meanings, assumptions and result uses. FPF makes those relations explicit where that reconciliation changes action. When one existing domain Method already answers the question sufficiently, use it directly; the benefit of an additional FPF contribution must exceed its reading and coordination cost.

This architecture also explains the separation between descriptions and their subjects. An alternative can be considered before it is realized; the same Method can be described in prose, diagrams or another suitable medium; several views can answer different questions about the same system. A.3.2 governs an exact MethodDescription claim, and the E.17 family governs the relevant view and publication uses. This allows a representation to improve without treating every publication change as a change to the described Method or system.

#FPF.Preface:16.3 - Shared sources and the choices they support

FPF uses source traditions for particular answers and states the adopted contribution in the subject pattern. The following connections explain why several families work together. The direct bodies retain the precise source editions, stronger technical conditions and refresh triggers.

Constructional ontology contributes a demand to explain constituents, construction and identity. A.1 adapts Florio and Linnebo's construction-sensitive account and the applied choices discussed by Borgo and Righetti; it keeps part relations and whole recognition explicit instead of importing an external category system wholesale. B.1.5 carries the corresponding question into Method composition and also adapts scoped-effect and protocol work: usable joins depend on preconditions, order, boundary interactions and failure routes. This combination helps a reader test a proposed whole while keeping its diagram and description separately inspectable.

Measurement and assurance supply different parts of an evidence-based answer. C.16 adopts the JCGM VIM result boundary and adapts GUM measurement-model discipline so that the reported value, relevant information, assumptions and uncertainty can be recovered. B.3 adapts the claim-argument-evidence structure of ISO/IEC/IEEE 15026-2 and GSN to the particular reliance question. Its dependence-sensitive calculation also rejects a universal weakest-link arithmetic. Together they let the report-review team ask both what a time value means and how far the trial supports the proposed use. The measurement source supplies no release authority; that question has its own participant and governing rule.

Open-ended search and sequential decision research explain why exploration is kept beside assurance. C.18 uses quality-diversity research to distinguish retained alternatives, current fronts and generation of further possibilities; its source account states the limits of inferring useful exploration from archive occupancy. C.19 draws on bandit and Bayesian-optimization work for explicit cost, uncertainty and policy-change pressures. FPF keeps those contributions while leaving the actual algorithm and domain evaluator to their justified use. An attractive archive or one high novelty value does not establish the usefulness of the next experiment.

The synthesis is use-specific: construction explains what whole is proposed, measurement makes a relevant observation interpretable, assurance qualifies reliance, and search preserves alternatives or asks for another result. A successor source matters when it changes one of those answers. G.11 returns the affected use to that source; E.19 and E.23 support preservation and improvement of the resulting pattern content. This lets stronger knowledge change the framework without requiring every unaffected practitioner result to be obtained again.

#FPF.Preface:16.4 - What to examine when adapting the arrangement

For a combined use, ask whether the outputs still answer the receiving questions, whether shared workload and resource assumptions are compatible, which missing premise changes the result, and what remains usable if that premise changes. Keep the whole-set condition where that combination is explained and use the relevant direct pattern for its technical test. The 15-hour example shows why locally acceptable contributions can still require a different joint decision.

The examples here assume readers who can supply subject expertise and recognize relevant evidence. A fluent assistant or an experienced engineer can conceal missing explanatory support that a new learner needs. The reader can use a bounded walkthrough to test recoverability of an answer; claims about learning, retention or transfer require observations suited to those claims. Likewise, engineering and software source examples indicate particular contributions; applicability in a laboratory, organization or other setting depends on its own mechanisms and evidence.

Using the arrangement costs attention and, when later reliance needs them, addressable source and result records. Its practical gain is that a new participant can find why a result was used, what it enables and what would change the answer. Stop when the current question has that useful answer or an explicit missing premise. Keep unresolved questions available for later inquiry rather than adding a pattern use merely to complete a familiar sequence.

#FPF.Preface:16.5 - Construct a usable whole with existing methods

Use this account when useful contributions are available but the intended whole cannot yet be obtained or used. This occurs in practical design and when an author allocates a source's construction to familiar patterns but loses the instructions that connect their contributions. Identify the next missing result, obtain it through the relevant subject method and return it to the use that required it.

The account assumes enough subject knowledge to recognize the required result and judge whether a proposed contribution fits. Obtain subject assistance when that knowledge is missing. If one known method already answers the question, use it directly. The explanations below help select and combine contributions; they do not supply every engineering method or domain ontology.

Semantic synthesis develops claims and distinctions: what the relevant objects and relations are, how source accounts can be compared, and what remains unresolved. Methodological synthesis constructs ways of acting and their material relations: how to obtain and use results, under which conditions, and where to return when an operation fails or its result cannot be used. They can develop together. Distinguishing assistance from a performer's own capability can change the method; attempting the method can reveal that this distinction was missing. Use F.0.2 for source-ontology comparison and C.39:4 for general construction, connection, explanation and change of Methods.

One account can explain composition within a Method and relationships among independently usable Methods. C.39:4.3–4.6 develops their connections for an ordinary practitioner: distinguish composition from enactment, reuse from generality or refinement, and cross-domain use from those relations; explain result uses, independent branches and what a changed condition reopens. E.4.CM applies this general foundation to framework authorship and public pattern form. C.32.MWA supplies an architecture account of Methods together with their performance, support and development. Neither a single “stack” nor FPF→DPF→LPF supplies all these relations.

The two worked cases use stipulated facts and numbers. One presents a partial comparison of night-service options and requirements for a conditional external arrangement; the other derives an assessment from measurement inputs. They show conditional reasoning, including what changes when a consequential input changes. A real project requires its own inputs and evidence.

#FPF.Preface:16.5.1 - Start outside the proposed boundary

State the use for which the whole is needed and the result that would make a difference there. Identify the relevant recipient and affected parties. Ask what must remain true when the result is used. This helps determine what belongs to the proposed whole and which outside contributions it requires. A missing contribution may require a new provision or a changed boundary.

The outside question need not identify a containing system. A pump belongs to an installation; a claim about that pump concerns it; a decision uses the claim. These are different relations. First looking outside is an order of justification, not a rule that every project starts its work in that order. When an available invention initiates the inquiry, look for a useful occasion, then test the invention against the conditions of that occasion.

Choose what must be obtained now. A usable assessment, a proposed service arrangement and an operating service have different completion conditions. A proposed arrangement can be the complete answer to a design question while leaving the original service need unmet. Keep that larger need visible when returning the smaller result.

#FPF.Preface:16.5.2 - Recover the construction and select the next operation

When a source already supplies a construction, recover its whole before allocating its components: what it tries to achieve, what is connected, how the connections work, and where it returns when a premise fails. Retain distinctions that change the operation even when all the component ideas have familiar names. When sources give different accounts of the same objects or relations, state the difference and determine whether it changes the receiving operation, its assumptions or permitted use. Keep consequential alternatives separate until an applicable subject comparison justifies their combination or selection. Shared terminology alone does not settle that question.

Useful methods can also have arisen independently, with no source that already explains their joint use. Start from the receiving difficulty and develop the missing connections through C.39:4.3–4.6. For a framework publication, E.4.CM:4.1–4.7 applies that construction to its readers, public owners and pattern form. Recovering a source's ready-made assembly is one entry, not a prerequisite.

Attempt the intended use with the contributions available. Locate a required result that the next operation cannot yet use. State that operation, who performs it, what it needs and what is supplied instead. For night response, diagnosis needs an available qualified operator; the explanation describes a conditional response calculation. For pressure assessment, comparison needs absolute pressure values with their uncertainty; the record supplies a gauge reading. These failures select different work.

Ask which change would make the supplied contribution usable. If a clear explanation would still leave the operator absent, explanation is not the missing contribution. If an applicable measurement record already exists but its indication has not been interpreted, taking another measurement may add work without settling the comparison. This test distinguishes an unavailable contribution from an unavailable description or interpretation of one.

Select an available pattern that teaches how to obtain the required result. Read its working situation and operation, rather than choosing from a shared word such as “connection”. In the two applications:

• C.16 recovers the measurement subject, reference, model and uncertainty. Use the measurement model to determine which values fit the indication and whether they settle the receiving question. The pressure example below performs the necessary interval calculation and threshold comparison in full.
• C.38 develops comparable ways to obtain the same result; C.11 governs the subsequent choice when the comparison is ready. Their results are a comparison and a choice, not an available service.
• A.15.9 helps use or request one bounded result from another practice, such as a qualified assessment of a proposed response time. It does not govern obtaining continuing provision. The night-service case specifies what the service owner must obtain before selecting and relying on a service; it does not supply the required procurement and operating methods.
• C.2.1 identifies the resulting episteme through its claim content, entity of concern and reference scheme. Its constitution distinguishes that result from the measurement Work and the pump about which the claims are made.

These patterns supply parts of the two applications; the night-service case also exposes a missing way to obtain and operate the service. Another subject requires its own selection. For a missing physical connection, identify the required behavior and participants, then use the relevant engineering method or obtain that operation from a capable provider. A.1.STM can help reconsider the system boundary and outside use, but does not supply every physical design. C.39 develops a missing obtaining way or connection at the needed scale. E.4.CM applies it when the result must become a developed framework explanation. Do not replace the immediate question of obtaining provision with the larger task of describing every provider Method.

Perform the selected operation and return its result to the operation that needed it. A proposed contract can settle a terms question while leaving service provision absent. A resolved pressure comparison can inform a release decision while leaving its other requirements open. If the result still cannot be used, locate the remaining condition and repeat only the affected work.

If a source disagreement still changes which construction would be usable, return the bounded semantic-comparison question to F.0.2. The two applications below do not supply that reconciliation. If no existing method or competent provider supplies the needed operation, retain the precise gap and use C.39 when further construction can change the answer. Use E.4.PFAD when the unresolved question concerns the resulting framework contribution or its placement. A recurring operation absent from the available suppliers can justify a new contribution; an unfamiliar combination of already sufficient methods does not establish that absence.

The table distinguishes several results a practitioner can seek and the completion conditions that change their use.

A design description is knowledge about a proposed System, whereas realizing that System requires its constituents and relations to obtain. An ontic description states the distinctions between objects and the relations required by its modeling question. Naming several concepts is insufficient when their relations carry the explanation. For a larger ontic description, use the definitions and relation rules of its subject; this pressure example supplies only the distinctions required for its assessment.

The activity of constructing an episteme can itself employ several Methods. That fact does not make the resulting episteme a composite Method. Likewise, describing a service arrangement produces knowledge about it; the description does not supply its staff or perform its service.

#FPF.Preface:16.5.3 - Compare constructions and return to use

When several ways of obtaining the same result need comparison, use C.38 to develop complete-enough alternatives on the same basis. A familiar label such as internal provision or automation does not yet describe such a way. Preserve unknowns that could change the comparison; return a missing alternative when no second way can be developed. Use C.11 for the resulting choice when its comparison basis is ready. A narrower result is an alternative only if the receiving need can be changed with its consequences made explicit.

For each required contribution, check that its result, meaning and conditions fit the operation that uses it. Return the resulting whole to the outside question. If it cannot yet serve that use, say what is available and which precise dependency still blocks the remainder. Retain useful partial results without calling the larger need fulfilled.

Then change one consequential condition of the whole. Determine which constituent, relation or boundary must change; preserve the contributions whose premises still hold. This is reciprocal reasoning between the whole and its constituents. It neither assumes mathematically reversible operations nor turns every change of level into a Meta-Holon Transition.

C.39:5.3 works this return across several Methods without requiring framework authorship. Preparation supplies a qualified recording to movement analysis and demonstration viewing. A tighter analysis tolerance requires another correction method, while the previously qualified viewing use remains available. The case explains composition within preparation and result-use and development relations among independent Methods. E.4.CM:5.4 then shows what framework authorship adds: a shared public explanation, its content functions and placement, and direct returns to its suppliers.

#FPF.Preface:16.5.4 - Explanation and night coverage

#FPF.Preface:16.5.4.1 - Recover the receiving result

An engineer explains a reduction in response time from eight to five minutes, conditional on an operator being present. A colleague asks about night coverage, when no operator is present. Preserve the conditional explanation. The next useful contribution is a way to obtain the required night response, rather than another explanation of the same calculation.

For this worked example, define the operational requirement as follows: a qualified, authorized operator must start the applicable mitigation within five minutes of alarm detection during the seven nightly eight-hour windows. The requirement concerns the start of appropriate mitigation, not resolution of every incident. It applies to the declared incident class and at most one incident at a time. These added conditions make comparison possible; a real practitioner must obtain their actual counterparts from the service need.

#FPF.Preface:16.5.4.2 - Compare proposed ways to meet the need

The nightly windows require 56 hours of coverage per week. Qualified members of the internal team can cover 12 of those 56 hours without conflicting with their other assignments. It therefore leaves 44 hours uncovered. Rewording the request cannot fill those hours.

Assume an external provider offers all 56 hours for 600 units per week, within a budget of 800. The proposed service includes a qualified operator and replacement coverage. For the declared incident class, its proposed serial bounds are 0.5 minutes for alarm delivery, 1 minute for the operator to take responsibility for the incident, 1.5 minutes for diagnosis and 1 minute to start mitigation. Their sum is 4 minutes. These are offer terms to verify, not observed performance; the one-minute margin does not establish reliability or cover simultaneous incidents.

The existing automation can route an alarm but cannot select and start the required mitigation within its current authorized function. A day-only promise would be cheaper, but the stated receiving use requires night coverage. These are consequential reasons for rejecting those alternatives in this case, rather than preferences for a provider.

The comparison is unfinished. C.38 exposes the missing internal way: who could cover the other 44 hours, with what replacement, response capability, assignments and full cost? The external offer also leaves setup, verification and continuing owner work to qualify. Those contributions could change the comparison. The service owner must obtain a sufficient basis before C.11 can settle a service choice. The following paragraphs develop the external candidate conditionally; they do not report that choice or an acquired service.

#FPF.Preface:16.5.4.3 - Specify the missing procurement and operating results

Before choosing, the service owner needs an adequately supported external proposal. It must identify the covered hours, response obligations, full cost, replacement and withdrawal conditions, the provider's required access, and who can authorize and make the proposed commitments. These details must support comparison with the internal way under C.38 and the subsequent choice under C.11.

That proposal is still missing. No procurement method or qualified provider result that establishes it is supplied here. A.15.9 can help request a bounded specialist result, such as an assessment of the proposed response time; it cannot supply the missing procurement operation.

After a supported choice and agreement, the service owner needs qualified staffing and replacement throughout the covered hours. Alarms must reach the responsible operator in an interpretable form, the current configuration must be accessible, and the operators must have authority for the permitted mitigation. Verification must provide evidence that the connected response meets the stated requirement. No service-operations method or qualified provider result supplying this provision is given in the case. The connections below specify requirements for that missing contribution. A technical operator who explains the mitigation may lack authority to purchase the service or permit operational access.

Connect alarm detection to delivery, delivery to the operator taking responsibility, diagnosis to the applicable mitigation, and the provider's report to the service owner's verification of the response. Preserve the time origin and incident identity through those connections. A receipt alone proves only receipt. The verification exercise must test receipt, configuration access and use of the replacement operator as well as the nominal serial path. Its coverage of actual incident conditions must be stated; a single successful exercise does not demonstrate every future occurrence.

Before authorizing the arrangement, examine a relevant consequence outside the immediate service team. Suppose the original night alarm would wake residents who cannot participate in the purchase discussion. Their exclusion from that discussion does not remove the consequence. The candidate uses silent delivery to the responsible operator instead, provided that the changed channel can deliver and be noticed within the required conditions. If it cannot, the arrangement needs another change.

#FPF.Preface:16.5.4.4 - Return the result and its remaining conditions

The worked result is a partial comparison and requirements for a conditional external arrangement. Before a choice can be supported, the service owner still needs an adequate proposal and a complete enough internal alternative. The first subject-domain gap is a way to obtain and qualify that proposal. After a supported choice and agreement, staffing, working access, authority and operating evidence would still have to be established before anyone could claim night coverage. For framework development, carry these two missing operations and their required results into E.4.PFAD's decision about an existing or new subject-domain contribution. The original conditional daytime calculation remains valid.

Once the comparison has supported a choice and the selected arrangement has the required commitments and operating evidence, the owner can decide whether to rely on the night service at the stated scope. Communication then conveys the qualified result and its remaining limits. Understanding, commitment, acquired capability and observed response remain different outcomes along this construction.

Change the whole condition to two simultaneous incidents. The offered bounds apply only to one. Do not keep the five-minute claim by adding another explanation: compare parallel provision, a second authorized responder, a justified prioritization with a changed service promise, or an unmet requirement. Retain the verified meaning of the alarm and each applicable diagnosis; reopen concurrent capacity and its implications for time, cost and authority.

#FPF.Preface:16.5.5 - An interpretable pressure assessment

#FPF.Preface:16.5.5.1 - Recover the pressure question and its inputs

An engineer needs a pressure assessment for a decision about pump P17: does the available information establish that its pressure, in the stated configuration and operating regime, is at or below a 300 kPa absolute limit at the measurement occasion? Other conditions and authority for releasing the installation remain separate.

Assume three source contributions. A model manual states the absolute pressure limit. A configuration record establishes that this limit applies to P17 in the regime being considered. A measurement record reports 195 kPa above the local atmospheric pressure, with an error bound of 5 kPa; local atmospheric pressure is 100 kPa absolute with an error bound of 2 kPa. For this illustration the bounds are enclosing intervals under the stated conditions, not confidence intervals. The records are assumed applicable to the same regime and measurement occasion.

Use C.16 to recover the measurement subject, reference and uncertainty. Here the addition relation is available, so an interval calculation can determine what comparison the supplied bounds resolve.

Extracting two numbers called “pressure” would lose the difference between gauge and absolute reference. Retaining all three documents as a bibliography would leave the comparison unperformed. The construction needs the applicability connection, the pressure reference and the calculation consumed by the decision.

#FPF.Preface:16.5.5.2 - Form and interpret the pressure assessment

Keep P17 as the entity the resulting assessment concerns. State the regime and measurement occasion as conditions of its claims. The reference scheme uses kPa, an absolute pressure datum, the relation between gauge and absolute pressure, and the meaning of the stated bounds. The claim content includes the applicable limit, the converted pressure interval and what follows for this comparison. The manual states the limit; the configuration record states its applicability to P17; the measurement record supplies the indication and uncertainty assumptions; the calculation derives the comparison from those premises.

For these readings, absolute pressure equals gauge pressure plus local atmospheric pressure: p_absolute = p_gauge + p_atmosphere. Apply that relation to the stated intervals:

• gauge pressure lies in [190, 200] kPa;
• atmospheric pressure lies in [98, 102] kPa absolute;
• absolute pump pressure therefore lies in [288, 302] kPa.

For a conservative enclosing interval, adding lower endpoints and upper endpoints requires no independence assumption. It does require the stated intervals and addition relation to apply together. The stipulated relation admits the central values, which give 295 kPa absolute. The enclosure's upper endpoint exceeds the limit while its lower endpoint does not. This enclosure therefore establishes neither compliance nor a violation. Distinguish an enclosure spanning a threshold from two feasible cases with different answers: the enclosure alone leaves the threshold question unresolved, without proving that both outcomes are possible. Comparing only the central value of 295 kPa with 300 kPa would lose the reason the uncertainty matters.

The resulting episteme is a coherent answer: under these inputs, compliance is unresolved. It tells the decision-maker what cannot be concluded and why. It is useful even though it does not authorize operation. A measurement that narrows the pressure interval enough to resolve the comparison, a changed operating regime, or a governing decision that permits reliance under residual uncertainty are different next possibilities. Such a decision must identify the uncertainty it permits and the scope of that permission; this example supplies no authority to make it.

#FPF.Preface:16.5.5.3 - Change the input and retain the applicable reasoning

Suppose a later applicable measurement keeps the same central readings but bounds gauge error by 2 kPa and atmospheric error by 1 kPa. The new absolute interval is [292, 298] kPa. Its upper endpoint is below 300 kPa, so the stipulated information now supports the pressure-limit comparison for this regime at the later measurement occasion. Actual release can still require other conditions that this assessment never claimed to decide.

The assessment still concerns P17 under the stated regime. Its unit, pressure reference and applicability rule remain, while the later measurement changes the input, derived interval and threshold conclusion. The engineer reuses the conversion relation and comparison rule and updates the affected claims. C.2.1 distinguishes the assessment's claim content and reference scheme from the pump those claims concern. To ground the assessment in an installation, the records must refer to applicable measurements of P17, and the calculation must warrant its claims from those measurements. The stipulated inputs here illustrate the inference without establishing that measurement relation or installation-side grounding. The assessment informs the release decision; its other conditions and authority remain separate.

#FPF.Preface:16.6 - Develop a useful way from received material

A practitioner may receive a chapter, paper or discussion before knowing which of its ideas deserve adoption. Begin with what the material could help someone do or understand. Follow a proposed result into its receiving use and recover what the source actually supplies. B.5.PI makes that ordinary occasion available without requiring a known error; B.5.RC helps recover a construction, and C.39:4.2–4.6 develops the way needed by the receiver. An adequate direct answer can finish the work.

For example, a historical discussion connects proposing an action, exposing its reasons to criticism, revising the proposal and taking the outcome seriously. C.39:5.4 follows that material into an instruction for examining a proposal and deciding how to continue. It preserves the constructive connection while distinguishing a useful proposal from an action whose necessary conditions and grounds have been established. Recovery begins with the source's constructive proposal; following its application exposes a question about the grounds for action.

Source interpretation, development and evaluation contribute different results. F.0.1 can settle what a consequential passage means; F.0.2 compares source accounts when their difference changes the receiving claim. C.39 constructs and explains the missing operation or connection. A.10 qualifies reliance on the claims actually used; C.11 makes a choice among available continuations. E.22 asks what the evaluation must establish for that use, and A.19.ECS is needed when no adequate evaluation exists or an actual failure warrants developing it. Start at the contribution whose inputs are present. This account does not require applying every listed method.

The distinction between Kernel and broader Core has a practical consequence here. The definitions of Episteme, Method and Work keep a source claim, a proposed way and a performed action apart. Those definitions alone do not construct the instruction: general Methods such as C.39 supply that work. Domain Methods and evidence supply the particular operation and its conditions. E.4.CM adds the framework author's publication work only when the resulting contribution is to be maintained in a framework.

A Preface or Reference can explain how independently useful contributions meet in this situation. Their direct bodies retain the reusable operations and governing distinctions; an appropriate DPF retains its domain contribution. A short entry can point to the connected explanation. This provides a smaller return path for a familiar use while leaving the reasons needed for adaptation accessible.

Evaluation follows the same receiving use. A good summary and good constituent patterns are evidence for their own questions. To judge whether the reader can obtain the promised result, examine the connecting explanation and its application on the material, including necessary support. E.22:4.3 and its source-to-method example show how to frame that question without changing the meanings of the constituent scales. A supported conditional next inquiry can be a useful complete answer to an inquiry-selection question; it does not fulfil a request for a performed intervention.

Finally, change a premise that one application actually uses. In C.39:5.4 a tighter timing requirement reopens the movement-analysis proposal while demonstration viewing can retain the same prepared recording under its unchanged conditions. Follow the relevant claim and result use, update the explanation that the receiver needs, and preserve what the change does not affect. Separate publication units can help obtain the right explanation; only the semantic dependency determines which conclusion needs reconsideration.

Conceptual compactification here keeps a developed connection available for reuse, together with the distinctions and reasons needed for application and change. Its effect on a particular reader's effort, acquired capability or work result remains a question for observations under that reader's actual conditions.

#FPF.Preface:17 - Transdisciplinarity As A Meta-Theory Of Thinking

Modern complexity lives at the junction of traditions. A manufacturing engineer, software architect, safety engineer, finance analyst, ML researcher, and operations manager may use the same words for different project entities and different words for the same project entity. They may also use different forms of proof, different measures of quality, and different standards for acting.

FPF treats transdisciplinarity as a meta-theory of thinking. It is not a new specialist dialect that replaces local traditions. It is a way to design reasoning across traditions while preserving local meanings.

The key move is local-first meaning. A term belongs to a context before it travels. A term sheet can align senses, but it does not erase their local differences. A bridge can say how meanings correspond, where they lose structure, and what cannot be transferred. A comparison can compare candidates, but only under declared characteristics and evidence minima. A mathematical lens can reveal shared structure while stating what it preserves and what it loses.

This is how a single framework can help in architecture, biology, manufacturing, AI-agent systems, safety assurance, management, education, and research without pretending those domains are the same. FPF does not flatten domains. It gives them governed interfaces for reasoning together.

#FPF.Preface:18 - The Culinary Architecture Of Collective Thought

Many FPF ideas sound familiar. Evolution, exploration and exploitation, evidence, roles, boundaries, architecture, comparison, naming, and improvement are not new ingredients. A thoughtful reader may ask why FPF formalizes so many "obvious" ideas.

The answer is that FPF is not trying to invent the ingredients. It is trying to build the kitchen.

A domain methodology is like a cookbook. It gives excellent recipes for a class of dishes: software delivery, scientific experiment, safety case, product discovery, architecture review, or policy design. A skilled practitioner can often cook one dish beautifully from experience alone.

FPF is closer to the architecture of a professional kitchen. It gives places, instruments, roles, interfaces, checks, and repeatable forms so many dishes can be prepared, compared, improved, and served without chaos. The value is not that flour or heat are new. The value is that ingredients, techniques, stations, timing, quality checks, and presentation can work together at scale.

In FPF terms:

• system-role kinds distinguish recurring work-facing contributions, while system-role assignments identify which systems are assigned to them;
• methods and method descriptions separate how action can be performed from the document describing it;
• work patterns keep actual change distinct from plans;
• evidence and assurance keep proof and reliance inspectable;
• characteristic spaces define what quality means for the object at hand;
• architecture patterns keep structure distinct from diagrams;
• naming and term sheets let people talk across contexts without semantic collapse;
• state-of-the-art and option portfolios keep search open before selection;
• improvement loops let the whole arrangement get better over time.

For a small well-known problem solved by one expert, FPF may feel heavier than intuition. Its advantage appears when reasoning is collective, long-lived, high-stakes, cross-domain, AI-assisted, or open-ended. That is where tacit expertise alone becomes hard to audit, transfer, or refresh.

FPF does not replace expert judgment. It gives expert judgment a shared architecture so it can compound rather than evaporate.

#FPF.Preface:19 - The Intellect Stack As A Pedagogical Map

The phrase "Intellect Stack" names a learning map of capabilities. In this specification it is pedagogy, not a prescribed sequence or a new ontology.

The point is simple: complex reasoning usually needs several capability families, and teams often underinvest in one of them.

This stack is not a universal project sequence. It is a way to notice missing capability. A team may enter through architecture and discover that it lacks evidence. It may enter through naming and discover that it has not named the project entity under concern. It may enter through mathematical modeling and discover that it lacks declared characteristics for comparison.

The learning value is that FPF can be taught as a set of capabilities, not only as a list of pattern ids.

#FPF.Preface:20 - Purpose, Scope, And Non-Goals

FPF's purpose is to help people and AI agents produce reasoning that survives use: reasoning that can be aligned, reviewed, improved, published, delegated, refreshed, and reopened without losing the EntityOfConcern it was about.

The Core Specification defines conceptual patterns, distinctions, publication forms, and checks. It is tool-agnostic. It does not prescribe a software stack, file format, repository layout, meeting style, workflow engine, or organizational method. Those may be useful in a project, but they are not the conceptual core.

FPF also does not replace domain expertise, evidence, mathematics, standards, or local judgment. It gives them a disciplined place in reasoning. A domain expert still knows the pump, reactor, contract, model, laboratory, organization, or market. FPF helps the expert's reasoning become inspectable, comparable, and evolvable across contexts.

FPF's non-goals are short:

• it is not a domain encyclopedia;
• it is not a universal procedure sequence;
• it is not a prompt collection;
• it is not one mathematical doctrine;
• it is not a license to turn every project into paperwork;
• it is not a substitute for evidence or accountability.

Its positive scope is broader than those refusals. FPF is a compact language for keeping hard work honest enough to act on and alive enough to improve.

#FPF.Preface:21 - How To Continue After The readme

Start with the readme when you are deciding whether FPF can help a working project. Read this Preface when you want the ideas that make the first practical entries fit together. Use the Table of Contents when you need to locate a pattern family. Then use the direct pattern body whose Problem frame and Solution govern the claim, relation, publication use, architecture, evidence, decision, work, name, mathematical lens, option portfolio, or improvement object you actually have. Begin with its action- or judgement-guiding content; recover a MethodDescription, admitted Method, or exact ClaimGraph only when the current claim or named reliance needs that distinction.

Do not read the specification linearly unless that is your study goal. In project use, the first useful FPF pattern family is selected by the working question.

The main practical habit is this: when a project sentence starts to matter, ask what kind of entity, relation, record, or claim it is talking about, what assertion it makes, what can responsibly be done with that assertion, and which pattern description contains the action- or judgement-guiding rule content needed next. Recover an exact Method, predicate, or ClaimGraph only when that distinction changes the truth, action, stop, or named reliance. That habit is small. The architecture behind it is the rest of FPF.

#FPF.Preface:End

---

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