#Thinking-Oriented Architecture, Not A Descriptive Upper Ontology

Preface node heading:thinking-oriented-architecture-not-a-descriptive-upper-ontology:857

#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 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 thing is under concern in this project moment;
• what claim, relation, decision, evidence path, work object, or publication use is being made;
• what distinction must remain visible for action to be responsible;
• what pattern can govern the next move;
• 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 kinds of things. 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.

---

Last Updated: 2026-06-08 — upstream FPF commit 093d30e8 (github.com/ailev/FPF)