Function-Behaviour-Structure ontology¶

The Function-Behaviour-Structure ontology represents a designed object through what it is for, what it does, and how it is constituted, and models designing as transformations among those three views.

Version: v1 · 2026-09-28 · History
Domain-specific #: 9585
Domain group: Applied Sciences & Engineering
Origin domain: Engineering & Design (beyond software)
Subdomains: Design Theory, Design Science → Engineering & Design (beyond software)

Core Idea¶

The Function–Behaviour–Structure (FBS) ontology represents a designed object through three related categories: function is what the object is for, behaviour is what it does or the measurable attributes through which purpose is realized, and structure is the components and relations of which it consists. Function is linked to structure through behaviour rather than mapped directly. A turbocharger's function may be to increase engine power; expected behaviours include target air-flow and efficiency characteristics; its structure includes compressor, turbine, shaft, geometry, materials, and interconnections. This separation prevents a desired purpose from being mistaken for either observed performance or a particular embodiment.

In the associated FBS design framework, requirements are interpreted into functions and expected behaviours. Synthesis proposes a structure expected to realize them. Analysis derives actual or predicted behaviour from that structure. Evaluation compares derived with expected behaviour. Documentation produces a description of the structure, while three kinds of reformulation revise structure, behaviour expectations, or function after the designer reinterprets what has been learned. Designing is thereby modeled as movement among ontological state spaces, not as a single step from need to object.

The abstraction is a design-science ontology and process model, not a universal claim that every artifact has only one function or that behaviour is context-free. Stakeholders can assign conflicting functions; the same structure can behave differently in different environments; and emergent or unintended behaviour may not serve any chosen purpose. Situated extensions explicitly account for interpretation and environment. The defining discipline is to type claims correctly—teleological function, performance-bearing behaviour, compositional structure—and to make the transformations between those types explicit.

Structural Signature¶

Sig role-phrases:

the function state — teleological claims about what the designed object is for
the expected-behaviour state — performance attributes required to realize the intended function
the structure state — components, geometry, materials, and relations composing the proposed object
the synthesis transformation — generation of a structure expected to produce the required behaviour
the analysis transformation — derivation or prediction of actual behaviour from that structure in context
the evaluation comparison — testing derived behaviour against expected behaviour
the documentation transformation — production of a communicable description of the resulting structure
the reformulation loops — revisions to structure, behaviour expectations, or function after evaluation and reinterpretation
the typing discipline — prevention of direct collapse among purpose, performance, and embodiment, including unintended behaviour and plural functions

What It Is Not¶

Not three synonyms for an artifact. Function names purpose, behaviour names performance or action, and structure names components and relations.
Not a direct function-to-form mapping. Expected and derived behaviours mediate whether a proposed structure realizes the intended purpose.
Not one-way linear design. Evaluation can trigger reformulation of structure, expected behaviour, or even function as understanding changes.
Not a claim that every object has one agreed function. Stakeholders can assign competing purposes, and purposes can change with context.
Not behaviour independent of environment. The same structure can produce different observed performance under different conditions.
Not limited to intended effects. Emergent and unintended behaviours can be derived and evaluated even when they serve no selected function.
Not a universal ontology of all reality. It is a design-science framework whose value lies in typed transformations among teleology, performance, and composition.

Scope of Application¶

The Function–Behaviour–Structure ontology applies to design reasoning when intended purpose, expected or derived performance, and material or relational embodiment must be separated and related explicitly.

Requirements interpretation. Stakeholder purposes are formulated as functions rather than silently treated as component descriptions.
Synthesis. Designers propose structures expected to produce behaviors that satisfy selected functions.
Analysis and evaluation. Behavior derived from a structure is compared with expected behavior and functional need.
Reformulation. Mismatch can change the structure, expected behavior, or understanding of function rather than forcing one fixed path.
Documentation and traceability. Typed links explain why components exist and which performance claims justify them.
Failure diagnosis. Unintended behavior can be traced to structure, environment, or an erroneous expectation.
Design education and comparison. Alternatives can be contrasted through purpose, performance, and embodiment without collapsing the categories.
Applicability boundary. FBS does not imply one objective function, direct function-to-structure mapping, context-free behavior, or one mandatory sequence of creativity.

Clarity¶

Function–Behaviour–Structure ontology separates three statements often collapsed in design discussions: what an artifact is for, what it is expected or observed to do, and what components and relations embody it. The behavior layer makes the proposed realization testable without equating a purpose with one physical design. It also distinguishes expected from derived behavior, exposing mismatches that drive redesign. The sharper question is which structural features generate which measurable behaviors, and whether those behaviors actually satisfy the intended function under the specified requirements.

Manages Complexity¶

Function–Behaviour–Structure ontology compresses a design's many requirements, analyses, and parts into three linked views. Functions state purposes, expected behaviors translate those purposes into observable performance, derived behaviors report what a proposed structure actually produces, and structure records components and relations. The analyst tracks mismatches between expected and derived behavior to locate redesign needs instead of debating purpose and embodiment in one vocabulary. Reformulation, synthesis, analysis, evaluation, and documentation become identifiable transitions, allowing alternative structures to be compared against the same function without assuming one preferred physical form.

Abstract Reasoning¶

Decomposition move. From a design brief, infer functions first, then express expected behaviors before proposing structure. Analysis move. From a candidate structure, derive behavior and compare it with expected behavior to locate mismatch. Reformulation move. If mismatch persists, change function framing, behavior targets, or structure at the appropriate layer rather than editing components blindly. Comparison move. Evaluate alternative structures against the same functions and behaviors. Boundary move. A component or geometry does not itself state its function, and a desired function does not establish that the proposed structure realizes it.

Knowledge Transfer¶

Within the home domain. The Function–Behaviour–Structure ontology transfers across product, mechanical, architectural, and software design when requirements are represented as functions, expected and derived behaviours mediate evaluation, and structure describes components and relations. Reformulation among these spaces retains the design-theory mechanism. Beyond the home domain (B — shared abstract mechanism). Biology and organizations also connect purpose-like roles, observable behavior, and arrangement, but intentional design and designer expectations may be absent. The portable pattern is mapping desired effects through behavior to organization. Using FBS outside design should not import teleology or claim that every function has an authored requirement.

Examples¶

Canonical¶

Consider the design of an electric kettle. The function state includes “heat water” and “permit safe pouring.” A candidate structure contains a vessel, heating element, thermostat, lid, handle, spout, and electrical base. Analysis of that structure predicts behaviours: heating rate, automatic shutoff, surface temperature, steam path, and pouring stability. Those derived behaviours are compared with expected behaviours such as reaching a target temperature within an acceptable time without exposing the user to excessive heat. If the comparison fails, the designer may reformulate structure, behaviour expectations, or even the function—for example, adding keep-warm capability changes all three spaces.

Mapped back: Heating and safe pouring are the function state; required performance is the expected-behaviour state; components form the structure state. Predicting performance is the analysis transformation, comparison is the evaluation comparison, and redesign produces the reformulation loops.

Applied / In Practice¶

A software team designing an appointment system uses the same typed distinctions. “Enable a patient to book an available visit” is a function, not a screen. Expected behaviours include preventing double booking and confirming the chosen time. Structure includes scheduling service, database constraints, notification component, user interface, and external calendar adapter. Simulation and tests derive behaviours under concurrent requests; a discovered race shows the structure does not realize the expected behaviour. The team changes transaction and locking structure, updates diagrams, and reruns analysis. Keeping function, behaviour, and structure typed prevents a database table from being confused with the service outcome it helps produce.

Mapped back: Booking is the function state, no double booking the expected-behaviour state, and services plus constraints the structure state. Concurrency testing performs the analysis transformation, requirement comparison the evaluation comparison, and architecture updates combine the synthesis transformation, documentation transformation, and typing discipline.

Structural Tensions¶

T1 — Identity versus admissible variation. Function-Behaviour-Structure ontology must remain recognizable across legitimate variants. Admissible variation is bounded by this condition: Stakeholder purposes are formulated as functions rather than silently treated as component descriptions. The stable element is expressed by this invariant: The Function-Behaviour-Structure ontology represents a designed object through what it is for, what it does, and how it is constituted, and models designing as transformations among those three views. Treating every surface change as a new abstraction fragments the identity, while allowing a change to the constitutive relation produces a false positive.

Diagnostic: After the proposed variation, can an analyst still establish this invariant: The Function-Behaviour-Structure ontology represents a designed object through what it is for, what it does, and how it is constituted, and models designing as transformations among those three views?

T2 — Recognition versus proxy. The domain needs observable or inferential evidence for Function-Behaviour-Structure ontology, but the evidence is not automatically the identity. The working recognition rule is: the typing discipline — prevention of direct collapse among purpose, performance, and embodiment, including unintended behaviour and plural functions. A familiar indicator can occur without the defining relation, and the relation can persist when a customary detector is unavailable.

Diagnostic: Does the evidence establish the defining claim—The Function-Behaviour-Structure ontology represents a designed object through what it is for, what it does, and how it is constituted, and models designing as transformations among those three views—or only a correlated sign?

T3 — Definition versus operational judgment. A compact definition aids reuse, whereas actual classification in design theory can require expert decisions about boundary conditions, measurements, conventions, or exceptions. In the associated FBS design framework, requirements are interpreted into functions and expected behaviours. The definition must constrain those judgments without pretending that every admissible case can be recognized from a label alone.

Diagnostic: Which observation would make a competent practitioner reject the classification under the stated definition?

T4 — Scope versus overextension. Function-Behaviour-Structure ontology has a genuine habitat in which stakeholder purposes are formulated as functions rather than silently treated as component descriptions. Yet FBS does not imply one objective function, direct function-to-structure mapping, context-free behavior, or one mandatory sequence of creativity. A useful application map therefore has to be broad enough to cover recurring practice and narrow enough to exclude merely topical or metaphorical occurrences.

Diagnostic: Can the claimed application fill the same carrier and relation roles, or has only the name traveled?

T5 — Transfer versus domain accent. Knowledge about Function-Behaviour-Structure ontology can travel within its home domain, and some structural lessons may travel farther. The Function–Behaviour–Structure ontology transfers across product, mechanical, architectural, and software design when requirements are represented as functions, expected and derived behaviours mediate evaluation, and structure describes components and relations. What transfers must be separated from the specialist vocabulary, warrant, and closure conditions that remain anchored in design theory.

Diagnostic: Is the receiving case a literal instance of Function-Behaviour-Structure ontology, a co-instance of Ontology, or only an analogy?

T6 — Autonomy versus reduction. Function-Behaviour-Structure ontology is a strict specialization of Ontology, but the edge does not erase the domain differentia. The broader node supplies only the necessary structural relation; design theory supplies the carrier, warrant, boundary, and exception conditions expressed by this identity: The Function-Behaviour-Structure ontology represents a designed object through what it is for, what it does, and how it is constituted, and models designing as transformations among those three views. The entry is over-split if those conditions add no discriminating work and under-specified if the parent alone is used for cases that require them.

Diagnostic: Can a domain expert use the added conditions to distinguish Function-Behaviour-Structure ontology from another case that equally instantiates Ontology?

Structural–Framed Character¶

Function-Behaviour-Structure ontology is mixed: structurally specifiable but materially dependent on its disciplinary frame. Its structural side consists of the carrier the function state — teleological claims about what the designed object is for and the constitutive relation The Function-Behaviour-Structure ontology represents a designed object through what it is for, what it does, and how it is constituted, and models designing as transformations among those three views. Its framed side comes from design theory, which fixes what the terms denote, what counts as evidence, and when a qualification or exception defeats the classification.

Across the principal tests, the entry is not merely a free-floating pattern. Evaluative weight: the identity can be stated descriptively even when its use has practical or normative consequences. Practice dependence: the typing discipline — prevention of direct collapse among purpose, performance, and embodiment, including unintended behaviour and plural functions. Institutional stabilization: disciplinary conventions may stabilize the name and test without necessarily creating every underlying event or relation. Vocabulary portability: the invariant is The Function-Behaviour-Structure ontology represents a designed object through what it is for, what it does, and how it is constituted, and models designing as transformations among those three views. Import versus recognition: an outside case qualifies literally only if the same typed roles and collapse condition are available; otherwise the comparison is analogical.

The reusable remainder is Ontology under a reviewed subsumption relation. That node preserves the necessary cross-domain organization after the design theory-specific carrier, evidence, and exceptions are removed. Function-Behaviour-Structure ontology remains autonomous because its recognition and collapse conditions distinguish cases that the parent alone leaves together.

Structural Core vs. Domain Accent¶

What is skeletal. The portable skeleton is a typed carrier organized by a constitutive relation, an invariant, a recognition test, and a collapse condition. Here the carrier is the function state — teleological claims about what the designed object is for. The decisive relation is The Function-Behaviour-Structure ontology represents a designed object through what it is for, what it does, and how it is constituted, and models designing as transformations among those three views, which also states the controlling invariant at this level. Stripped of specialist nouns, this organization is represented by Ontology.

What is domain-bound. design theory supplies the actual objects or agents, admissible transformations, units or conventions, standards of warrant, and named exceptions. In this case, recognition requires evidence for the typing discipline — prevention of direct collapse among purpose, performance, and embodiment, including unintended behaviour and plural functions. Admissible variation is bounded by the condition that stakeholder purposes are formulated as functions rather than silently treated as component descriptions, and the classification collapses when function names purpose, behaviour names performance or action, and structure names components and relations. These are constitutive differentia, not illustrative decoration.

Why it remains a domain-specific node. The reviewed DAG relation is subsumption to Ontology. Outside design theory, the parent captures only the reusable structural remainder. The specialist name remains literal only where the typing discipline — prevention of direct collapse among purpose, performance, and embodiment, including unintended behaviour and plural functions can be established under the domain's standards of warrant.

This entry is a kind of Ontology.

Immediate parent — Ontology (subsumption). Function-Behaviour-Structure ontology is a domain-specific kind of Ontology: The Function-Behaviour-Structure ontology represents a designed object through what it is for, what it does, and how it is constituted, and models designing as transformations among those three views. The parent supplies the necessary broader identity—What exists and how entities relate.—while the candidate adds the source-domain carrier, recognition rule, and failure conditions. The defining source account begins: The Function–Behaviour–Structure (FBS) ontology represents a designed object through three related categories: function is what the object is for, behaviour is what it does or the measurable attributes through which purpose is realized, and structure is the components and relations of which it consists.
Nearest catalog surface declined — Ontology. Its rematch score was 0.237382. Retrieval proximity did not establish synonymy or parentage; the carrier, invariant, and collapse condition remain different.
Related reasoning operations. Evidence, comparison, boundary testing, and representation can support a case without becoming additional DAG parents.

Relationships to Other Abstractions¶

Current abstraction Function-Behaviour-Structure ontology Domain-specific

Parents (1) — more general patterns this builds on

Function-Behaviour-Structure ontology is a kind of Ontology Prime

Function-Behaviour-Structure ontology is a domain-specific kind of Ontology: The Function-Behaviour-Structure ontology represents a designed object through what it is for, what it does, and how it is constituted, and models designing as transformations among those three views.

Hierarchy path (1) — routes to 1 parentless root

Function-Behaviour-Structure ontology → Ontology → Set and Membership

Neighborhood in Abstraction Space¶

Function-Behaviour-Structure ontology sits in a sparse region of the domain-specific corpus (63^rd percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Cognitive & Behavioral Theories (16 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-08

Not to Be Confused With¶

Ontology. This is the reviewed immediate parent or structural prerequisite, not a synonym. Tell: retain Function-Behaviour-Structure ontology only when the domain-specific relation The Function-Behaviour-Structure ontology represents a designed object through what it is for, what it does, and how it is constituted, and models designing as transformations among those three views. and its source-domain warrant are established; otherwise route the case to Ontology.
Conceptual Graph. This is the closest catalog retrieval surface, not an accepted synonym or parent. Tell: Ask which entry's carrier, invariant, and collapse test the case actually satisfies; shared vocabulary or a score of 0.727413 is insufficient.
Not three synonyms for an artifact. Function names purpose, behaviour names performance or action, and structure names components and relations. Tell: Require the positive recognition condition that the typing discipline — prevention of direct collapse among purpose, performance, and embodiment, including unintended behaviour and plural functions.
Not a direct function-to-form mapping. Expected and derived behaviours mediate whether a proposed structure realizes the intended purpose. Tell: Replace the familiar surface feature and test whether the Function-Behaviour-Structure ontology represents a designed object through what it is for, what it does, and how it is constituted, and models designing as transformations among those three views.
A detector, representation, or consequence. A method may reveal Function-Behaviour-Structure ontology, a notation may describe it, and an outcome may follow from it without any of those being identical to the abstraction. Tell: Would the defining relation remain if the present detector, notation, or downstream effect changed?
A metaphorical transfer. A case outside the home domain may resemble the structure while lacking its native role types and standards of warrant. Tell: If only the general organization survives, route the comparison to Ontology rather than treating it as another Function-Behaviour-Structure ontology instance.

References¶

Frozen Wikipedia revision: https://en.wikipedia.org/wiki/Function-Behaviour-Structure_ontology (revision 1318674411).
Supporting reference preserved in the packet: https://trace.tennessee.edu/utk_graddiss/2749

The frozen Wikipedia revision is discovery provenance. The cited source set was reviewed for identity, formal or operational relation, and scope. The encyclopedia's structural synthesis is bounded to those claims; URL transport failure alone was not treated as substantive contradiction.