#Domain-Concept Bridge

B.5.3 · Stable · Part B - Trans-disciplinary Reasoning Cluster

#About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a FPF Reference product feature page.

#How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

FPF keeps a small set of admitted U-kinds, ontics, slot relations, mechanisms, characteristics, methods, work values, epistemes, and publication-use relations. Working domains use their own words. A thermodynamicist says "system", "macrostate", "control volume", and "free energy"; a safety engineer says "hazard", "mitigation", and "assurance case"; a software team says "service", "endpoint", and "release".

#Keywords

• domain vocabulary
• source-local meaning
• F.17 cell
• basis relation
• direct relation
• bounded use and loss.

#Relations

#Content

#Problem Frame

FPF keeps a small set of admitted U-kinds, ontics, slot relations, mechanisms, characteristics, methods, work values, epistemes, and publication-use relations. Working domains use their own words. A thermodynamicist says "system", "macrostate", "control volume", and "free energy"; a safety engineer says "hazard", "mitigation", and "assurance case"; a software team says "service", "endpoint", and "release".

Those words are useful. The problem starts when one local word is silently treated as a new root kind, a role assignment, a characteristic, a method, a work occurrence, an evidence relation, or a publication claim without saying which FPF value the claim uses.

#Problem

How can FPF let project teams keep domain vocabulary while preserving the current FPF ontology? A dictionary-style alias is too weak because it only says that two labels are being associated. It does not say whether the claim concerns an entity, a kind, a slot filler, a characteristic coordinate, a role assignment, a method, a mechanism, a work plan, a performed work occurrence, an episteme, a publication-use relation, or an evidence-use relation.

#Forces

#Solution

Use the Domain-Concept Bridge as a bounded reasoning move, not as a new domain container or mandatory record.

1. Start from the exact expression, source, edition, and relevant passage. Use F.0.1 to recover the source-local claim. Recover an F.17 cell and test its basis relation when the current claim needs them, including when an F.9 Bridge is claimed. Add a durable term row only when the receiving use needs that packaging under F.17.
2. Ask which exact FPF value or relation the current claim needs, then use the pattern that defines or constrains it. For example, the answer may concern a System, characteristic, Method, Work occurrence, episteme, system-role assignment, or evidence-use relation; the list is illustrative, not a set of new bridge kinds.
3. If the use really needs a new kind, apply E.24.UK and C.3. A familiar expression, table row, or diagram label supplies no kindhood.
4. If the recovered source-local claim already answers the question, return it and stop. If a receiving use must relate two distinct local-sense claims, use F.9 to test whether an exact Bridge between their F.17 cells actually obtains. Shared spelling, a mapping table, or a completed card proves no such relation.
5. State the receiving use separately. Name the direction, scope or applicability boundary, tolerated loss, evidence or reliance basis, and reopen condition only when each changes that use. The semantic relation alone neither authorizes nor performs the use.
6. When role wording is material, use E.10.ROLE and A.2 to distinguish a local system-role kind, classification, assignment, participation, responsibility, or ordinary language before making the direct claim.

The practical result can be one readable sentence. Use a note, row, or card only when a later reader or tool needs durable packaging. The package describes the result; it does not create the FPF value, local meaning, relation, or permitted use.

An alias says only that L is another name for V. A completed B.5.3 move instead says what the exact source means here, which FPF value the current claim uses, whether any direct relation actually obtains, and what the named receiving use may rely on. Thus a component called "sensor" may lead to a System claim, measurement-capability claim, publication claim, or system-role-assignment claim; the expression alone chooses none of them.

#Archetypal Grounding

A thermodynamics team models a heat engine.

• In the cited thermodynamics source, "thermodynamic system" names the engine under concern together with the boundary and state variables relevant to that local claim. Recover the same System already used elsewhere; the expression does not automatically name a kind or assignment.
• "Macrostate" makes a source-local claim about a state description or characteristic bundle over, for example, pressure, volume, temperature, and particle amount. State the effective scheme and units directly; recover an F.17 cell and its basis relation when the receiving claim needs them, and add a durable term row only when reuse needs one.
• "Control volume" may name a boundary or region relation. The claim must say which entity is bounded and which exchanges cross the boundary.
• "Free-energy objective" may name an objective claim, characteristic, or selection criterion. The claim must say which FPF value the decision uses.
• If the engine control System is assigned a locally defined heat-source-controller system-role kind, establish a separate obtaining occurrence of the declared U.SystemRoleAssignment species. The source-local meaning, classification, assignment, Work, claim scope, and time window remain separate.

Current physical-system claims in this example use A.1 for system identity. A.14 distinguishes the part and whole relations actually claimed; A.22 defines how to identify a selected organization of already established constituents and direct relations. A.3.4 identifies an actual bounded change when one is claimed. Use B.1.6 for any work-resource aggregation needed here and C.16 for measured characteristics.

The control-volume boundary and exchange claims require the applicable thermodynamic rule. If that rule is unavailable, retain the local description and name the missing rule rather than asserting the relation. Planned C.1 (Sys-CAL) may later consolidate that guidance; it is not a current governor.

What this achieves:

• Domain constraints become reviewable without turning every domain word into a root kind.
• Verification can use the direct pattern for the recovered value: boundary discipline for a control volume, characteristic-space discipline for state variables, system-role-assignment discipline when an assignment is claimed, and publication-use or evidence-use discipline for reports and dashboards.
• The heat engine remains the same System when a power-plant architecture, finance model, safety case, and thermodynamics model all discuss it. Any actual F.9 relation states how two distinct local meanings correspond; the named receiving-use claim states which losses block that use.

The same expression can be reused in an architecture view, a requirements document, and a simulation model only after each local claim identifies its actual value. If the claims use distinct local meanings, test any required F.9 relation and its receiving use separately.

Conformance Checklist

• CC-B5.3.1 (Recover the FPF value used by the claim): The result names the exact FPF value or relation used by the current claim before treating a preferred expression as reusable.
• CC-B5.3.2 (No kindhood by spelling): A local expression, dotted name, table row, or diagram label does not become a U-kind. A needed durable kind requires its own E.24/E.24.UK and C.3 settlement from independent ontic and membership evidence.
• CC-B5.3.3 (Role boundary): When role wording changes the claim, E.10.ROLE first recovers whether it means a local system-role kind, classification, assignment, participation, responsibility, or ordinary language. Each resulting claim then uses its own FPF pattern.
• CC-B5.3.4 (Relation and use boundary): Claim an F.9 Bridge only when its exact endpoint cells and predicate make it obtain. State the receiving use, direction, applicable scope, tolerated loss, evidence or reliance basis, and return condition separately; shared spelling proves none of them.
• CC-B5.3.5 (Description boundary): If the local expression appears in a requirement, diagram, dashboard, report, or publication, use the direct description and publication patterns to keep the described entity, description episteme, publication form, and carrier distinct.

Common Anti-Patterns and How to Avoid Them

#Consequences

#Rationale

This pattern implements open-ended parsimony: FPF can use many domain vocabularies without turning every useful expression into a kernel kind. It recovers the source-local claim first, routes the needed FPF value to its direct pattern, and introduces an F.9 Bridge only for an actual relation between distinct local senses.

#Relations

• Builds on: A.2, A.6.5, C.3, E.24.UK, F.0.1, F.1, F.2, F.3, F.5, F.8, and F.17.
• Coordinates with: A.7, C.2.1, E.10.ROLE, E.17, A.13, A.15, B.3.3, F.7, F.9, and the direct domain-specific CHR, LOG, and CAL patterns.
• Used when: a project must recover what an exact source expression means for one FPF claim, or must relate two distinct local meanings for a named receiving use without confusing the wording, governed value, semantic relation, and use.

#B.5.3:End

---

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