#Part F - The Unification Suite (U-Suite): Concept Sets, SenseCells, and System-Role Kinds and Assignments

Preface node heading:part-f-the-unification-suite-u-suite-concept-sets-sensecells-and-system-role-kinds-and-assignments:92677

#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

#Source-Local Meaning Recovery

Type: Architectural (A) Status: Stable Normativity: Normative unless explicitly marked informative

#Problem frame

One-sentence summary. Recover what one expression means in one exact source passage before comparing, translating, or reusing it elsewhere.

Use F.0.1 when a word in an already selected source may be read in more than one way and the reading can change the present answer or action. Name the exact source and edition, state the source-local meaning in ordinary language, and point to the passage that supports that reading.

The first useful result is one source-backed meaning statement. For example: “In OMG BPMN 2.0.2 (January 2014), Process here means the designed sequence or flow of Activities in an organization; this reading comes from §10.1.” If that answers the question, use it and stop.

What changes in practice. A reader can inspect the source of the meaning without first creating a semantic container, record, relation, or assurance package. A stronger formal result is added only for a named later use.

Not this pattern when. Use an already clear source claim directly when no lexical distinction changes the work. Use F.1 when the open question is which sources can change the answer, F.0.2 when several source ontologies must be compared for one receiving claim, and F.18 when the problem is selecting an FPF term after the subject is settled. When the problem is not lexical, use the rule that defines or tests the exact entity, relation, claim, measurement, permission, or Work question. Use F.9 only when an actual relation between already recovered source-local meanings is current.

#Problem

A string does not identify one meaning across sources. The same spelling can denote a designed structure, a performed occurrence, a status, a permission, a measurement, or another subject. If the source, edition, and passage disappear, a later claim can silently change its entity, relation, time stance, or intended use.

The opposite response is also harmful. A full source survey, durable cell, provenance record, reliance disposition, or assurance claim for every word makes ordinary reading needlessly expensive. The problem is to recover one local meaning cheaply while keeping the point of escalation visible.

#Forces

#Solution — recover locally, strengthen only for use

#Recover one source-local meaning

1. Name the question. State what answer or action can change if the expression is read differently.
2. Identify the source. Give the exact source and edition. A discipline or shelf label is not enough.
3. Locate the passage. Point to the claim, definition, example, rule, or other passage used.
4. State the meaning plainly. Say what the expression denotes or claims in that passage. Keep designed descriptions and performed occurrences distinct when the source does.
5. Use the answer and stop. Do not create a durable cell or relation unless a later receiver needs it.

The source, edition, expression, passage, and plain meaning are the ordinary minimum. A brief scoped heading may keep an already established source in view; repeated source tags are unnecessary when the reading remains unambiguous.

#Add a durable address only when it earns its cost

Create one F.17 SchemeSenseCell <ReferenceScheme, LocalExpression, LocalSenseClaim> only when stable reuse, a later claim, a named receiver, or an actual relation to another local sense needs an exact address. The effective ReferenceScheme keeps the source and edition recoverable; the LocalSenseClaim states the meaning rather than hiding it in a label.

State an obtaining LocalSenseBasisRelation only when the support relation from an exact basis episteme to that cell is itself current and supported. Identifying a source, stating that support relation, relying on it in a later use, and assuring that reliance are four different claims. Use A.10 and B.3 only for the latter questions.

When a source fixes a designed-versus-performed distinction or another time stance, put it in the local sense claim or its exact basis. Do not make an edition label or separate container stand in for the distinction.

#Relate different local meanings only when the relation is current

A shared label, close paraphrase, common superclass, table row, embedding score, or family membership does not establish identity or another relation. First recover each source-local meaning separately. Then use F.9 when a receiving use needs an actual relation between the two F.17 cells.

The F.9 result states which two cells are related, what kind of relation obtains, how its endpoints are oriented, and what relation profile makes it true. When a receiving use is current, state a separate C.2.1 claim: what action is proposed, in which direction, under which correspondence rule, how much loss it tolerates, and whether the Bridge is suitable for that use. Changing this use claim does not change the Bridge. Neither the relation nor the claim by itself permits translation, substitution, or row membership, establishes reliance or authorization, or shows that the action occurred. A chain of relations does not silently create a direct endpoint relation.

#Recover old Context-shaped artifacts only for a current reliance

An old Context Card or two-part SenseCell remains an historical episteme or representation under its original edition. Do not relabel it as a current F.17 cell.

When a current claim or action actually relies on it, recover only the values that use needs: for example, the exact source and edition, expression, source-local claim, passage, effective scheme, claim scope, or obtaining relation. If a needed value cannot be recovered, return the exact unresolved value and reopen only the dependent claim or action. Mere archival presence does not start a migration.

#Minimal conceptual objects

#Invariants

1. Every load-bearing local meaning has a recoverable source, edition, and passage.
2. A plain source-backed statement may be the complete result.
3. A SchemeSenseCell is created only for a named durable use and keeps scheme, expression, and claim distinct.
4. A basis relation is stated only when it obtains; reliance and assurance remain separate.
5. Different local meanings remain distinct unless an exact relation between them is established.
6. Designed and performed readings do not become identical through shared wording.
7. A changed edition, passage, or relation reopens only claims and uses that relied on the changed premise.
8. Historical artifacts remain historical; current recovery does not require corpus-wide relabelling.

#Readable reasoning moves

• Local reading. “This source passage uses t to mean m.”
• Durable address. “This receiver will reuse that reading, so record it as an F.17 cell under the effective source scheme.”
• Basis. “This exact source episteme supports the cell through a current LocalSenseBasisRelation.”
• Cross-source relation. “The two recovered cells stand in this stated F.9 relation under this relation profile.” When a receiving use is current: “A separate C.2.1 claim says whether that Bridge is suitable for this action, direction, correspondence rule, and tolerated loss.”
• No transitive shortcut. Two established relations through an intermediate meaning do not establish a direct third relation.
• Affected-only reopening. A changed source premise reopens the claims that used it, not every claim that cites the edition.

These are allowable conceptual moves, not storage fields, APIs, or mandatory workflow records.

#Archetypal Grounding

#Entry, stop, and continuation

Start with one troublesome use in one already selected source. Return one ordinary sentence plus a source pointer. Stop when it answers the question.

Continue only for the next result actually needed:

• F.1 for a question-relative source cut;
• F.17 for a durable local-sense address and, when current, its basis relation;
• F.9 for an actual relation between distinct recovered cells;
• F.0.2 for a bounded comparison or synthesis among source ontologies;
• F.18 for naming after the subject distinction is settled; or
• the rule that defines or tests the exact entity, relation, claim, measurement, permission, or Work question itself, with its pattern ID as locator.

#Compact worked results and recognition cues

A worked result below names the exact source, edition, passage, and meaning used. A recognition cue only marks a likely false friend; it establishes no local meaning until the practitioner supplies those four values. This distinction keeps a broad set of examples useful without dressing an unresolved pointer as source-backed knowledge.

#process and activity

• Worked result — OMG BPMN 2.0.2 (January 2014), §10.1, Processes. Process denotes the designed sequence or flow of Activities in an organization.
• Worked result — W3C PROV-O Recommendation (30 April 2013), §3.1, Starting Point Terms. Activity denotes something that occurs over a period of time and acts upon or with entities, including using or generating them.

The first question may need only one of these readings. If a later use relates the designed structure to performed occurrences, recover two F.17 cells and state the exact F.9 relation, including concurrency or trace information that does not carry across. Do not call the two meanings identical.

#actuation and control output

• Recognition cue — control theory. If actuation may mean a signal applied to plant actuators, select one exact control-theory publication, edition, and passage before using that reading.
• Recognition cue — IEC 61131-3. If control output may mean a program-produced value sent to field I/O, identify the exact edition and clause before using that reading.

These cues establish no relation. After both readings become worked results, F.9 may test whether the PLC output can be read as the controller's actuation signal for one stated operating regime while keeping hardware and scan-cycle limits visible.

#observation and service metric

• Worked result — W3C SOSA/SSN Recommendation (19 October 2017), §4.3.2.2, sosa:Observation. Observation denotes the act of carrying out a procedure to estimate or calculate a value of a property of a feature of interest.
• Recognition cue — ITIL 4. If service-level metric is used for a quantity that evaluates a service-level objective, identify the exact ITIL 4 publication, edition, and passage before using that reading.

The verified SOSA reading alone establishes no service-metric relation. Once the second reading is source-backed, a named use may ask whether the observation supplies evidence for that metric; that is a subject relation, not lexical identity or same-row membership.

#subclass-of and is-a

• Worked result — W3C OWL 2 Structural Specification and Functional-Style Syntax, Second Edition (11 December 2012), §9.1.1, Subclass Axioms. SubClassOf(CE1 CE2) states that the first class expression is a subclass of the second.
• Recognition cue — engineering glossary. If is-a is being used as a less formal kind-of relation, identify the exact glossary, edition, and entry before relying on that reading.

Keep the verified formal reading and the unresolved cue separate. Relate them only when the receiving artifact needs the formal relation and an exact second passage supports the correspondence.

#permission and RBAC role

• Worked result — W3C ODRL Information Model 2.2 Recommendation (15 February 2018), §2.6.1, Permission Class. A Permission allows an action on an Asset when its refinements and constraints are satisfied and its duties are fulfilled.
• Recognition cue — NIST RBAC. If role is being used for an access-control grouping through which permissions are assigned, identify the exact NIST publication, edition, and passage before using that reading.

The verified permission reading is not the unresolved role reading. A later access-control use may relate two source-backed meanings, but familiar wording alone establishes neither the relation nor interchangeability.

#Quick checks for later use

• String check. If the only evidence is the same spelling, no cross-source relation has been established.
• Stance check. If one source describes a design and another a performed occurrence, state that difference before any relation or row use.
• Direction check. Preserve the direction and limits of the actual relation; a reverse or broader reading needs its own support.
• Chain check. Keep intermediate meanings and accumulated loss visible; test a direct endpoint relation separately when needed.
• Contradiction check. Incompatible relation claims about the same cells remain explicit rather than being averaged into a vague alignment.
• Row check. A Concept-Set row needs the relation and bounded receiving-use judgment required by F.7 and F.9; a label or confidence level cannot admit a member.

#Quick reference

• Ordinary result: one source-backed plain meaning statement.
• Durable local meaning: an optional F.17 SchemeSenseCell.
• Current support: an optional obtaining LocalSenseBasisRelation.
• Different local meanings: separate cells; use F.9 only for an actual relation.
• Source selection: F.1; synthesis: F.0.2; naming: F.18; subject reasoning: the defining or testing rule for the recovered claim.

Mental checklist: Name the source and edition → locate the passage → say what the expression means → stop if sufficient → add only the durable address or relation a named receiver needs.

#Bias-Annotation

• Gov: Source authorship, popularity, or standard status does not decide the receiving claim.
• Arch: The pattern favors recoverable local meanings and explicit relations over one global vocabulary or universal container.
• Onto/Epist: A word, a local-sense claim, its subject, its source, a basis relation, and a receiving claim remain different.
• Prag: Ordinary use is one sentence and one citation; stronger objects and assurance are conditional.
• Did: Plain worked cases come before formal designators. A scoped source heading may reduce repetition without hiding the source.
• Scope: The pattern recovers meaning. It does not establish source truth, source adequacy, relation obtaining, permission to substitute, or assurance.

#Conformance Checklist

#Static checks

• SCR-F01 (Recoverable source). Every load-bearing local meaning identifies the exact source, edition, and passage directly or through an unambiguous scoped reference.
• SCR-F02 (Plain first result). The ordinary branch's result is a readable meaning statement, and the practitioner may stop there.
• SCR-F03 (Conditional cell). A SchemeSenseCell appears only for a named reuse, claim, receiver, or relation need and keeps ReferenceScheme, LocalExpression, and LocalSenseClaim distinct.
• SCR-F04 (Separate support). A LocalSenseBasisRelation is asserted only when current; source identification, reliance, and assurance are not inferred from it.
• SCR-F05 (No string identity). Shared wording, family, score, or row does not establish a relation between local senses.
• SCR-F06 (Explicit relation and use). Every claimed cross-local relation uses exact F.17 endpoints and the applicable F.9 relation profile. When a receiving use is current, a separate C.2.1 claim names the proposed action, use direction, correspondence rule, tolerated loss, and polarity.
• SCR-F07 (Temporal honesty). Designed descriptions and performed occurrences remain distinct wherever the source fixes that difference.
• SCR-F08 (No subject capture). The local gloss does not redefine the subject's behaviour, deontics, measurement, kind, proof, or work rules.

#Regression and evolution checks

• RSCR-F01 (Affected edition change). A changed edition or passage reopens only local claims and later uses that relied on the changed content.
• RSCR-F02 (Endpoint change). A changed cell claim or stance triggers recheck of relations and uses that cite that endpoint.
• RSCR-F03 (Composition guard). A relation chain never silently becomes a direct relation or unrestricted substitution.
• RSCR-F04 (Source-cut relevance). Reopen F.1 only when the receiving question or use, a relied source role, known rival, counterexample, or transfer limit changes.
• RSCR-F05 (Historical recovery). An old Context-shaped artifact is recovered only for a current reliance; missing values return as exact unresolved inputs.

#Common Anti-Patterns and How to Avoid Them

#Consequences

Local meanings become inspectable and revisable without forcing a global vocabulary. A reader sees when source selection, synthesis, naming, subject reasoning, or a cross-local relation is the real next question. Most uses become cheaper because one sentence and one citation can close them.

The cost is explicit judgment about source, edition, passage, and meaning. A reusable cell or relation requires more work only when a later receiver needs it. This cost is preferable to hiding several different objects behind one generic container.

#Rationale

Meaning is cheapest to recover where a source actually uses an expression. Starting with the source passage prevents a later comparison from rewriting the source before the commonality or difference is known. Keeping durable cell identity in F.17 and cross-local relations in F.9 prevents local recovery from becoming a second ontology or relation catalogue.

The proportional split also protects practical use: one identified source can yield an answer immediately; several possible sources call for F.1; several source ontologies call for F.0.2; an actual relation calls for F.9.

#SoTA-Echoing

The non-dominated combination is a plain local answer first, an exact durable address only for reuse, an inspectable relation only when current, and receiving-use judgment separately.

#Relations

• F.17 defines SchemeSenseCell and LocalSenseBasisRelation.
• use F.1 to select exact sources and editions for one receiving question and use.
• F.0.2 compares or synthesizes several source ontologies after their meanings are recovered.
• F.2 and F.3 support term evidence and local-sense clustering when those heavier moves are needed.
• Use F.7 for Concept-Set rows and F.9 for actual cross-local relations and their bounded uses.
• Use E.15 for edition continuity, supersession, and affected-premise reopening.
• Use A.10 for evidence use and reliance and B.3 for assurance.
• Use F.18 for term choice after the subject distinction is settled.

#F.0.1:End

#Conceptual Synthesis across Source Ontologies

Type: Architectural (A) Status: Draft Normativity: Normative unless explicitly marked informative

#Problem frame

Use this pattern when several sources describe the same working question through materially different concepts, relations, explanations, or boundaries, and those differences can change a named authoring decision or a contribution to one subject pattern.

The primary concern is one bounded conceptual-synthesis question for one declared receiving use. The first useful move is to state that question and the difference that could change the next decision. Keep each source claim local through F.0.1, choose the source cut through F.1, then compare the claims here.

What goes wrong if missed. An author either leaves a crosswalk or literature narrative where a positive contribution is needed, or merges similar words before checking whether the sources describe the same entity, relation, explanation, and use. A large research package may also be demanded for a question that one bounded comparison can settle.

What this buys. The author can turn heterogeneous source ontologies into one reviewable result: a provisional synthesis claim, a contrast claim, or an unresolved-inquiry claim. When a pattern contribution is proposed, the result also states the practitioner action, first useful result, and later content decision that may accept, change, reject, or reopen it.

Not this pattern when. Cite one source directly when one source claim closes the question. Use F.1 alone when only source selection is current; F.0.1 when only local meaning is unclear; F.9 when one relation between already recovered cross-context senses is current; and the subject pattern when it already supplies the needed action and result. Use G.2 instead when the work needs a broad, refreshable SoTA Synthesis Pack@CG-Frame and its downstream Part G handoffs.

#Problem

Framework authors often receive maintained syntheses, books, papers, standards, models, and current alternatives whose ontologies are partly similar and partly incompatible. Lexical alignment can reveal candidate correspondences, but it cannot decide whether the receiving framework should adopt a shared claim. A literature summary can preserve sources, but it may never state what changes in practice.

Three failures follow:

1. a correspondence, shared label, similarity score, or framework fit is treated as permission to merge;
2. a source difference that changes action is hidden as terminology variation; or
3. missing or weak source material is reported as if the disputed domain claim were false.

Conceptual synthesis must preserve source-local meanings while returning a positive next move or an honest bounded stop.

#Forces

#Solution

#Bounded synthesis method

1. Name the receiving question and use. State the authoring decision or subject-pattern contribution that may change. Name the practical action and first result under consideration when a pattern contribution is being proposed.
2. Recover source-local claims. For every load-bearing source, identify the claim, its EntityOfConcern, effective ReferenceScheme, edition, source role, and the context in which the claim is used. Apply F.0.1; use F.9 only when the comparison asserts a relation between exact cross-context SenseCells.
3. Choose a bounded source cut. Apply F.1. Include the sources needed for the intended use, known rival explanations, action-changing counterexamples, transfer limits, and material non-fit. State why each selected source can change the decision.
4. Compare what changes action. Compare concepts, relation participants, explanations, contexts, assumptions, source roles, counterexamples, losses, and validity limits. Treat lexical or model correspondences as proposals to inspect, not as conclusions.
5. Write one first result. Write a provisional synthesis claim when a positive shared contribution is warranted; a contrast claim when the proposed unification is not warranted for the named use; or an unresolved-inquiry claim when a named source gap prevents either substantive answer.
6. Give the result a stable local locator and name its receiving decision. Keep ordinary C.2.1 claim identity. Add a stable locator within the authoring source, such as SE-CS-03, so later text can cite the same result together with that source edition. Name the content, placement, or pattern-allocation decision that will consider it. The locator does not identify the episteme and the file does not make the decision.
7. Record the receiving disposition. When the named decision is made, its decision record states whether this result is used as proposed, revised into a newly identified claim, not used for the named purpose, or reopened for further comparison. Cite the result locator and source edition. A result awaiting that decision remains a proposal; silence or a citation is not acceptance.
8. Keep the source use revisable. Identify the source claims and editions relied on, why each matters to this result, what was deliberately left local or rejected, and which change reopens the comparison.

Stop after one bounded synthesis slice when it answers the named authoring question. Enter clustering, Concept-Set, naming, UTS, or heavy harvesting only when the next question requires that additional result.

#Source-basis branches

#Three result branches

Every result recorded for later authoring, review, or decision use is an ordinary claim-bearing episteme under C.2.1. Its identity remains <claim content, EntityOfConcern, effective ReferenceScheme>. Give every such result a stable local locator in its authoring source and cite that locator together with the source edition. The locator helps readers recover the claim but does not identify it by itself.

The source gap is the reason and closure condition for an unresolved-inquiry claim, not a fourth result branch. A temporary unrecorded pause is not an F.0.2 result that later work can cite.

#Bounded method and broad SoTA-pack method

Use F.0.2 for one ontology-to-subject-pattern question whose smallest useful result is one of the three claims above. Use G.2 when a CG-Frame needs a broad, refreshable harvesting surface with a CorpusLedger, Claim Sheets, palette, inventories, alignment records, examples, and declared G.3-G.5 handoffs.

The methods combine in one direction. An author may use identified claims and provenance from a G.2 pack as inputs here. The author must still compare retained differences, limits, receiving use, and reopen conditions before writing an F.0.2 result. The bounded comparison does not require the rest of the pack when the question does not use it.

#Boundary to wording-use precision restoration

Conceptual synthesis and wording restoration both pass through ontology, but they answer different questions. Conceptual synthesis forms or revises a cross-source claim. Wording restoration starts from an already current subject claim and repairs a consequential wording use so that the intended entity, relation, claim kind, and admissible action can again be recovered.

A recurring wording failure may supply evidence that a subject distinction is missing or unstable. The system maintaining the affected FPF or DPF edition then uses that evidence in a named content decision. The findings do not themselves revise the synthesis claim. A DPF keeps its domain wording entries beside the domain patterns that use them; E.10.ARCH supplies the shared restoration method.

A DPF may need a reliable current domain ontology so practitioners can recognize situations, distinguish Methods and results, and use its solution moves. An author can use F.0.2 to synthesize or revise that ontology as a proposed contribution. Ontology alone is not a DPF: use E.4 and E.4.DPF to connect it to recurring problems, constructive Methods, a usable first cut, evidence practice, access, and maintenance.

#Archetypal Grounding

#Systems Engineering use and system concept

A Systems Engineering DPF author must decide what a practitioner should do when a proposed system concept is internally attractive but its connection to outside use is unclear. The bounded source cut contains three exact editions:

The cut is sufficient for the present decision because these pinned claims expose the action-changing difference. No relied-on clause from ISO/IEC/IEEE 15288:2023 or the INCOSE Handbook fifth edition is pinned in this slice, so adding their titles alone would not add decision-relevant content. Reopen the cut when an accessible clause is pinned and can change the receiving decision.

A lexical crosswalk can now appear to improve: map environment, using system, containing system, use concept, and system concept into one hierarchy and the visible match or coverage rate rises. The receiving decision gets worse. Ownership, use, interaction, affectedness, parthood, and function bearing become indistinguishable, so the author can no longer compare a change to the project System with a change to an external System, interface, or Work arrangement. The better proxy therefore hides the practical distinction that the synthesis is meant to preserve.

The author records the provisional synthesis branch at local locator SE-CS-USE-01 with this exact claim: “For one Systems Engineering concept decision, develop the outside-facing use claim and the inside-facing system-concept claim together; state the decision-changing subjects and direct relations; and reopen either claim when architecture or realization evidence defeats it. Do not infer one containing System, fixed lifecycle, or mandatory carrier form.” The result retains the guide's use-and-concept link, SEBoK's concurrent, iterative, and recursive application, and FPF's separate relation conditions.

A later Systems Engineering DPF content decision cites SE-CS-USE-01 and records whether it uses, revises, splits, or rejects the proposed contribution. In this worked case, it records used as revised: the applied use-and-system-concept move stays in the Systems Engineering DPF, while general claim, parthood, and function-bearing rules stay in FPF. Reopen SE-CS-USE-01 when one of the named source editions changes the linked action or boundary, a counterexample shows that the proposal cannot guide the decision, or the receiving decision changes its intended use.

#Organization change contrast

An organization-change author compares schools that describe organizational flows and partial organizations through different transformations and coordination structures. The sources support a narrower claim about linked transformation and coordination structures, but not one universal organization-flow kind. The author records a contrast claim, preserves the source-local decompositions, and lets a later DPF content decision choose the narrower contribution.

#Scientific classification inquiry

A cross-disciplinary data framework proposes one shared classification relation between a laboratory ontology and an administrative classification. The available alignment suggests candidate correspondences, but the current edition of a load-bearing clinical source is unavailable. The author records an unresolved-inquiry claim about that bounded comparison, keeps the administrative-only use available, and names inspection of the missing clinical edition as the next source action.

#Cheap anti-case

An engineer consults a handbook and its later edition only to recover the current pump tolerance. The later edition gives the needed claim, and no ontological difference changes the authoring decision. The engineer records direct source reliance and stops without conceptual synthesis.

#Bias-Annotation

Scope. This pattern is limited to one bounded synthesis question in which differences between source concepts can change an FPF or DPF content decision. It is not a general method for literature review, ontology alignment, source selection, evidence, assurance, or framework admission.

This pattern favors explicit source roles and positive integration over a single authoritative vocabulary. That stance can overvalue synthesis and make every disagreement look like a new framework contribution. The cheap exits, contrast branch, unresolved-inquiry branch, and subject-pattern placement test keep the work proportional. Domain knowledge, lived practice, institutional authority, and empirical evidence remain source-local until a receiving claim states how they are used.

#Conformance Checklist

• CC-F0.2-1 The receiving question, intended use, and action-changing source difference are stated before comparison begins.
• CC-F0.2-2 Every load-bearing source claim has a recoverable EntityOfConcern, effective ReferenceScheme, edition, and source role; locators are not treated as source-use relations.
• CC-F0.2-3 The source cut covers the intended use, known rival explanations, action-changing counterexamples, transfer limits, and material non-fit by relevance rather than by a universal count or distance threshold.
• CC-F0.2-4 Similarity, correspondence, Bridge, framework fit, or G.2 pack conformance is used as input and not as synthesis truth or permission to merge.
• CC-F0.2-5 The result is one provisional synthesis claim, contrast claim, or unresolved-inquiry claim with ordinary C.2.1 identity and one stable local locator in the authoring source.
• CC-F0.2-6 The result names its receiving content, placement, or pattern-allocation decision. When that decision occurs, the decision record cites the result locator and source edition and states the disposition; an absent disposition is not acceptance.
• CC-F0.2-7 The result states relied source claims and editions, why each matters, retained differences and limits, and material reopen conditions.
• CC-F0.2-8 An unresolved-inquiry claim concerns the inquiry state, names what remains usable and the next source action, and does not turn missing evidence into a negative domain claim.
• CC-F0.2-9 Domain roles, methods, examples, evidence bases, and refresh lines stay in their subject DPF; the reusable synthesis move remains independent of those DPFs.
• CC-F0.2-10 The author stops after the smallest result that answers the receiving question and opens G.2 or later Part F work only for a named additional use.

#Common Anti-Patterns and How to Avoid Them

#Consequences

Benefits:

• framework authors can produce a useful first claim before a complete account or UTS exists;
• source differences that alter action remain visible instead of being normalized away;
• small and large synthesis investments have separate methods that can reuse the same identified source claims; and
• DPFs reuse one method while retaining their own doctrine, evidence, examples, and currentness.

Costs and trade-offs:

• authors must recover source claims and editions rather than cite files or bibliographies as wholes;
• a contrast or unresolved inquiry can be the correct result even when a positive synthesis was expected; and
• later reliance still needs the evidence-use, decision, admission, assurance, or publication claims required by that use.

#Rationale

Conceptual synthesis is the middle move between preserving local meaning and publishing a unified term or subject-pattern contribution. It cannot be reduced to lexical alignment because a correspondence does not decide what the receiving framework should claim. It cannot be reduced to literature review because a source inventory does not state the practitioner action. It should not require a full G.2 pack because many authoring decisions need only one bounded comparison.

The three result branches keep the method constructive without forcing agreement. A provisional synthesis opens a positive contribution, a contrast preserves a decision-relevant difference, and an unresolved inquiry turns a real source limitation into a defined next action. Ordinary C.2.1 claim identity keeps those results separately revisable without introducing a ConceptualSynthesisAccount kind or making their carrier ontological.

#SoTA-Echoing

The current best-known line is plural: ontology matching is strong at proposing inspectable correspondences, while theory and framework synthesis are strong at producing a positive contribution and handling fit and non-fit. F.0.2 combines those complementary moves and adds FPF claim identity, local-meaning discipline, pattern placement, cheap exit, and later-use boundaries. Revisit this comparison when matching practice, conceptual-synthesis methods, or heterogeneous use exposes a better result branch or a missing action.

#Relations

• Builds on: F.0.1 for source-local meaning and F.1 for a relevance-based source cut.
• Uses when current: F.9 for an asserted relation between exact cross-context SenseCells; C.2.1 for every recorded result claim; A.2.4 and the applicable direct relation pattern for a later evidence or decision use.
• Coordinates with: F.2-F.8, F.14, F.17, and F.18 when the next authoring question requires harvesting, clustering, Concept-Set, naming, or UTS work.
• Coordinates with: G.2 as the optional broad harvesting method. Identified claims and provenance from a G.2 pack may supply inputs here; the pack does not replace the receiving comparison.
• Coordinates with: E.4.DPF for DPF entry and result placement, E.10.ARCH for DPF-local wording entries under the shared restoration method, and G.11 for source-currentness and refresh work.
• Boundary: Domain claims produced through this method remain in the subject FPF pattern or named DPF selected by the later content decision. F.0.2 introduces no domain doctrine, new root kind, generic synthesis-to-use relation, admission result, assurance result, publication result, or mandatory carrier.

#F.0.2:End

#Question-Relative Source Selection

Type: Architectural (A) Status: Stable Normativity: Normative unless explicitly marked informative

One-sentence summary. Select the smallest inspectable set of exact sources whose claims, limits, rivals, or counterexamples can change one stated answer or use.

Historical title (informative). Domain-Family Landscape Survey. Aliases (informative). Source cut; question-relative source selection.

#Problem frame

Use F.1 when the receiving question is clear, more than one source may change its answer, and the source cut is not yet justified. Start from candidate sources and exact editions, ask how each could change the answer or its limits, and retain the smallest set that covers the distinct contributions that matter.

The first useful result is one SourceCutNote : U.Episteme. Before treating the note as that episteme, identify the receiving question as one exact project entity. That question is the note's EntityOfConcern; the intended use remains in the ClaimGraph rather than becoming a second subject. Name the effective U.ReferenceScheme explicitly: it must resolve the question, the cited source-edition designators, and the answer-changing role claims. The ClaimGraph also names deliberate exclusions, known limits or source gaps, and reopen conditions. If the question or scheme is still missing, keep an ordinary working note and return that missing value instead of claiming a C.2.1 episteme. A one-screen source note may represent the same episteme when it carries the same claims; its compact form neither admits a source nor contains its local meaning.

What this buys. Later term recovery, comparison, synthesis, or direct source use begins from an inspectable reason for each source rather than from one influential canon, a bibliography quota, a domain label, or an opaque search score.

Not this pattern when. If one already identified source closes the question, use its claim directly or use F.0.1 for one source-local meaning. Use F.9 for an actual relation between recovered local senses and F.0.2 for a bounded conceptual comparison or synthesis. Use G.2 for a broader refreshable SoTA pack. When the receiving work requires an exhaustive, protocol-defined, or appraisal-bearing evidence review, use its domain method; F.1 does not replace that search, appraisal, or reporting discipline.

Primary result. One question-relative SourceCutNote, not a source container, meaning container, admission token, or assurance result.

#Problem

Without a question-relative source cut:

1. Word drift. Familiar terms silently change meaning across sources and editions.
2. Canon lock. One influential standard is mistaken for the whole answer.
3. Recency blur. An old edition remains load-bearing merely because it was used first.
4. Category bleed. Designed structures, performed occurrences, system roles, statuses, permissions, and measurements are merged before their source claims are inspected.
5. Source bloat. A large reading list hides which sources can actually change the current answer.
6. Search substitution. Rank, similarity, or family membership is mistaken for relevance, truth, or completeness.

#Forces

#Solution — select by answer-changing role

#Minimal vocabulary

• Exact source and edition. The identified publication, canon, corpus, practice source, or other claim-bearing basis being considered.
• Receiving question and use. The independently identified question that the source-selection claims concern, plus the decision, pattern contribution, comparison, or action the answer will serve. The question is the SourceCutNote's EntityOfConcern; the use is claim content.
• Answer-changing role. The inspected claim, limit, rival explanation, counterexample, transfer condition, material non-fit, or other stated contribution by which a source can change the answer.
• Source cut. The finite set of sources retained for that question and use.
• SourceCutNote. One C.2.1 episteme identified by its source-selection ClaimGraph, the exact receiving question as EntityOfConcern, and the named effective ReferenceScheme under which that question, source editions, and role claims are read.
• Domain family. An informative discovery label, such as workflow, provenance, services, sensing, types, or control. It carries no semantics and cannot admit, merge, or replace a source.
• Local search policy. An optional named way to prioritize candidate inspection using search terms, descriptors, citations, embeddings, distances, active learning, or portfolio readings. Its output is attention guidance, not a source-selection verdict.

Source selection, source identity, source-local meaning, source truth, source adequacy, cross-source relation, synthesis, reliance, and assurance are separate questions.

#Source-selection method

Step 1 — State the receiving question and use. Say what answer is needed, what later use it serves, and which source difference could change that answer.

Step 2 — Name candidate sources by exact edition. Use identified sources whose relevant claims can be inspected. A discipline or domain-family label may help discovery but is not a source.

Step 3 — Inspect the answer-changing role of each candidate. Ask what claim or limit from that edition can change the answer. If that role depends on a disputed expression, pause selection only long enough to use F.0.1's ordinary branch: name the exact source, edition, and passage, and say in plain language what the expression means there. Then return to source selection. Do not run this branch for every candidate. Look deliberately for intended-use contributions, rival explanations, action-changing counterexamples, transfer limits, and material non-fit. One source may serve several roles.

Step 4 — Take the smallest sufficient cut. Retain sources that cover distinct answer-changing roles. Exclude a candidate when no inspected claim from it changes the stated question or use. Do not optimize for a fixed count, diversity score, canonical status, or exhaustive appearance.

Step 5 — Record exclusions, gaps, limits, and reopen conditions. Name deliberate exclusions and why they do not change this answer. State a load-bearing source gap rather than treating an unavailable source as irrelevant. Say which question, use, edition, rival, counterexample, or transfer-boundary change would reopen the cut.

Step 6 — Return one SourceCutNote. Identify it under C.2.1 by three values: the ClaimGraph produced by Steps 1–5, the exact receiving question from Step 1 as EntityOfConcern, and the named effective ReferenceScheme that resolves the question, cited editions, and role claims. Keep the intended use in the ClaimGraph. Use a one-screen representation when it helps the receiver hold the result in view. Detailed source analysis stays with the receiving comparison, synthesis, or evidence method. Step 7 — Recover only the meanings the work needs. After the cut is stable, create an F.17 local-sense cell only for a retained expression that later reuse, a claim, a named receiver, or an actual relation needs. Do not postpone a meaning needed by Step 3 to this stage, and do not manufacture a cell for every retained source.

#When the cut will support a SoTA claim

A source cut used to claim SoTA has a stricter role test because source relevance and source currentness do not establish the best-known answer. E.8:11 owns the FPF definition of SoTA and the meanings of its comparison roles; F.1 neither redefines SoTA nor selects the winning line. For each retained source, record one of those roles in plain wording: best-known-line candidate, serious current rival, failure or counterexample evidence, official or popular comparator, lineage only, or identity/currentness only.

The first three roles can supply answer-changing evidence. An official or popular comparator may stay only when its named defect is necessary to the comparison. Roles are assigned by contribution, not institution: an official standard or widely used practice may instead be a best-known-line candidate when its substantive answer wins against the serious alternatives. Officiality, prevalence, maintenance, citation, freshness, or academic praise contributes nothing to that rank. An official catalogue, publisher page, or registry entry may verify the source's identity, edition, publication date, or maintenance state; it establishes neither truth, adequacy, nor SoTA rank.

For a SoTA claim, disable the generic one-source cheap exit unless the one source is itself a current critical synthesis that compares the serious alternatives for the named question and the author can state why no known action-changing rival or counterexample remains hidden. Otherwise retain the necessary rival and failure evidence or return an unresolved source gap. Do not manufacture confidence from a one-source cut.

The SourceCutNote records the E.8:11 roles and the missing comparison, but it does not itself select the best-known line. Use F.0.2 when an actual cross-source synthesis claim is required. Use G.2 only when a broader refreshable evidence pack is justified; a bounded comparison does not require that apparatus by default.

#The SourceCutNote

The note's exact EntityOfConcern is the independently identified receiving question from Step 1. It is not the note, its file or one-screen form, the retained-source list, or a question-and-use bundle. The intended use remains part of what the note claims. Name the effective ReferenceScheme explicitly and make sure it resolves the question, every exact source-edition reference, and every answer-changing role statement. If either the question or scheme is unresolved, return that gap and keep the text as an ordinary working note.

Its ClaimGraph states:

• the receiving question and intended use;
• every retained source and exact edition;
• the answer-changing role of each retained source;
• for a SoTA-supporting cut, each retained source's plain role and any unresolved rival, counterexample, or synthesis gap;
• deliberate exclusions and their reasons;
• known limits and load-bearing source gaps;
• the distinction between designed and performed material when it affects the answer; and
• the conditions that reopen the cut.

A one-screen source note is a compact representation of the same episteme when it carries the same claims. If its ClaimGraph differs, it is another C.2.1 episteme rather than a second F.1 result kind. A short form does not establish source truth, adequacy, or local meaning.

#Optional search assistance

Use search aids only under a named local policy and only when they help find a suspected omission, rival, counterexample, or near-duplicate. When the result matters, keep the searched corpus, source editions, model or ranking method, scale or threshold, and intended interpretation recoverable.

Inspect the underlying source claims before changing the cut. A descriptor match, citation count, embedding distance, LLM answer, rank, threshold, active-learning choice, or portfolio score never admits, excludes, merges, or replaces a source by itself.

#Invariants

1. Every retained source has an inspected answer-changing role for the stated question and use.
2. The cut is finite, inspectable, and revisable; no universal count establishes sufficiency.
3. Exact sources and editions remain recoverable.
4. Source-local meanings remain local; F.1 does not merge or relate them.
5. The result contains no F.9 relation, synthesis conclusion, truth verdict, reliance decision, or assurance claim.
6. Domain families and search readings guide discovery only.
7. Designed descriptions and performed occurrences stay distinct when that source difference matters.
8. A changed relied premise reopens the affected cut claims; an unrelated edition-number change does not.
9. One already identified sufficient source is the ordinary cheap exit; for a SoTA claim, the stricter critical-synthesis condition in F.1:4.2.1 applies.
10. A protocol-defined evidence review continues to follow its domain method.

#Self-checks

• Answer-change test. What can each retained source change in the answer or action? If nothing, exclude it or state the missing role.
• Rival-and-limit test. Is a known rival explanation, counterexample, or transfer limit still hidden? Add the source that makes it inspectable or return the source gap.
• One-source test. Does one already identified source close the ordinary question? If yes, stop without additional F.1 steps. If the cut will support a SoTA claim, take this exit only when that source is a current critical synthesis of the serious alternatives and no known action-changing rival or counterexample remains hidden.
• SoTA-role test. Has each retained source been classified under one of the comparison roles defined in E.8:11? If not, classify it there before using the cut for a SoTA claim; do not recreate the role meanings in F.1.
• Rank test. Did official status, popularity, maintenance state, date, or a catalogue check raise a source's SoTA role? Remove that inference; keep the check only as source identity/currentness evidence.
• Gap test. If the best-known line cannot be established, does the note return the missing rival, counterexample, or synthesis need as a source gap rather than naming the newest available source?
• Locality test. Have two sources been treated as saying the same thing merely because they use the same word? If so, use the ordinary F.0.1 branch on the exact passages before deciding their roles, then return to selection.
• Search-policy test. Did a score decide membership before source claims were inspected? Undo that decision.
• Memory test. Can the receiver hold the cut and each source's role in view? Remove non-changing material or split genuinely different questions.
• Reopen test. Can the note say what future change would require selection again?

#Archetypal Grounding

#Three heterogeneous source cuts

#Role assignment, performed work, sensing, and execution

Candidate sources include BPMN 2.0 (designed workflow structures), PROV-O (performed activities and provenance), ITIL 4 (service vocabulary), ODRL 2.2 (permissions, prohibitions, and duties), SOSA/SSN (observations and results), and IEC 61131-3 (control-program execution). Retain only those whose exact claims change the receiving question.

The cut keeps false friends visible: a BPMN participant is not an RBAC role; a PROV activity is not a BPMN process; an SOSA observation is an act, not a status; an ITIL incident is not automatically a plant fault. F.1 exposes these source roles but does not settle their relations.

#Methods, types, and measurement

SPEM 2.0 or ISO 24744 may change the reading of Method and MethodDescription; OWL 2 and formal concept analysis may change kind reasoning; SOSA/SSN and ISO 80000-1 may change measurement and quantity claims. The cut preserves the source-fixed differences rather than making method, concept, or measurement globally uniform.

#Control, actuation, and services

Control-theory sources, IEC 61131-3, ISA-95, ITIL 4, and SOSA/SSN can contribute different claims about controller design, program execution, integration, service commitments, and observations. A current question may need only a subset. Actuation is not a service promise, and incident is not a plant fault merely because the words occur near operational work.

#Minimal worked source cut

The project brief already identifies this receiving question: Can one contribution use “process” for both a workflow description and a performed occurrence? The exact question, not the note or source list, is the SourceCutNote's EntityOfConcern. The project names its effective ReferenceScheme Workflow and occurrence source cut, August 2026; that scheme fixes the three editions below and the ordinary-English role statements. The intended use stays in the ClaimGraph.

Receiving use: decide which subjects the later pattern must keep distinct.

Retain:
- OMG BPMN 2.0.2 (January 2014), §10.1: its workflow-structure claim changes the design-description side.
- W3C PROV-O Recommendation (30 April 2013), §3.1: its Activity claim supplies the performed-occurrence contrast.
- W3C SOSA/SSN Recommendation (19 October 2017), §4.3.2.2: Observation supplies an action-changing counterexample—an act that follows a Procedure and yields a Result, not a workflow graph.

Exclude for now:
- thermodynamic-process literature: no inspected claim changes this stated use.

Known limit: service commitments are outside this cut.
Reopen if: the use adds physical transformation or service commitments, a relied edition changes the relevant claim, or a known counterexample no longer fits.
Search policy: none needed for this bounded question.

The resulting SourceCutNote is identified by that ClaimGraph, the stated receiving question, and the named reading scheme. Because this cut turns on the difference between a designed workflow and a performed occurrence, the project recovers any disputed process reading through ordinary F.0.1 while inspecting source roles, before stabilizing the cut. It adds an F.17 cell afterward only if later reuse, a claim, a named receiver, or an actual relation needs one.

#Portable first-hour case — function-to-module allocation

“First hour” means a compact entry slice, not a deadline or completeness claim.

Receiving question. Which current FPF sources must a Systems Engineering author use to prepare a first function-to-module allocation teaching slice without collapsing functions into modules? The project identifies this sentence as one exact question before treating the note as a C.2.1 episteme; that question is its EntityOfConcern.

Receiving use. Prepare a slice that helps a practitioner generate and compare candidate bearers, modules, allocations, interfaces, and trade-offs instead of copying functions into a component list or selecting familiar bearers first. This use stays in the note's ClaimGraph.

Effective ReferenceScheme. FPFCoreReferenceScheme, applied to the FPF August 2026 edition and the exact section locators below.

Retained sources and answer-changing roles. All five are exact passages in that edition.

1. A.6.F §§4.2 and 4.5. Separates the possible subjects hidden by function-like wording and requires function, bearer, flow, module allocation, and interface claims to remain distinct. This blocks the one-function-one-component shortcut.
2. A.6.M §§4 and 4.3. Treats module use as claim content over exact holons, allows many-to-many or still-unallocated functional claims, and requires an actual interface specification when compatibility or substitution is claimed. This changes what an allocation row must show.
3. C.30.TFS-REL §4.2. Relates functional structure to selected transformation-flow structure without identifying them. This exposes candidate flow topology, crossings, and correspondence limits that can change bearer placement.
4. C.31 §4.5. Makes function-module alignment, interface burden, and flow-boundary alignment separate characteristics rather than one modularity score. This changes the trade-offs the comparison must expose.
5. C.32 §§4–5. Starts candidate synthesis from functional demand and candidate bearers, keeps materially different configurations visible, and records expected gain, known loss, constraints, and source-return conditions. This prevents the source cut from pretending to choose the architecture.

Deliberate limits. The cut claims neither an exhaustive survey of allocation algorithms nor one module taxonomy or cross-sector optimum. It does not decide the final DPF pattern identity. The campaign-specific guide and research-source pilot remains in FPF-DPF-CLAIM-PLACEMENT-CAMPAIGN/PILOT-SYSTEMS-ENGINEERING-FUNCTION-TO-MODULE-ALLOCATION.md; it is not a hidden dependency of this portable example.

First result. One SourceCutNote whose ClaimGraph contains the five roles, use, limits, and reopen conditions; whose EntityOfConcern is the stated question; and whose effective scheme is FPFCoreReferenceScheme for FPF August 2026. The later comparison must expose unsupported capabilities, unallocated functions, unresolved interfaces, alternatives, trade-offs, and accepted losses.

Reopen when. A relied FPF passage changes, the question expands to external allocation algorithms or another domain, or the intended DPF use changes the required answer or boundary.

#Readable reasoning moves

• Retain: “This exact source stays because this inspected claim changes the answer in this way.”
• Exclude: “No inspected claim from this source changes the stated use; record the exclusion and what would reopen it.”
• Return a gap: “This unavailable or uninspectable source may be load-bearing; the cut remains limited here.”
• Keep meanings local: “Selection puts both sources in view; it does not say their terms are identical or related.”
• Use search assistance: “The ranking tells us what to inspect next; the source claim decides whether it enters the cut.”
• Reopen: “This question, use, relied claim, rival, counterexample, or transfer boundary changed, so select again.”

#Didactic distillation

State and independently identify the question; keep the later use in the claims. Keep a source because an inspected claim can change the answer, expose a rival or counterexample, or mark a transfer limit. Return one finite SourceCutNote whose ClaimGraph carries those roles, exclusions, limits, and reopen conditions, whose EntityOfConcern is the exact question, and whose named effective scheme resolves the question and exact editions. Search scores may guide inspection; they do not admit or exclude a source. Stop when additional candidates do not change the answer.

#Bias-Annotation

• Gov: Authority, popularity, international status, or sponsorship does not decide membership; the receiving question and inspected claims do.
• Arch: The method keeps source roles explicit and the active cut small without claiming exhaustive coverage.
• Onto/Epist: A source, edition, source claim, local meaning, source-cut episteme, and representation remain different.
• Prag: Direct use of one identified source is the cheap exit. Search assistance earns its cost only when it improves candidate inspection.
• Did: A one-screen representation protects working memory; detailed analysis stays with the receiving work.
• Scope: Practitioners use F.1 to select sources, not to establish truth, adequacy, semantic relations, synthesis, reliance, or assurance.

#Conformance Checklist

#Static checks

• SCR-F1-S01 (Question and use). The receiving question is independently identified as the note's exact EntityOfConcern; the intended use and the source difference that can change the answer remain in its ClaimGraph.
• SCR-F1-S02 (Exact sources). Every retained source and edition is recoverable.
• SCR-F1-S03 (Answer-changing roles). Every retained source has an inspected role; exclusions and source gaps are explicit.
• SCR-F1-S04 (Finite and inspectable). The cut can be held in view without dropping a known answer-changing source merely to satisfy a count.
• SCR-F1-S05 (C.2.1 identity and one result). The SourceCutNote's ClaimGraph, exact receiving-question EntityOfConcern, and effective ReferenceScheme are all recoverable. The scheme resolves the question, exact source editions, and role claims. A file, source list, one-screen form, or question-and-use bundle supplies none of these values by form and does not become another result kind.
• SCR-F1-S06 (Locality). No cross-source equivalence, merge, or relation is asserted by selection.
• SCR-F1-S07 (Temporal honesty). Designed and performed source claims remain distinct when the difference affects the answer.
• SCR-F1-S08 (Family neutrality). No meaning, relation, or membership decision relies on a domain-family label.
• SCR-F1-S09 (Named search policy). Any material search aid has a recoverable policy, corpus, method or model edition, and interpretation.
• SCR-F1-S10 (No algorithmic gate). A search reading changes the cut only after inspection of source claims.
• SCR-F1-S11 (Reopen conditions). The result says which question, use, edition, rival, counterexample, or transfer-boundary change reopens it.
• SCR-F1-S12 (Domain-method boundary). A required systematic or appraisal-bearing review remains with its domain method.
• SCR-F1-S13 (SoTA source roles). A cut used for a SoTA claim assigns every retained source one of the comparison roles defined in E.8:11, records it in plain wording, and says which retained contributions can change the answer. F.1 does not restate or supersede the E.8 definition.
• SCR-F1-S14 (No authority or currentness laundering). Official status, popularity, maintained status, citation count, publication date, freshness, or academic praise does not promote a source into the best-known line. An official or widespread source may still earn that role from its substantive comparison. Catalogue and publisher pages support identity/currentness only unless their substantive claims independently enter the comparison.
• SCR-F1-S15 (SoTA one-source guard and gap). A one-source SoTA cut is used only when that source critically synthesizes the serious alternatives and no known action-changing rival or counterexample remains hidden. Otherwise the cut retains the necessary comparison or returns a source gap.

#Regression checks

• RSCR-F1-E01 (Edition change). Recheck only answer-changing claims that used the changed edition.
• RSCR-F1-E02 (Use change). Recheck which sources, rivals, counterexamples, and limits matter when the question or use changes.
• RSCR-F1-E03 (New false friend). Add a concise warning when recurrent wording confusion changes the receiving answer.
• RSCR-F1-E04 (Bounded cut). Remove non-changing sources or split genuinely different questions when the active cut can no longer be inspected together.
• RSCR-F1-E05 (Search drift). A changed taxonomy, corpus, model, descriptor, scale, distance, threshold, or rank cannot silently change membership.

#Common Anti-Patterns and How to Avoid Them

#Consequences

The source cut becomes small enough to inspect, while a decisive rival, counterexample, or transfer limit cannot be discarded merely to satisfy a count. Later work can recover why each source was present, which edition was used, what the cut deliberately omitted, and what change reopens it.

The cost is explicit judgment. The author must say what each source can change and disclose a load-bearing gap instead of treating absence as evidence against a claim. Unknown rivals can still be missed, so citation chasing, expert leads, search aids, or a domain review method may remain necessary. Their outputs are candidates until source claims are inspected.

The cut is not evidence that its sources are true, sufficient, representative, mutually compatible, or safe to rely on. Those conclusions belong to the receiving synthesis, domain evidence method, F.9 relation, A.10 reliance account, or B.3 assurance claim.

#Changes that reopen or revise a cut

1. A source edition changes a relied claim, limit, or distinction.
2. The receiving question or intended use changes.
3. A new rival explanation, action-changing counterexample, or transfer limit appears.
4. A formerly retained source no longer changes the answer.
5. A language edition changes distinctions used by the result; treat editions separately unless the source supplies a mapping that preserves them.
6. Search-policy drift reveals a candidate but never changes membership without source inspection.
7. A later F.9 relation is proposed; keep source selection unchanged unless that proposal changes the source roles themselves.

#Rationale

Source selection for conceptual work is neither statistical sampling nor a race to the largest bibliography. The receiving question determines which source differences matter. A source belongs in the active cut when an inspected claim can change the answer, expose a rival or counterexample, or mark where transfer fails.

This keeps the useful part of purposive and iterative sampling—selection for a stated analytic purpose—without importing another field's population, richness scale, saturation claim, or count convention. It also keeps the useful part of systematic-search and AI-assisted screening—recoverable searches and efficient candidate discovery—without treating search coverage, rank, or reporting conformance as source adequacy.

#SoTA-Echoing

These comparisons change the source-selection method and its stops; they do not make a SourceCutNote a synthesis result or assurance claim.

#Relations

• E.8:11 owns the canonical SoTA definition, comparison-role meanings, and positive comparison contract. F.1 prepares only the question-relative source cut and records those roles for the receiving comparison.

Builds on.

• C.2.1 identifies the SourceCutNote from its ClaimGraph, the exact receiving question as EntityOfConcern, and its effective ReferenceScheme, and distinguishes that episteme from its representation.
• F.0.1 supplies a plain local reading during selection when a candidate's answer-changing role depends on a disputed expression.
• F.17 supplies a durable local-sense cell after selection only when later reuse, a claim, a named receiver, or an actual relation needs one.
• A.11 supplies the parsimony test; finiteness does not replace relevance with a fixed count.
• E.15 supplies affected-premise reopening across source editions.

Related later uses.

• F.0.2 can compare or synthesize the exact sources, roles, limits, and reopen conditions returned here.
• F.9 defines any actual relation between distinct recovered local senses; F.1 asserts none.
• G.2 supplies the broader refreshable SoTA-pack method when that heavier result is required.
• Use A.10 for reliance and B.3 for assurance; source selection establishes neither.
• An author of a subject pattern or DPF may use the source cut directly when an inspectable source basis is needed but no cross-source synthesis is current.

#F.1:End

#F.2 — Term Harvesting & Normalisation

“Harvest the source’s own words, recover what they mean there, and stop before comparison.” Status. Architectural pattern. Depends on. F.1 Question-Relative Source Selection; F.0.1 Source-Local Meaning Recovery; E.10.D1 Recovering What “Context” Means in Use; A.7 Strict Distinction; A.11 Ontological Parsimony. Coordinates with. F.3 Source-Local Sense Clustering; F.17 for an optional durable cell and basis relation; F.4 SystemRoleKindDescription when the recovered subject is a local system-role kind; F.9 only for an actual relation between distinct local meanings. Aliases (informative). source-local harvesting; local normalisation.

#Intent & applicability

Intent. Turn usage in an exact source and edition into a small, auditable set of source-local expressions and one-sentence meaning claims. Keep the source’s idiom, help a cold reader, and withhold every cross-source conclusion.

Use this when. F.1 has selected a source because it can change the receiving answer, and the reader needs the actual words that carry its contribution. Re-enter when the selected edition, passage, language, or interpretation basis changes enough to change meaning.

Do not use this when. The words are already recovered precisely enough for the receiving question, or the current task is to relate two local meanings; use F.9 for that relation. F.2 creates no global term, kind, assignment, behaviour, obligation, or storage scheme.

#Problem Frame

Three mistakes recur even after the right sources are selected:

1. Word-centrism. A string such as process, role, or service is treated as though it carried one meaning everywhere.
2. Over-normalisation. Spelling or morphology is forced into a house style and source-specific cues disappear.
3. Premature structure. A short lexical note quietly acquires behavioural, deontic, measurement, or kind claims that the source passage does not establish.

F.2 prevents these mistakes by tying each expression and local-sense claim to the exact source basis that supports it.

#Forces

#Core idea (didactic)

For each needed use, name the exact source and edition, the relevant passage, and the effective U.ReferenceScheme under which the passage is being read. Harvest an attested LocalExpression, choose a minimally edited Local Normal Form (LNF), add Tech and Plain labels, and state the LocalSenseClaim in one sentence.

That is the ordinary F.2 result. If later work needs a durable address, F.17 may represent it as SchemeSenseCell = <ReferenceScheme, LocalExpression, LocalSenseClaim> and record the basis relation. The cell is optional and does not replace the source, passage, or claim. F.2 establishes no relation to another source-local meaning.

#Minimal vocabulary (this pattern only)

• Exact source basis — the selected source, edition or version, relevant passage, and effective U.ReferenceScheme needed to recover this use.
• Attested phrase — a short verbatim cue showing how the expression is used in that source.
• LocalExpression — the exact expression whose source-local meaning is being recovered.
• Local Normal Form (LNF) — the minimally edited surface used to cite that expression while preserving the source’s spelling, hyphenation, and casing.
• Tech and Plain labels — an engineer-facing label faithful to the source and a newcomer-facing label that does not add scope.
• LocalSenseClaim — one sentence saying what the expression means in this source use, at the least generality needed by the receiving question.
• Source-local lexical note — the exact source basis, expression and LNF, labels, claim, and one or two attested cues. This is F.2’s ordinary outcome.
• Homonymy signal — notice that the same string supports different local claims; this notice is not a relation between those claims.
• SchemeSenseCell — F.17’s optional three-part address, used only when durable reuse needs it.

#Solution — three mental moves

#Move A — Recover the basis

Ask: “Which exact source use am I reading, and under which interpretation rules?”

Name the source and edition, locate the passage, and recover the effective reference scheme with F.0.1. Take one or two representative phrases. If you cannot identify that basis, do not harvest the word yet.

#Move B — Name the local meaning faithfully

Ask: “How does this source itself say it?”

Choose the LNF with minimal editing. Keep an idiomatic Tech label, add a genuinely explanatory Plain label, and write one LocalSenseClaim. Prefer the source’s head noun and meaningful modifiers. Put behavioural equations, obligations, measurements, and kind criteria under their direct patterns rather than inside the lexical note.

#Move C — Fence the result

Ask: “What has this source use not established?”

Refuse to infer sameness, substitution, hierarchy, or transfer across sources; refuse to merge a materially different edition or language use by spelling alone; and refuse to treat the expression as the value that the substantive claim is about. Record an itch to compare for F.9, but do not settle it in F.2.

#Guard-rails (normative, lightweight)

1. Basis visible. Every harvested expression MUST name the exact source and edition and the effective reference scheme needed to recover its meaning.
2. Idiomatic normalisation. LNF MUST preserve meaningful source spelling, hyphenation, casing, and modifiers with minimal edits.
3. Two registers. Each note SHOULD carry Tech and Plain labels; the Plain label must explain rather than broaden.
4. Minimal generality. The LocalSenseClaim MUST say no more than the source use and receiving question require.
5. Category hygiene. A lexical note MUST NOT stand in for behaviour, obligation, measurement, kind, assignment, Work, or evidence.
6. No cross-source claim. F.2 MUST NOT assert equivalence, subsumption, similarity, permission, or transfer between local meanings.
7. Edition and language honesty. When edition or language changes meaning, recover a distinct source-local claim and interpretation basis; do not manufacture a universal “new Context” rule.
8. Parsimony. Keep the head expressions that affect F.3, F.4, F.8, or a real F.9 question; omit an unused tail.

#Micro-examples

Each item is one source-local lexical note. Their proximity asserts no relation.

• BPMN 2.0 (2011), effective BPMN scheme — expression and LNF process; Tech process; Plain workflow graph; claim: “A graph of flow nodes and sequence flows specifying orchestration among participants.”
• PROV-O (2013), effective PROV scheme — expression and LNF activity; Tech activity; Plain time-bounded occurrence; claim: “An occurrence that uses or generates entities and may be associated with agents.”
• ITIL 4 (2020), selected service-management use — expression and LNF service-level objective; Tech SLO; Plain service target; claim: “A target value or range for a service characteristic.”
• NIST RBAC (2004), RBAC scheme — expression and LNF role; Tech access role; Plain permission grouping; claim: “A named grouping of permissions used in access-control assignment.”
• SOSA/SSN (2017), SOSA scheme — expression and LNF observation; Tech observation; Plain act of observing; claim: “An act applying a procedure to a feature of interest to obtain a result.”
• IEC 61131-3, cited edition and runtime passage — expression and LNF task; Tech task; Plain scheduled program execution; claim: “A cyclic or event-driven runtime unit that invokes programs.”

#Didactic heuristics (informative)

• Keep the source in your inner speech: say “process in BPMN 2.0” and “activity in PROV-O”.
• Prefer the source’s head noun and meaningful modifier: do not shorten service-level objective to objective.
• Preserve spelling or case when it carries source signal.
• Compress from attested use, not from a neighbouring theory.
• When role, function, process, or another trigger word appears, recover the actual subject before choosing a label.

#Anti-patterns & remedies

#Worked examples

#Enactment and sensing

The BPMN, PROV-O, SOSA/SSN, and ITIL notes above remain four separate source-local claims. They let a writer say “compare an SOSA observation result with the ITIL service target” while withholding any claim that BPMN process and PROV activity are the same.

#Control and services

• State-space control source, cited passage and scheme — actuation; Plain control output; claim: “A signal applied to influence plant state or output.”
• IEC 61131-3, cited runtime passage and scheme — task; Plain scheduled program execution; claim as above.
• ITIL 4 (2020), incident-management use — incident; Plain reported service disruption; claim: “An unplanned interruption or reduction in service quality.”

This prevents a plant fault from becoming an ITIL incident merely because a writer wants one word for both.

#Kind, method, and knowledge sources

• OWL 2 profile source — subClassOf; Plain class inclusion; claim: “Every instance of the first class is an instance of the second.”
• FCA source — formal concept; Plain extent–intent pair; claim: “A maximal object–attribute pair under the stated Galois connection.”
• SPEM 2.0 and ISO 24744 sources — method; Plain way of doing; claim recovered from the cited method passage.
• SOSA/SSN (2017) — procedure; Plain observation recipe; claim: “A description of how an observation may be carried out.”

The notes do not turn an FCA concept into a root kind or a procedure description into a Method. Those are separate claims under their direct patterns.

#Safe reasoning moves

1. Localise. Hear the expression only in the exact source use now under examination.
2. Recover. Identify the edition, passage, effective scheme, and source-local claim.
3. Normalise minimally. Choose an LNF that preserves the source’s idiom.
4. Explain twice. Keep an idiomatic Tech label and a genuinely helpful Plain label.
5. Check scope. Tighten any sentence that says more than the passage supports.
6. Signal homonymy. Note repeated spelling without claiming a relation.
7. Stop. When the local note is clear enough for the receiving question, do not add a cell or comparison merely for completeness.
8. Address only when needed. Use F.17’s three-part cell when later reuse requires stable addressability.

#Relations

Builds on:

• Use F.1 Question-Relative Source Selection to recover the exact sources, editions, answer-changing contributions, and receiving question.
• Use F.0.1 Source-Local Meaning Recovery to recover the exact source-local claim.
• Use E.10.D1 when vague context wording hides source, scheme, scope, situation, or use.
• Use F.17 for a durable SchemeSenseCell and basis relation only when later reuse needs that address.

Constrains:

• F.3 clusters exact expressions and local claims under one effective scheme; it does not infer sameness across sources.
• F.4 may cite an exact F.17 cell when a local system-role-kind description needs it; a harvested expression establishes no kind.
• F.9 receives exact local meanings only when a proposed use needs an actual relation between them. F.2 supplies no Bridge, equivalence, direction, or use licence.

Used by. Part C patterns may cite the exact source expression and local-sense claim. The direct subject pattern still defines or constrains the value in the current claim.

#Migration notes

1. New edition. Recover the changed passage and scheme; keep the earlier note if its source use remains relevant.
2. Idiomatic correction. Repair the LNF without silently changing the LocalSenseClaim.
3. Ambiguity in one source. Recover two claims when selectional frames or entailments differ; F.3 tests the split.
4. Language change. Determine whether the language edition changes source wording, reference scheme, or both; do not merge by translation alone.
5. Tail pruning. Remove working notes that do not affect an active question; preserve cited source evidence elsewhere as required.
6. Tool dialect. Keep it as one exact source basis and do not let it define other sources’ idiom.

#Acceptance tests

#Static conformance

• SCR-F2-S01 (basis). Every note names the exact source and edition and the effective scheme required to recover the claim.
• SCR-F2-S02 (idiomatic LNF). Each LNF preserves meaningful spelling, hyphenation, casing, and modifiers.
• SCR-F2-S03 (two registers). Tech is faithful and Plain is explanatory without added scope.
• SCR-F2-S04 (lexical boundary). No note substitutes for behaviour, obligation, measurement, kind, assignment, Work, or evidence.
• SCR-F2-S05 (no cross-source claim). F.2 asserts no equivalence, hierarchy, transfer, or permission between local meanings.
• SCR-F2-S06 (minimal generality). Each LocalSenseClaim is no broader than its source use and receiving question.

#Regression

• RSCR-F2-E01 (edition change). A changed edition produces a newly recovered claim only where meaning changed; earlier source identity remains visible.
• RSCR-F2-E02 (normaliser stability). LNF edits do not silently widen or narrow the claim.
• RSCR-F2-E03 (language honesty). Translation does not create unproved sameness.
• RSCR-F2-E04 (no stealth relation). New notes still contain no cross-source identity or use claim.
• RSCR-F2-E05 (head-term focus). The working set remains small and tied to actual downstream questions.

#Didactic distillation

“Name the exact source and edition, find the passage, and say under which reference scheme you are reading it. Keep the source’s own expression, add a faithful Tech label and a helpful Plain label, and state its local meaning in one sentence. Stop there. The same spelling elsewhere proves nothing. Use F.17 only if you need a stable address, and use F.9 only if a real relation between two local meanings must be tested.”

#F.2:End

#Source-Local Sense Clustering

“Under one explicit interpretation basis, merge aliases that make the same local claim and split uses that do not.” Status. Architectural pattern. Depends on. F.1 Question-Relative Source Selection; F.2 Term Harvesting & Normalisation; F.17 for the optional three-part local-sense cell; E.10.D1 Recovering What “Context” Means in Use; A.7 Strict Distinction; A.11 Ontological Parsimony. Coordinates with. F.4 SystemRoleKindDescription; F.7 Concept-Set Table; F.8 Mint or Reuse Decision; F.9 only when two exact local meanings need a tested relation. Aliases (informative). source-local clustering; sense consolidation.

#Intent & applicability

Intent. Consolidate the expressions recovered by F.2 into a small set of source-local meaning claims under an explicit source and edition and an effective reference scheme. Merge aliases that the source uses interchangeably; split uses whose argument patterns, entailments, or practical consequences differ. The result stays local to its stated interpretation basis.

Use this when. Several expressions or uses from a selected source may carry one meaning, or one expression may carry several meanings that matter to the receiving question. Repeat when a changed passage, edition, or interpretation basis changes that partition.

Do not use this when. The local meaning is already clear enough, or the question is whether two meanings from distinct interpretation bases are related. That is an F.9 question. F.3 creates no kind, assignment, cross-source sameness, or permission.

#Problem Frame

Source-local lexical notes often over- or under-differentiate meaning:

1. Over-split: an abbreviation and its full form are treated as different meanings despite interchangeable source use.
2. Under-split: one gloss covers incompatible argument patterns or conclusions.
3. Source drift: different chapters, editions, or translations are blended without checking whether the interpretation basis changed.
4. Didactic drift: the Tech and Plain labels begin to teach different things.

F.3 repairs this by testing usage under the exact source basis rather than by counting strings.

#Forces

#Core idea (didactic)

Cluster by source use, not by spelling. Under one explicit interpretation basis:

• Same local meaning: expressions are interchangeable in the relevant source passages and no source-grounded test makes them support different conclusions.
• Different local meanings: their argument patterns, entailments, temporal stance, or practical consequences differ.

The cluster’s outcome is a LocalSenseClaim, with a Tech and Plain label pair, supporting expressions, and an optional counterexample. If durable reuse needs an address, use F.17’s SchemeSenseCell = <ReferenceScheme, LocalExpression, LocalSenseClaim>. The cell has three parts; it is not a two-part pair and does not make the claim global.

#Minimal vocabulary (this pattern only)

• Interpretation basis — the exact source and edition and the effective U.ReferenceScheme used to understand the selected passages.
• Unit — a source-local lexical note from F.2.
• LocalSenseClaim — the one-sentence claim that a cluster of source uses supports under that basis.
• Supporting expressions — the F.2 expressions consolidated by the claim.
• Counterexample — a short source-grounded use that must not be covered by this claim.
• SchemeSenseCell — F.17’s optional stable address; it carries the scheme, an expression, and the local-sense claim.
• Usage cue — collocation, paraphrase, argument pattern, or entailment that suggests a merge or split; a cue is evidence to inspect, not a decision by itself.

#Solution — how to think about clustering

#Consolidate source-blessed aliases

If spelling variants, abbreviations, or explicit synonyms are interchangeable in the relevant passages and do not change a conclusion, let one LocalSenseClaim cover them.

Example: ITIL’s service-level objective and SLO may support one local claim when the cited edition uses them interchangeably.

#Split incompatible argument patterns

Split when the same head takes materially different participants or occupies a different place in the source’s propositions.

Example: a BPMN event as a diagram node is not an outage occurrence merely because a tutorial uses the same word narratively.

#Split divergent entailments

If one use entails occurrence in time and another entails a design structure or capability, the uses support different claims.

Example: a PROV activity is a time-bounded occurrence; that claim does not describe a static algorithmic capability.

#Prefer the coarsest adequate partition

Merge candidates when no source-grounded test relevant to the receiving question distinguishes them. Split when a concrete counterexample would otherwise be admitted. Do not split merely to fill a taxonomy.

#Keep labels honest

Keep the Tech label in the source’s idiom. Make the Plain label explain the same claim to a careful newcomer. Neither label is the value being described, and neither may widen the claim.

#Address only recurring uses

Ordinary prose may cite the source, expression, and claim directly. Mint an F.17 cell only when the local meaning must be reused, compared, or traced repeatedly.

#Outputs

For each interpretation basis used by the receiving question, F.3 yields a small set of local-sense claims. Each has:

• a Tech and Plain label pair;
• a one-sentence LocalSenseClaim;
• the supporting expressions and passages;
• an optional counterexample that sharpens the boundary;
• an optional F.17 SchemeSenseCell when durable addressability is worth its cost.

These are reference points for reasoning. They are not mandatory records, and their proximity creates no relation.

#Invariants

1. Basis explicit. Every LocalSenseClaim names the source and edition and the effective reference scheme needed to interpret it.
2. Parsimony. Prefer the coarsest partition that preserves source-grounded differences relevant to use.
3. Idiomatic Tech. The Tech label remains source-faithful.
4. Didactic Plain. The Plain label aids comprehension without adding scope.
5. Usage first. Claims follow source passages, not imported taxonomies.
6. Counterexample rule. A source-grounded counterexample that matters to the receiving question forces a split or tighter claim.
7. Category boundary. A local-sense claim does not establish behaviour, obligation, measurement, kindhood, assignment, or Work.
8. No relation by clustering. F.3 establishes no cross-source identity, hierarchy, Bridge, substitution, or permission.

#Self-checks

• Same-conclusion test. Would the candidate uses ever change a source-grounded conclusion relevant here? If not, merge.
• Argument probe. Substitute the participants from one use into the other. If the source proposition fails, split.
• Entailment probe. Does one use imply an occurrence while the other implies a description, kind, or status? Split.
• Label inversion. Read the Plain label alone. If it invites a broader claim, tighten it.
• Counterexample ping. State a short use that must be excluded. If it falls inside the claim, refine the boundary.
• Memory rule. If a careful reader cannot recall the few relevant claims, the partition is probably too fine.

#Anti-patterns & remedies

#Local-Sense Cards

An optional one-glance card may show:

• source and edition;
• effective reference scheme;
• Tech and Plain labels;
• LocalSenseClaim;
• supporting expressions and passages;
• counterexample;
• F.17 cell, only when one is actually used.

The card is a display. Its fields do not create a new object or relation.

#Worked examples

#BPMN 2.0

Process (workflow graph). Claim: a graph of flow nodes and sequence flows that specifies orchestration among participants. Supporting expressions may include process, process model, and business process where the cited passages use them for the diagram. Counterexample: “this process took five minutes” describes an occurrence, not this design claim.

Event (node). Claim: a typed diagram node marking starts, ends, or intermediates. Counterexample: “the outage event happened at 13:05” describes an occurrence.

#PROV-O

Activity. Claim: a time-bounded occurrence that uses or generates entities and may be associated with agents. Counterexample: a sorting algorithm as a reusable way of doing is not an occurrence.

Agent. Claim: an entity that bears responsibility for an activity’s effects under the PROV scheme. Counterexample: an RBAC permission role is not thereby a PROV agent.

#ITIL 4

Service-level objective and SLO. One claim may consolidate the full form and abbreviation when the cited edition uses them interchangeably: a target value or range for a service characteristic. Counterexample: an observed availability value is evidence, not the target.

Incident. Claim: an unplanned interruption or reduction in service quality. Counterexample: a plant sensor fault is not an ITIL incident unless another relation is separately established.

#SOSA/SSN

Observation. Claim: an act applying a procedure to a feature of interest to obtain a result. Counterexample: “20 °C” is a result value, not the observation act.

#OWL 2

SubClassOf. Claim: every instance of one class is an instance of another. Counterexample: rdf:type relates an individual to a class.

EquivalentClasses. Claim: two class expressions have the same instances under the OWL semantics. Counterexample: owl:sameAs is individual identity.

#IEC 61131-3

Task. Claim: a cyclic or event-driven runtime unit that invokes programs. Counterexample: a control algorithm or program description is not the task occurrence.

#Safe reasoning moves

1. Alias consolidation. Merge expressions only when the source uses them interchangeably for the current question.
2. Argument split. Split uses whose required participants differ materially.
3. Entailment split. Split when the uses support different conclusions.
4. Parsimony merge. Merge when no relevant source-grounded test distinguishes the candidates.
5. Counterexample trigger. Tighten or split a claim that admits a concrete excluded use.
6. Label check. Tech stays idiomatic; Plain explains without widening.
7. Address check. Create an F.17 cell only when recurring use needs a stable address.
8. Edition check. Re-evaluate the interpretation basis before carrying a claim across an edition change.
9. Coverage ping. If a frequent source expression that matters to the receiving question has no local-sense claim, check whether one useful cluster is missing.
10. Stop rule. Do not infer a relation to another local meaning from clustering alone.

#Relations

Builds on:

• Use F.1 for the finite source cut and receiving question.
• Use F.2 for exact expressions and source-local lexical notes.
• Use F.17 for <ReferenceScheme, LocalExpression, LocalSenseClaim> only when a stable address is needed.
• Use E.10.D1 to keep source, scheme, claim scope, model use, and working situation distinct when context wording is encountered.

Constrains:

• F.4 may cite an exact cell but never infers a local system-role kind from it.
• F.7 displays exact local claims or cells and already obtaining relations for one stated comparison or use; F.3 clustering creates neither a row relation nor permission.
• F.8 compares proposed wording with exact existing designations and claims without treating either as the value being named.
• F.9 tests a relation only between exact local meanings whose interpretation bases differ. F.3 establishes no Bridge, cross-source sameness, substitution, or use licence.

Used by. Part C patterns may cite a local-sense claim under its exact source and scheme; the direct pattern still defines or constrains the substantive value or relation in the example.

#Migration notes

1. Usage clarifies. Merge only when the source-grounded distinction test fails.
2. Usage diverges. Split and add a counterexample when argument patterns or entailments pull apart.
3. Edition changes. Recover the changed basis and claim; do not automatically invent a new universal container.
4. Labels drift. Repair Tech or Plain without silently changing the claim.
5. Dormant claim. Omit it from the active comparison when it no longer changes the receiving answer; do not fold it into another claim without evidence.
6. Bridge temptation. Record the question for F.9; do not answer it in F.3.

#Acceptance tests

#Static conformance

• SCR-F3-S01 (basis). Every LocalSenseClaim names its source and edition and the effective reference scheme.
• SCR-F3-S02 (labels). Tech and Plain denote the same bounded claim.
• SCR-F3-S03 (fidelity and time stance). Each claim is grounded in cited source use, preserves any source-grounded design-time, run-time, or other temporal distinction, and contains no imported substantive calculus.
• SCR-F3-S04 (parsimony). The claim set is small enough for the receiving question.
• SCR-F3-S05 (counterexample). Ambiguous heads have a concrete boundary test.
• SCR-F3-S06 (no inferred relation). Clustering asserts no cross-source identity, hierarchy, transfer, or permission.

#Regression

• RSCR-F3-E01 (merge soundness). Every merge has a failed relevant distinction test.
• RSCR-F3-E02 (split necessity). Every split cites an argument, entailment, temporal, or counterexample difference.
• RSCR-F3-E03 (edition honesty). Changed editions are not silently absorbed into an old claim.
• RSCR-F3-E04 (label stability). Label changes do not change the claim unnoticed.
• RSCR-F3-E05 (downstream continuity). After a split or merge, direct citations and any F.17 cells remain unambiguous; no silent aliasing occurs.

#Didactic close

“Start with one explicit source and interpretation basis. Merge aliases only when the source uses them interchangeably and no relevant conclusion changes. Split uses when their participants, entailments, or time stance differ. Give each result one faithful Tech label, one helpful Plain label, and a short counterexample. Use an F.17 cell only when recurring work needs the address. Nothing in this clustering makes two sources the same; test that separately in F.9.”

#F.3:End

#SystemRoleKindDescription — Describing an Exact System-Role Kind

Type: Definitional (D) Status: Stable in the current FPF Normativity: Normative unless marked informative

#Use This When

Plain name. Description of a system-role kind.

Use F.4 when a project needs a short, reusable description that makes one exact local system-role kind recognizable, teachable, and checkable. The described kind is a C.3 kind whose candidates must first be independently admitted as U.System. A candidate may be, for example, a person, team, organization, or non-human technical object; SystemRole does not mean “technical system only.”

Typical moments:

• a project has a durable kind name such as ReviewerSystemRole, OperatorSystemRole, InspectorSystemRole, TransformerSystemRole, or ShipyardCoordinatorSystemRole, but readers cannot recover which systems are candidates, what condition distinguishes members from relevant non-members, what change would make it another kind, the current KindSignature, or the work-facing boundary;
• a MethodDescription names a required system-role kind, but readers cannot tell which exact local kind must classify a candidate before an assignment can be checked;
• a kind name is starting to carry assignment, capability, Method, Work, permission, responsibility, evidence, publication, or status claims that belong elsewhere; or
• source prose says that a report, standard, dataset, theorem, dashboard, publication, or requirement has a “role”, and the writer must recover whether that wording denotes a system-role kind at all.

Primary EntityOfConcern. A SystemRoleKindDescription is one U.Episteme constituted under C.2.1. Its exact EntityOfConcern is one local system-role kind. Its ClaimGraph makes the C.3 recovery basis readable: the candidate domain, operative membership condition, intended member/non-member boundary, and continuity rule. It also names the current KindSignature edition, effective U.ReferenceScheme, useful source or practice provenance, and only the neighboring relations needed by the described use. Provenance helps readers locate and compare the definition; it does not identify the kind. The description is not the kind, a classification judgment, assignment occurrence, holder system, capability, MethodDescription, performed Work, status-use relation, or publication form.

Primary working reader. The first reader is an engineer-manager, analyst, Method author, or pattern author who must help people recognize the kind while keeping kind, candidate classification, assignment, capability, Method, Work, evidence use, status use, and publication use distinct.

First useful move. Name the exact local system-role kind, say in ordinary words which systems can count and what separates a member from a relevant non-member, cite the current KindSignature, and state the change that would make it another kind. Add source or practice provenance only to help readers find and compare the definition. Keep the recognition explanation no longer than the next classification, assignment, Method, Work, naming, or cross-local claim needs.

What goes wrong if missed. A description card becomes a hidden procedure, staffing record, access policy, permission badge, responsibility claim, evidence relation, status assertion, or Work log. Then one word recreates a universal role ontology and a second role-like ontology for epistemes, publications, statuses, and relation positions.

What this buys. A project gets a compact, readable description while operational claims remain at their direct loci. The kind stays recognizable; classification and assignment stay checkable; capability, Method, Work, evidence, status, responsibility, and publication claims stay inspectable instead of being smuggled into the name.

Not this pattern when.

• If the current question is whether a local system-role kind exists, how it is identified, or whether one candidate satisfies it, use A.2 with C.3 and C.3.2.
• If the current question is whether one admitted system and one exact local kind participate in an obtaining assignment, use A.2.1.
• If one assignment may satisfy one state condition during a window, use A.2.5.
• If the current question concerns admission substitution, incompatibility, qualification, a bundle, or another relation among system-role kinds, use A.2.7.
• If the current question is capability, use A.2.2.
• If it is about a Method, MethodDescription, WorkPlan, or performed Work, use A.3 or A.15 and the direct neighboring pattern.
• If an episteme is used as evidence, source, standard, requirement, publication, assurance input, status bearer, gate input, or decision input, use the direct relation. Do not classify the episteme as a system-role holder by wording.
• If only a durable name is needed, use F.18.
• If the current question relates two exact local system-role kinds, use C.3.3. If it relates two exact source-local senses, address them as F.17 SchemeSenseCell values and use F.9. Scheme difference or shared spelling alone triggers neither relation.
• If bare role may mean a relation participant, declaration slot, representation position, ordinary wording, or another object, use E.10.ROLE and A.6.RSIR where relation recovery is needed.

#Problem Frame

A local system-role kind often needs a recognizable description before people can classify a candidate, assign a system, compare kinds, or use the kind in a Method condition. A name such as InspectorSystemRole is not self-explanatory. Readers need to know which systems are candidates, what condition distinguishes intended members from relevant non-members, when that distinction continues, which KindSignature states it, and where neighboring claims begin. Source or practice provenance can help them locate and compare that definition; it cannot decide kind identity.

The recurring failure is to make the description carry too much. A compact card is tempting: put kind, status, permission, responsibility, evidence, capability, Method, assignment, Work, and publication cues into one “assignable” template. That convenience creates duplicate ontology. A standard used as a requirement source becomes a “standard role”; a report used as evidence becomes an “evidence role”; an access-control label becomes a system-role kind; a kind name becomes proof of capability or performed Work.

F.4 instead treats the description as an episteme about one exact local kind. It may cite neighboring relations but does not absorb them.

#Problem

Without this pattern:

1. Description and kind collapse. The description is treated as the local system-role kind.
2. Description and classification collapse. A card is treated as proof that one candidate satisfies the kind criterion.
3. Description and assignment collapse. A kind name or card is treated as proof that one system has an assignment.
4. Description and capability collapse. A kind name is treated as evidence that a system can do the Work.
5. Description and Method collapse. Kind criteria become a hidden procedure or MethodDescription.
6. Description and performed Work collapse. A card is treated as evidence that Work happened.
7. Status and episteme uses become system roles. Publications, standards, datasets, claims, and statuses acquire fake system-role classifications because they matter to reasoning.
8. Relation positions become system roles. Participant meanings, declaration slots, interface places, and representation positions are mistaken for system-role kinds.
9. Same-spelled kinds collapse or fragment. Shared spelling is treated as proof of one kind, or a changed practice or source as proof of two, without comparing the candidate domains, operative membership conditions, member/non-member boundaries, and continuity rules.

#Forces

#Solution

Constitute one SystemRoleKindDescription through C.2.1. Its ClaimGraph describes one exact local system-role kind, and that kind is its EntityOfConcern. It makes the kind's candidate domain, operative membership condition, intended member/non-member boundary, continuity rule, current KindSignature, and effective U.ReferenceScheme recoverable. It may record source or practice provenance so readers can find and compare definitions, but provenance is not a kind-identity key. The description gives readers enough to recognize and check the kind while routing neighboring claims to their direct rules.

The following is a content checklist, not a relation signature or mandatory record.

Always make recoverable:

• the described local system-role kind;
• the candidate domain, operative membership condition, intended member/non-member boundary, and continuity rule;
• the current KindSignature edition and effective reference scheme;
• a short recognition explanation;
• the full A.1 range of possible candidate systems, using examples only when helpful;
• the smallest direct-feature criteria or invariants needed by the current use; and
• the explicit boundary: the description asserts no classification, assignment, capability, Method, Work, evidence, status, permission, responsibility, publication, or relation-position occurrence.

Add only when the current use depends on them:

• a SystemRoleAssignmentStatePredicate or state-relation reference under A.2.5;
• capability-condition references under A.2.2;
• Method or MethodDescription references under A.3 and A.15;
• durable-name or lineage references under F.18;
• C.3.3 or F.9 Bridge references; and
• a selected BoundedModelUseStructure only when that structure changes the described interpretation or receiving use.

These are claims or references in an episteme. They are not SlotSpec declarations and add no participant to U.SystemRoleAssignment or another relation. A card, table row, Method appendix, or pattern section may express the description. When availability matters, a separate E.24.PUB occurrence makes the exact description edition available through its publication form and carrier.

#Content Meanings

A quick local description may stop after the always-recoverable content. A consequence-bearing Work-admission use requires only the neighboring relations it actually needs.

#Description versus Neighboring Values

F.4 points to these loci; it does not copy their ontology.

Keep the description episteme, the exact local system-role kind it describes, the KindSignature that states the membership criterion, the effective scheme used to read the description, and any classification judgment about a candidate separate. Add an F.17 SchemeSenseCell only when a later use needs a stable local-sense address; cite a LocalSenseBasisRelation only when that relation actually obtains. An ordinary F.4 description requires neither.

#Positive Construction Rule

Write a description in this order:

1. Name the described local system-role kind and state its candidate domain, operative membership distinction, one useful member/non-member boundary, and continuity rule. Record source or practice provenance only when it helps the reader locate or compare the definition.
2. Name the current KindSignature edition and effective reference scheme.
3. Give one short recognition paragraph, including the broad A.1 system range when a cold reader could narrow it incorrectly.
4. State the smallest direct criteria or invariants that distinguish the kind.
5. State what the description does not assert about classification, assignment, capability, Method, Work, evidence, status, permission, responsibility, publication, or relation positions.
6. Add neighboring references only when the receiving use depends on them.
7. Use F.18 for a durable public name. Use C.3.3 only when an actual relation between exact local kinds is current; use F.9 only when the receiving claim relates distinct F.17 local-sense cells.

#Invariants

1. One described kind. A SystemRoleKindDescription describes exactly one local system-role kind.
2. Direct kind identity. The candidate domain, operative membership condition, intended member/non-member boundary, and continuity rule remain recoverable. A source, practice, taxonomy row, signature edition, or scheme helps locate, state, or interpret that basis; none decides identity by itself.
3. Description boundary. The description is a U.Episteme; it is not the kind, candidate, classification judgment, assignment, holder system, capability, Method, Work, or status-use relation.
4. System range. A candidate must independently pass A.1 as U.System. No description or kind name performs that admission, and SystemRole does not narrow the candidate to non-human technical systems.
5. No hidden assignment. Classification under a local kind neither creates nor proves a U.SystemRoleAssignment occurrence.
6. No hidden capability. Capability requirements may be cited, but the description proves no capability.
7. No hidden Method. Method requirements may be cited, but the description is not a MethodDescription.
8. No hidden Work. The description may support later Work-attribution checks, but it is not evidence that Work occurred.
9. No status or episteme-use fusion. Status, evidence, source, requirement, publication, and assurance uses remain direct relations, not another description branch.
10. Position discipline. Bare role that denotes participation, a declaration slot, interface place, or representation position is recovered through E.10.ROLE and A.6.RSIR rather than made a system-role kind.
11. Name after meaning. Durable naming follows F.18 only after the exact kind, description, scheme, and local sense are recovered.

#Reasoning Primitives

Use these schemas as thinking checks.

SystemRoleKindDescription D describes local system-role kind K
  -> D is a C.2.1 episteme about K; D is not K or a classification judgment.

Candidate system X satisfies the current KindSignature of K
  -> this may support a classification judgment about X and K;
     it creates neither an assignment nor performed Work.

Assignment A relates admitted holder system X to K
  -> A is an occurrence of an exact species under U.SystemRoleAssignment;
     D establishes neither A nor X's system admission.

D cites capability requirement CapReq or Method requirement MReq
  -> apply A.2.2 or the direct Method pattern; the citation proves neither result.

Source says “episteme X has role Y”
  -> use E.10.ROLE to recover the direct episteme-use relation or ordinary wording
     before considering any system-role kind or assignment.

#Worked Cases

#Pump Inspector System Role

PumpInspectorSystemRoleKindDescription is a C.2.1 episteme whose EntityOfConcern is the kind currently named PumpInspectorSystemRole. The practical distinction is simple: an admitted system counts when it obtains readings for the named pump and declared condition characteristics in the applicable inspection situation and returns the named pre-maintenance judgment from those readings. A maintenance technician, inspection robot, or service team can be a member; a report, or a system missing either condition, is a relevant non-member. PlantA-PumpInspector-KindSignature-v4 and Plant-A-Maintenance-Scheme state the current definition and interpretation. Plant A provenance locates that definition; it does not identify the kind. The same kind continues through an aligned edition while the candidate range and two-part distinction continue; a material change to either calls for another kind. Each predicate declaration supplies participant meanings and applicability, and the current case supplies the satisfying facts. Use A.6.F only if source wording first hides those claims behind function; it establishes neither predicate. If either predicate or its case facts cannot be recovered, record the exact A.6.RCD missing-governor or missing-information result instead of classifying the candidate.

The description says the kind concerns pump-condition inspection and does not itself denote repair. It may cite pump-inspection capability conditions or an inspection Method when a receiving Work claim needs them. Its boundary says that an inspection report is an episteme used through evaluation, evidence, source, or publication relations, not a system-role holder.

The description makes PumpInspectorSystemRole recognizable. It does not say that Robot-7 satisfies the kind, has an assignment, is capable of inspecting, has permission or readiness to inspect, enacted a Method, or performed Work. Those claims use C.3.2, A.2.1, A.2.2, A.2.8.PER, A.15, and the applicable evaluation or evidence relations.

#Reviewer System Role and Review Report

ReviewerSystemRoleKindDescription may describe the kind currently named ReviewerSystemRole. An admitted system counts when it compares the named pattern claims with each selected scale in the applicable review situation and returns the named reasoned judgment with the assessed values or defects. A person, team, or review service satisfying both conditions can be a member; a review report, or a system that merely comments without applying the scales, is a relevant non-member. PatternReview-2026-Reviewer-KindSignature-v2 states the current condition. The PatternReview source locates that definition; it does not identify the kind. The same kind continues only while the candidate range and substantive-review distinction continue under aligned editions. A.6.F is used only to unpack still-ambiguous function wording and establishes neither claim. If a predicate is missing, record the A.6.RCD missing-governor; if case facts are missing, record the corresponding unresolved result. This condition can be checked without asserting that any review appointment or dated review Work already exists.

Alice's classification under that kind, any review appointment she holds, any dated review Work she performs, and any report used as evidence remain four separate claims. This compact description names none of their occurrence identities.

Use:

• A.2 with C.3 for the local kind and direct classification;
• F.4 for the description episteme;
• A.2.1 when a particular review assignment must be identified;
• A.13 followed by independent A.15.1 admission when a particular dated review Work occurrence is identified, and F.6 afterward when the claim also identifies the assignment under which that Work was performed; and
• A.10, B.3, G.6, or another direct relation for the report's evidence or assurance use.

The report is not a system-role holder and does not acquire an “evidence role.”

#Standard Used as a Specification or Source

The sentence “Standard S has the architecture-standard role in this Work” is unsafe if it classifies the standard episteme as a system-role holder. Rewrite the actual claim: the exact edition of Standard S is used as a specification, external rule, premise, or source for named claims. A standard may constrain or support a claim through that direct relation. No system-role kind or assignment is needed unless a separately admitted system really satisfies and is assigned to one.

#Access Role Is Not Automatically a System Role

RBAC role often names a permission grouping. If the current claim concerns permission or access standing, use the direct policy, deontic, access, or status relation. Treat a local access term as a system-role kind only when its own C.3 identity and criterion are current and a receiving Work claim actually needs that classification. Even then, permission and assignment remain separate.

#Anti-Patterns and Repairs

#Consequences

Benefits.

• Descriptions stay short enough for practice while preserving the ontology.
• Part F naming and Bridge patterns can cite descriptions without inheriting classification, assignment, capability, Method, Work, evidence, or status claims.
• Episteme-use relations stay direct and do not become a parallel system-role ontology.
• Method and Work checks may cite the description without treating it as Work evidence.

Costs.

• Former “role-or-status template” material must move to F.10, A.2.4, B.3, A.10, E.17, G.6, or another direct relation.
• A stronger claim may require several neighboring patterns instead of one overloaded card.
• Public, Core-facing, or durable cross-local names require F.18.

#SoTA Decision for a Readable Kind Description

Source use was checked on 2026-08-20. The bounded question is: how can one work-facing kind be described for recognition without confusing the kind with its bearer, a classification judgment, assignment, capability, Method, Work, designation, or publication? The comparison assumes the effort of authoring one project pattern, not adopting a whole upper ontology.

Selected non-dominated contribution. gUFO and BFO offer richer foundational categorization, but at higher mapping effort and without deciding the project-local recognition use. ISO 704 and OntoLex keep description and designation separate at lower effort, but leave assignment, capability, Method, Work, and publication outside their answer. F.4 takes the smallest useful middle path: one C.2.1 episteme about one already recovered C.3 kind, a short ordinary-language recognition distinction, and explicit exits for stronger neighboring claims. At the effort of one pattern description, it preserves the needed ontology while remaining usable by a cold project reader.

SysML is intentionally not a SoTA comparator, lineage source, or ontology authority for this question. Its modeling notation does not supply the kind-identity, classification, assignment, description, or Work rules being compared; search visibility or standard status does not make it a content rival.

Currentness and reopen condition: reopen F.4 when A.2, C.3, A.2.1, A.2.5, A.2.7, A.15, A.6.5, A.6.RSIR, C.2.1, F.9, F.10, F.18, or the accepted episteme-use discipline changes enough that the described-kind or non-inference boundary would be stated differently.

#Relations

Builds on. A.2, C.3, C.3.2, A.6.5, A.6.RSIR, A.7, C.2.1, E.10.ROLE, E.10.D2, and E.24.

Coordinates with. A.2.1, A.2.2, A.2.5, A.2.7, A.15, A.15.1, A.15.2, F.5, F.9, F.10, F.14, F.15, F.18, and direct evidence, status, source, publication, requirement, permission, responsibility, and assurance relations.

Constrains.

• F.5 names a SystemRoleKindDescription only after the described local kind, current criterion, effective scheme, and local sense are recovered.
• Use F.8 to decide durable name minting or reuse without turning status or episteme use into a system-role-kind description.
• F.14 keeps bundles and separation-of-duties relations separate from kind descriptions.
• Use F.15 to check the single-kind and non-inference boundaries.

#Conformance Checklist

#Phrasebook

Prefer:

• “description of the local kind currently named ReviewerSystemRole; JournalReview-2026 locates the definition”;
• “candidate-system admission is established under A.1; classification and any assignment are separate”;
• “capability requirement cited by the description”;
• “Method requirement cited by the description”;
• “review report used as evidence for this claim”;
• “standard used as a requirement source”; and
• “relation position declared by this SlotSpec.”

Avoid as live Tech vocabulary:

• “evidence role” for an episteme;
• “status role” for a status or status-use relation;
• “standard role” for a standard used as a source;
• “holder” for a publication, report, standard, dataset, or theorem unless the exact entity is independently admitted as U.System and an exact U.SystemRoleAssignment names it as holder;
• “role” for a SlotKind; and
• “role description” for a Method, capability, Work record, access policy, or status-use relation.

#Didactic Memory

A SystemRoleKindDescription is the readable episteme that tells people what one exact local system-role kind means. It helps a reader classify, assign, name, or compare the kind. It does not admit the kind or a candidate system, produce the classification judgment, create an assignment, prove capability, define a Method, perform Work, grant permission, establish responsibility, carry evidence, publish itself, or turn every useful episteme into a system-role holder.

#F.4:End

#Naming Discipline for U-kind Names and SystemRoleKindDescription Labels

Type: Definitional (D) Status: Stable in the current FPF Normativity: Normative unless marked informative

#Use This When

Plain name. Meaning-first naming discipline.

Use F.5 when a project needs a durable name for either:

• a public U-kind already admitted through E.24.UK, or another durable cross-local value already recovered through the direct rule for that kind of value—for example, episteme constitution or relation obtaining; a Concept-Set row may cite comparison evidence but does not recover the value; or
• one exact local system-role kind and, when needed, the separate SystemRoleKindDescription episteme that describes it.

Typical moments:

• a Concept-Set comparison has enough witnesses for a naming question and the reusable value is already admitted, but candidate names import one source tradition too strongly;
• an F.4 description names ReviewerSystemRole, OperatorSystemRole, InspectorSystemRole, or TransformerSystemRole, and the label must remain faithful to the exact local kind without smuggling assignment, capability, permission, Method, Work, evidence, status, or responsibility;
• source wording with role must be named locally, but the project has not yet recovered its use—for example, a system-role kind, assignment, status or access relation, relation position, another object, or ordinary wording; or
• similar names threaten to collapse independently governed objects—for example, a kind, assignment, status, Method, Work occurrence, and description episteme.

Primary EntityOfConcern. The EntityOfConcern is the naming discipline for these name families. It relates a recovered meaning to selected Tech and Plain designations. It defines neither the named U-kind nor the local system-role kind, constitutes no description, classifies no candidate, creates no assignment, asserts no status or responsibility, supplies no evidence, and publishes no form.

Primary working reader. The first reader is a practitioner who already has a candidate meaning and must choose a name that readers can use without creating another ontology—for example, an engineer-manager, analyst, pattern author, or terminology steward.

First useful move. Recover the exact named value and its direct meaning source before choosing the label. For a U-kind, use its accepted E.24.UK admission result or its direct admission rule. For a local system-role kind, use its A.2 and C.3 identity and criterion; use F.4 for the separate description episteme. Then choose one Tech label and one short Plain explanation whose scope does not exceed the recovered meaning.

Smallest useful result and stop. Stop with one already identified value, one Tech label, and one Plain explanation as soon as they resolve unambiguously for the named local use. Do not create a NameCard, public row, Bridge, description episteme, or new kind merely to complete a form. If the value or kind is unresolved, apply its direct recovery rule. Use F.18 or F.17 only for the durable or public use they address. Use C.3.3 only for an actual relation between exact local kinds and F.9 only for an actual relation between distinct F.17 cells. If the label starts carrying assignment, Work, result, provenance, assurance, responsibility, or publication claims, stop naming and recover those objects first.

What goes wrong if missed. Names become arguments. A system-role-kind label smuggles in neighboring claims—for example, assignment, permission, responsibility, or capability. A status phrase becomes a system-role kind. A U-kind name imports one practice's or source's private ontology. A polished global word hides disagreement among witnesses. Downstream patterns then repair semantics that naming already broke.

What this buys. Readers can use short names without guessing the ontology. U-kind names stay neutral across witnesses. Concrete ...SystemRole designations point to exact local kinds, and ...SystemRoleKindDescription designations point to their separate description epistemes. Names for neighboring claims—for example, status, evidence, access, requirement, source, publication, assurance, gate, and decision claims—remain with their direct relations.

Not this pattern when.

• If the problem is ordinary phrase repair, use E.10, E.10.ROLE, E.10.ARCH, A.6.P, A.6.RSIR, or the direct pattern.
• If the question is whether a U.* spelling or structural name should survive as a durable U-kind, use E.24.UK before F.5.
• If the broader local-first protocol, NameCards, candidate comparisons, lineage, or public naming is current, use F.18.
• If the current object is a SystemRoleKindDescription, use F.4 to constitute it before naming it.
• If the question concerns kind admission, classification, assignment, assignment extent, or performed-Work attribution, use A.2 with C.3, A.2.1, or F.6.
• If the current object is another governed value rather than a name—for example, a status, evidence use, source use, standard use, requirement use, publication use, assurance claim, gate result, or decision—use its direct pattern.
• If role denotes a relation position, recover the position under A.6.RSIR and A.6.5.
• If an actual cross-local relation is current, use C.3.3 for exact local kinds or F.9 for distinct F.17 cells.

#Problem Frame

FPF needs names that humans can use without dragging the wrong ontology behind them. A good name is short enough for documents and conversation, but it belongs to a recovered meaning.

This pattern keeps two recurrent naming tasks separate.

First, a public U-kind gets a name only after E.24.UK admits the exact value. Another durable cross-local value gets a name only after its direct rule has identified or established it; kind membership is only one case. A Concept-Set row may preserve witness comparison and evidence; it neither admits nor identifies the value. The name should be neutral across witnesses and no wider than the recovered invariants.

Second, one concrete local system-role kind receives a ...SystemRole designation after A.2 and C.3 settle its candidate domain, operative membership condition, intended member/non-member boundary, and continuity rule. A practice or source reference may help readers find or compare that settlement; it does not identify the kind. SystemRole is common morphology, not a universal kind. An F.4 description episteme is another object and may receive a separate ...SystemRoleKindDescription name. Neither label creates the kind, description, classification, or assignment.

The tempting shortcut is to make system-role descriptions cover statuses and episteme uses because all need labels. That convenience creates duplicate ontology. Another governed value—for example, a status, evidence use, permission, or publication—may need a name; none becomes a system-role kind because it is named.

#Problem

Without this pattern:

1. Local terms look global. Observation, Activity, or Process becomes a U-kind name although it carries one practice's or source's private commitments.
2. System-role names become hidden admissions. A label such as ReviewerSystemRole is treated as if the local kind or candidate classification already exists.
3. System-role names become hidden assignments. A concrete kind label is treated as if someone is already assigned.
4. System-role names become capability claims. A candidate is assumed able because the kind label sounds competent.
5. System-role names become Methods. A noun label hides a Method or Method family.
6. Description and described kind collapse. PumpInspectorSystemRoleKindDescription is treated as PumpInspectorSystemRole itself.
7. Status names become system-role kinds. For example, Approved, AccessRole, ModelFitEvidenceRole, or RequirementRole creates a fake work-facing classification instead of the exact direct relation.
8. Relation positions become system-role kinds. Signature, relation, or argument-position names borrow role morphology even though they name participation or a declaration place.
9. Names carry interpretation metadata. Task-IEC61131, Participant-BPMN, or ReviewerSystemRole-SchemeA fossilizes an edition, source, local boundary, or scheme in the label.
10. Aliases become silent renames. Several labels circulate for one meaning without lineage or Bridge discipline.

#Forces

#Solution

Name after meaning. Recover the value, its kind, direct meaning source, and intended use. Then choose designations that preserve them.

Make these facts recoverable in the prose, direct admission, F.4 description, Concept-Set row, or NameCard. This is a naming checklist, not a relation signature or mandatory record:

• the exact named value and its admitted kind;
• the direct source of its meaning;
• for a local system-role-kind designation, the candidate domain, operative membership condition, intended member/non-member boundary, continuity rule, current KindSignature, and effective scheme, with source or practice provenance kept as a locator or comparison cue;
• for a description name, the separate F.4 SystemRoleKindDescription and its exact EntityOfConcern;
• the selected Tech and Plain designations;
• aliases or predecessor labels with lineage;
• morphology, neutrality, and minimal-generality checks; and
• the boundary that prevents the name from absorbing classification, assignment, capability, Method, Work, status, evidence, permission, responsibility, publication, or relation-position claims.

#Name Families Used Here

Keep four things separate: the chosen name, the local system-role kind it names, an optional F.4 description of that kind, and any assignment that the current use actually needs. The name designates the kind; the description describes it. An assignment is a separate A.2.1 occurrence of a directly declared species under U.SystemRoleAssignment. That species says which systems may be holders, which exact local kinds may fill the assigned-kind place, what the assignment predicate means, when it applies, how an uninterrupted occurrence keeps its identity, and whether another real participant matters. The occurrence supplies the actual holder, assigned kind, and any other participant values. If the naming use needs no assignment identity, do not invent an assignment. Spelling, a suffix, a NameCard, a public row, a description, or a citation creates none of these objects, nor any dated Work, result episteme, provenance record, or publication occurrence.

#Tech and Plain Designations

Use two human-facing designations when a name is durable enough to be reused:

For a concrete local system-role kind, the Tech designation normally ends in ...SystemRole, for example ReviewerSystemRole or PumpInspectorSystemRole. The Plain designation may remain ordinary, for example “reviewer” or “pump inspector”, when the named practice and criterion make the intended kind clear. Add “system role” only when it prevents a live neighboring reading. The compound does not imply non-human technical systems, kind admission, candidate classification, assignment, agency, capability, Method, or Work.

For the description episteme, name the description rather than the described kind: PumpInspectorSystemRoleKindDescription may have Plain designation “description of the pump-inspector system-role kind”. SystemRoleKindDescription identifies the construction; Kind identifies the EntityOfConcern and Description already identifies the episteme.

For a coupled system-role–Method phrase, recover the local kind and Method separately before naming either one. Recover and name a MethodDescription, WorkPlan, or dated Work only when that exact object is already admitted and the naming use consumes it; a shared phrase does not require any of them to exist. RoboticsEngineerSystemRole may designate one admitted local kind; RobotEngineeringMethod names a Method or Method family. Ordinary engineer-roboticist may remain the Plain expression when nearby project wording makes the intended kind clear and the C.3 candidate domain, membership distinction, boundary probes, and continuity remain recoverable. The wording helps the reader; it does not identify the kind. It replaces neither a qualifying MethodDescription nor any description of planned or performed Work.

When a later naming use actually consumes one dated Work identity, that Work must already be constituted before F.5 naming begins. Recover every exact actual performer through A.13, and let A.15.1 independently admit the Work from its semantic Method, time, containing System, and other required direct facts. Add the assignment occurrence, holder equality, and F.6 relation only when the naming record or receiving use expressly represents precise assignment-bound attribution; missing or failed F.6 leaves the Work identity intact. Otherwise keep the activity in ordinary wording and do not mint a Work identifier merely to support a name.

For a U-kind, the Tech designation should be neutral enough that no witness wins by vocabulary alone. If witnesses disagree between Observation, Reading, and MeasurementResult, a Concept-Set row preserves the comparison; the exact shared value and invariants must still pass E.24.UK admission or their direct defining rule before an author uses F.5 to choose a name.

#Positive Naming Rules

1. Recover the object first. State the governed kind or construction of the value—for example, a U-kind, local system-role kind, description episteme, classification judgment, assignment, relation, Method, Work, status, evidence use, slot, lens, or another object.
2. Recover the meaning source. Use the exact E.24.UK or direct admission for a U-kind; A.2 with C.3 for a local system-role kind; F.4 for its description; A.2.7 for relations among kinds; A.3, A.15, G.5, or the exact composition pattern for Method and Work names; and the direct relation for status, evidence, source, requirement, publication, assurance, gate, decision, and relation-position names.
3. Use minimal generality. The designation's scope is no wider than the admitted invariants.
4. Keep interpretation metadata out of the label. Edition, source, witness, local boundary, reference scheme, and threshold belong in the direct declaration, description, relation, or NameCard.
5. Make morphology object-sensitive. Concrete local system-role kinds use ...SystemRole; description epistemes use ...SystemRoleKindDescription; states use state or level wording; slots say Slot, Argument, Endpoint, or another exact position head.
6. Keep coupled names typed. A compact phrase may help a reader, but one label must not carry several independently governed objects—for example, kind, assignment, capability, Method, Work, and description—at once.
7. Do not encode thresholds or windows in the name. Put time, state, threshold, capability envelope, or admission window in the direct claim.
8. Use aliases only with lineage. A source term, predecessor term, symbol, or translation does not become a second selected Tech label.
9. Escalate only for actual reuse. Use F.18 and F.17 for durable or public naming. When an actual cross-local relation is consumed, name the exact obtaining C.3.3 relation between local kinds or F.9 Bridge between distinct F.17 cells and keep the separate C.2.1 claim that it suits the named use. Ordinary reliance requires the exact A.10 evidence-provenance relation and RelianceDisposition=pass. Use B.3 only when an actual named assurance claim is current. None of the cross-local relation, use claim, evidence path, assurance result, NameCard, row, designation, or publication establishes assignment, Work, result, provenance, assurance, or publication occurrence.

#Neighboring Use Boundary

When a candidate contains a tempting word, recover the current claim instead of replacing words mechanically.

Select the name only after recovery. A cleaner string is not a repair if it hides the same ontological error.

#Archetypal Grounding

#Public or Cross-Local Kind Name

A Concept-Set row compares SOSA Observation, metrology measurement result, ML practice metric reading, and a dashboard value exported for comparison. The row is a comparison and evidence surface, not admission or identity of a common result value.

Keep the concrete objects at their direct loci. Pump 14 was measured before the reading was recorded, but this naming example does not identify a dated Work occurrence. If a use needs that occurrence, recover its exact actual performer through A.13 and admit it independently under A.15.1. Attribute it under F.6 only when that use also consumes precise assignment-bound attribution.

C.16 constitutes the measurement result: a value attributed to the measurand together with the Characteristic, Scale, uncertainty, method, model, calibration basis, time stance, and measurement Work needed to interpret it. Pump14PressureReading_2026-07-14T10-42Z is one C.2.1 episteme that states that result; F.5 does not repeat either pattern's schema. The result and its episteme are distinct from raw output, indication, Pump 14's actual state, a later diagnosis, a criterion verdict, evidence, or a dashboard display. Pump14CalibrationTrace_2026-07-14 is a provenance record whose G.6 and A.10 relations make the calibration and source path recoverable. A dashboard publication may cite the reading, and the Concept-Set row may cite the reading and trace; neither is the result, its episteme, provenance, or a generic relation that establishes them.

Only E.24.UK or the direct result pattern can admit a shared value and its invariants. After admission, use F.5 to select Reading, Result, or another neutral head no wider than that value. The spelling still creates no result or provenance identity.

#Local System-Role Kind and Its Description

Under Plant-A-Maintenance-Scheme, PumpInspectorSystemRole designates one exact local kind; it is not that kind. PumpInspectorSystemRoleKindDescription-v3 is a separate C.2.1 episteme whose EntityOfConcern is the kind. Its ClaimGraph states which systems are candidates, the reading-and-judgment condition that distinguishes members, useful member and non-member probes, the continuity rule, current KindSignature, and effective scheme. Plant-A maintenance provenance locates that definition; it does not identify the kind. The Tech designation is PumpInspectorSystemRole; the Plain designation is “pump inspector”.

This worked slice needs an assignment identity, so Robot7-PumpInspector-Assignment-2026Q3 is one occurrence of the directly declared PlantAPumpInspectionAssignment species under U.SystemRoleAssignment. The species' holder slot admits a U.System; its declaration-local assigned-kind slot uses the exact PlantAMaintenanceSystemRoleKindDomain; and its predicate applies within the Plant A maintenance scheme and obtains while the fixed holder is assigned under PumpInspectorSystemRole to supply the pump-inspection contribution. The occurrence identifies Robot-7 as holder and PumpInspectorSystemRole as assigned kind, and spans the maximal uninterrupted interval over which that predicate obtains for those values. This simple species declares no additional identity-bearing participant; a commission, position, or installation locus would become one only in a species whose predicate and identity actually require it.

This naming example does not identify Robot-7's inspection of Pump 14 as a dated Work occurrence. Pump14InspectionFinding_2026-07-14T11-18Z is a separate claim-bearing result episteme, and Pump14InspectionTrace_2026-07-14 is the exact provenance record connected through G.6 and A.10.

The kind label helps readers recover the kind; the description episteme describes it. Neither says Robot-7 satisfies the kind, has an assignment, performed the inspection, produced the finding, or supplied its provenance. A suffix, NameCard, row, pattern section, or citation identifies none of those objects or relations.

#Evidence Use Is Not a System-Role Name

Source text may say ModelFitEvidenceRole. The repair is not a prettier role label. This naming example does not identify the model-fit evaluation as a dated Work occurrence. Recover the exact objects it does consume: ModelFitResult_2026-07-15T09-22Z is a separately constituted domain-local result episteme; ModelFitTargetClaim-v5 is the target claim; and ModelFitRunTrace_2026-07-15 is the provenance record connected through exact G.6 and A.10 relations. Keep any operation-result binding, result-episteme inception claim, evidence use, provenance, and current assurance claim separate, and apply the rule that defines or tests each relation.

A durable name, if needed, names one recovered evidence-use relation, status value, Work occurrence, result episteme, or provenance value. ModelFitEvidenceRole, a NameCard, row, or citation creates none of them and supplies no generic evidence-result relation. It is neither a local system-role kind nor a SystemRoleKindDescription label.

#Relation Position Is Not a System-Role Name

In a relation signature, “provider role” may mean the provider argument position. Use E.10.ROLE and A.6.RSIR to recover the participant meaning; use A.6.5 to declare ProviderSlot, its ValueKind, and its reference mode. A provider system's classification under a local ProviderSystemRole kind is a separate C.3 claim. When assignment identity is irrelevant to naming that relation position, say only that any provider assignment remains independently governed by A.2.1; do not invent an occurrence. When it is relevant, recover the assignment occurrence and its declared species rather than asserting that the provider simply “has an assignment”.

#Bias Annotation

1. Semio-bias. A name, card, row, publication, or source label is mistaken for the named value or authority to use it.
2. Role-bias. Evidence, status, access, source, requirement, participation, or argument-position wording is forced into SystemRole morphology.
3. Source-vocabulary capture. One source's term becomes the Tech designation without showing fit to the admitted value or exact local kind.
4. Suffix formalism. Adding SystemRole, KindDescription, Status, Record, Graph, or Map makes a label look precise while the object remains unresolved.

The repair is object recovery first, designation second.

#Conformance Checklist

#Common Anti-Patterns and Repairs

#Consequences

Good consequences:

• durable names become shorter because the ontology stays at the right object;
• local system-role-kind names stay usable without becoming assignment, capability, Method, or evidence claims;
• description names no longer collapse into the kinds they describe;
• U-kind names are easier to bridge because their comparison evidence remains explicit; and
• For an E.10 repair that uncovers a durable naming issue, use F.5 or F.18 instead of ad hoc word substitution.

Costs:

• authors recover the object and meaning source before naming;
• some familiar source labels cannot become FPF Tech designations;
• durable public names may need F.18 and F.17, while actual cross-local relations may need C.3.3 or F.9 even when a local label looks obvious; and
• source text that uses role for status, evidence, access, participation, or relation position needs ontological recovery, not suffix editing.

Reopen F.5 when U-kind neutrality, SystemRole or SystemRoleKindDescription morphology, the Tech-Plain relation, lineage, or durable cross-local naming boundaries change. Reopen a neighboring pattern when the dispute is about the named object itself.

#Rationale

Naming is late ontology, not early decoration. Durable names become references used in reasoning, search, publications, and pattern relations. A wrong name makes later readers inherit a false kind claim.

The design choice is to split naming by meaning source rather than source spelling. Bare role can point to many different objects or uses—for example, a local system-role kind, assignment, policy term, status, evidence use, relation position, representation position, or ordinary English. Do not decide by suffix. Use E.10.ROLE and the direct patterns to recover the object, then F.5 to name it.

F.5 remains narrower than F.18. Use F.18 for the full local-first protocol, NameCards, candidate comparison, lineage, and public naming. F.5 supplies the special discipline needed by U-kind names, concrete system-role-kind names, and SystemRoleKindDescription labels.

#SoTA Decision for Precise, Readable Technical Names

Source use was checked on 2026-08-20. The bounded question is: after the object is recovered, what is the smallest naming result that stays technically precise, readable to a project reader, and honest about morphology and reuse?

Selected non-dominated contribution. A bare preferred label is cheaper but can hide the wrong object and leaves a cold reader without a safe explanation. A full ontology lexicon is richer but normally costs more than one project naming decision needs. F.5 stops at one already recovered value, one Tech designation, and one short Plain explanation. The word form follows the kind of object, while explicit limits prevent the two labels from creating a second ontology. At that effort, the result is more usable than a formal-only name and more precise than an unexplained familiar word.

SysML is intentionally not used as a naming, ontology, or lineage authority here. Its notation does not settle the referent, local kind, description, assignment, participation, Method, Work, or readable term choice at issue.

Source-use boundary: external labels, Concept-Set rows, and citations are evidence for local meaning or common practice, not automatic Tech designations, admission decisions, or Work, result, and provenance identities. A source term becomes selected only after the exact value is admitted and the naming comparison passes; naming changes none of those objects.

#Relations

Builds on. A.2, C.3, F.4, F.7, F.18, E.10, E.10.ROLE, and E.10.ARCH.

Coordinates with. E.24.UK for U-kind admission; A.2.1 for system-role assignment; A.2.2 for capability; A.2.5 for assignment state; A.2.7 for relations among system-role kinds; A.6.5 and A.6.RSIR for relation positions; A.15 for system-role–Method–Work alignment and dated Work; C.16 for measurement results; C.2.1 for descriptions and result epistemes; G.6 and A.10 for provenance and ordinary evidence reliance; B.3 for assurance-bearing reliance; F.8 for mint or reuse; C.3.3 for relations between exact local kinds and F.9 for relations between distinct F.17 cells; F.10 for status; F.13 for lineage; F.14 for anti-explosion; F.15 for conformance; and F.17 for public term-sheet use.

Used by. Part F naming patterns, F.4 description authors, Concept-Set authors, E.10 repairs that uncover naming rather than phrase-use issues, and any pattern use that creates a durable local name for a U-kind, system-role kind, or SystemRoleKindDescription.

Does not replace. Direct evidence, status, requirement, source, publication, assurance, gate, decision, responsibility, relation-signature, Method, Work, or architecture patterns.

#F.5:End

#SystemRoleAssignment and Performed-Work Attribution Check

Type: Boundary and use pattern Status: Stable Normativity: Normative unless marked informative

#Use This When

Plain name. Check whether this already admitted Work was performed under this exact system-role assignment.

Use this pattern only after A.15.1 has independently admitted a dated U.Work occurrence. Use F.6 when deciding whether that already admitted Work was performed under a particular assignment occurrence from the U.SystemRoleAssignment family. When it was, the direct world-side performed-under-assignment relation obtains. A separate assertion or record can identify the two occurrences and state that relation.

Typical moments:

• a work record says “Alice reviewed”, “Robot-7 inspected”, or “the operations team approved”, but the assignment occurrence is missing;
• a MethodDescription names a system-role kind and the project must connect actual Work to the assigned performer;
• source wording says RoleEnactment, “played the role”, or Holder#Role:Context@Window;
• a stronger appointment has a commission, position, or locus participant and must retain that occurrence identity during attribution;
• a report, standard, dashboard, or access label is described with role wording although it did not perform Work;
• a corresponding kind or assignment from another context is cited without a current Bridge and local occurrence.

Primary EntityOfConcern. One obtaining performedUnderAssignment relation occurrence between a U.Work occurrence and an assignment occurrence whose species is declared under U.SystemRoleAssignment.

Primary working reader. An engineer, operator, Method author, manager, or FPF author deciding whether a performed-Work attribution is grounded strongly enough for the next use.

First useful move. Confirm that A.15.1 has already admitted the exact dated Work without using an F.6 conclusion. Name that Work and the assignment occurrence under which it is said to have been performed. Recover the assignment's declared species and participant values, then confirm that the actual performer already has the A.13 core for this action, scope, working situation, and window and that this is the same obtaining assignment. Evidence supports those core facts; a characteristic profile enters only for a consumed Grade, autonomy or profile result, criterion-dependent characteristic, or assurance use. Ask what direct case fact links the exact pair. Confirm holder equality and interval coverage; those checks alone do not create the link. If the case does not establish the pair, retain the Work and leave only the attribution unresolved. Otherwise say plainly that the holder System performed the Work under that assignment.

What goes wrong if missed. Assignment is treated as proof of Work, a label replaces the assignment occurrence, a generic assignment duplicate erases a stronger appointment, or a log or report is made the performer. When several assignments overlap, interval coverage then attributes the same Work to all of them even though the exact pair was never established.

What this buys. Attribution is one thin relation. The holder System remains the actor, the assignment occurrence remains linked to its species and participant values, and Work, Method, capability, state, result, evidence, publication, and cross-context use remain separate.

Not this pattern when. Use A.2 for the system-role kind and classification, A.2.1 for assignment species and occurrence identity, A.2.5 for assignment state, A.2.2 for capability, and A.15.1 for the Work occurrence. Use the direct evidence, source-reliance, publication, access, authority, permission, responsibility, status, gate, or decision pattern when that relation is current. Use E.10.ROLE and A.6.RSIR when role denotes another object or relation position.

#Problem Frame

U.SystemRoleAssignment and U.Work classify different world-side occurrences. An assignment occurrence belongs to a declared species, relates fixed participant values, and lasts for one maximal uninterrupted interval in which its predicate remains true. A U.Work occurrence is dated. Their existence does not establish the additional attribution relation.

Use F.6 to state that missing relation between the Work and assignment occurrences. Every assignment species declares a holder slot, and each assignment occurrence supplies its actual holder System. F.6 exposes that holder only so the attribution can compare it with the actual performer already recovered through A.13 and used by A.15.1 to admit the Work; it does not discover a performer. This preserves a commission-sensitive or otherwise stronger assignment instead of replacing it with a generic duplicate.

A roster can assert the assignment; a log can assert the Work and attribution; evidence can support either assertion. Those epistemes help a system know or use the claim. They do not become relation participants or make world-side attribution obtain merely by being stored.

This separation matters because assignment, classification, state, ability, performance, result, evidence, and acceptance vary independently. A system can hold an assignment and do no Work. It can perform poor Work under a valid assignment. A report can accurately describe the Work without performing it.

#Problem

Without the direct attribution relation:

1. Assignment becomes Work. Current assignment is treated as evidence that a system performed one occurrence.
2. Performer comes from a label. Reviewer or Operator is used without a holder and assignment episode.
3. A stronger assignment is flattened. A commission-sensitive appointment is replaced by a weaker generic record.
4. Episodes do not cover. Work is attributed outside the interval in which the exact assignment predicate obtains.
5. Support becomes constitution. A log, report, standard, dashboard, or decision is treated as what makes attribution obtain.
6. Enactment is duplicated. RoleEnactment or RoleEnactmentFact becomes another object beside Work and attribution.
7. Locality is hidden. A context word replaces the exact local kind, assignment species, Work locus, scope, or selected model-use structure.

#Forces

#Solution

Treat performed-Work attribution as one direct relation species under U.Relation.

#Direct Relation Declaration

performedUnderAssignment : U.Relation
  WorkOccurrenceSlot: U.Work, U.EntityRef
  SystemRoleAssignmentSlot: U.SystemRoleAssignment, U.RelationRef

when performedUnderAssignment(W, RA) obtains:
  attributedPerformerSystem(W, RA) := RA.HolderSystemSlot

WorkOccurrenceSlot names a dated Work already admitted under A.15.1 from independently grounded performance history, A.13-qualified actual performer facts, Method, extent, and containment. The typed slot consumes that completed membership result; F.6 neither helps establish nor reopens W : U.Work. The declaration-local SystemRoleAssignmentSlot names one occurrence of an admitted assignment species declared under U.SystemRoleAssignment. Its U.RelationRef names that occurrence and is limited to U.SystemRoleAssignment. Filling the two slots, matching the holder, or finding temporal overlap does not establish that this Work was performed under this assignment; the case must independently establish that link.

For an obtaining attribution:

S = attributedPerformerSystem(W, RA) = RA.HolderSystemSlot

S is the admitted System already recovered as an actual performer through A.13 and used by A.15.1 to admit W; F.6 does not discover it. RA is the assignment under which that Work is now attributed. The projection exposes the holder already carried by RA only to test equality with S; it creates neither performerhood, Work, attribution, classification, nor a generic assignment occurrence and discards none of RA's additional participants.

performedBy remains only a deprecated source relation name. Read it through the direct Work-assignment relation only after A.13 and A.15.1 have independently established the actual performer and admitted Work, and after holder equality is checked. New practitioner-facing claims say that the already recovered performer System performed the Work under the assignment, or name performedUnderAssignment when the relation name is needed; they never make the assignment the performer or use F.6 to discover one.

No evidence, log, status, MethodDescription, result, publication, context record, or assignment-state assertion is a generic attribution participant.

#Obtaining and Occurrence Identity

The direct Work-assignment attribution is a world-side fact, separate from any assertion or evidence. A positive check requires all of the following:

1. W is one exact dated U.Work occurrence already admitted under A.15.1 from its independently grounded candidate-action history, A.13-qualified actual performer basis, Method actually followed, temporal extent, and containing-System relation; that admission neither assumes nor depends on this F.6 relation;
2. the actual performer S has the A.13 core for this action, scope, working situation, and window: S is an admitted System, satisfies and is classified under one exact local agential system-role kind, and holds the same obtaining assignment RA; evidence supports those core facts, while a characteristic profile is required only for a consumed Grade, autonomy or profile result, criterion-dependent characteristic, or assurance use;
3. RA is one named assignment occurrence of a declared U.SystemRoleAssignment species, with all identity-bearing participants and its rule recovered;
4. the case establishes that W was performed under RA, rather than deriving that link from a label, common holder, assignment existence, or temporal overlap;
5. RA.HolderSystemSlot = S, the admitted System that actually performed W; and
6. RA's species predicate obtains throughout the attributed temporal extent of W.

Conditions 1–3, 5, and 6 are five constraints on a valid attribution but do not establish it. F.6 reuses the obtaining A.13 assignment; it does not create the A.13 classification, assignment, evidence, optional profile, or Work. Failure of condition 4 or any constraint leaves W : U.Work intact and leaves only this exact assignment-bound attribution unasserted. Two overlapping assignments held by the same System may satisfy all five constraints while the case links the Work to only one. Use that case fact; if it does not distinguish the assignments, leave the attribution unresolved rather than asserting both.

If attribution concerns only a temporal, episode, or operational part of a larger Work whole, first identify that part as its own U.Work occurrence under A.15.1. Do not hide an unidentified Work portion inside F.6.

When a receiver needs an explicit attribution occurrence:

PerformedUnderAssignmentOccurrenceKey =
  <WorkOccurrenceSlot, SystemRoleAssignmentSlot>

This key identifies an already obtaining relation; it does not make one obtain. The attribution extent follows W. Extending an open Work interval or later recording its end does not create another attribution occurrence while both participants and the direct relation remain the same. Another Work occurrence, separately identified Work part, or assignment episode yields another possible pair whose relation must be checked independently.

An assertion can state the exact pair, and evidence can support reliance on that assertion. Neither the assertion nor its evidence constitutes the world-side relation. Missing evidence leaves reliance unresolved; missing pair grounding leaves the positive attribution unasserted. A demonstrated different performer, non-covering assignment, or false direct pair can support a stronger negative claim.

#Preserve the Exact Assignment Species

Before checking or relying on attribution, recover RA's declared species and occurrence. This distinguishes the assignment even when the final practitioner sentence omits its full declaration. Every species declares:

• a HolderSystemSlot whose ValueKind is U.System;
• a declaration-local AssignedSystemRoleKindSlot whose ValueKind is the exact local system-role-kind domain admitted for that species;
• every additional participant meaning and its ValueKind;
• the rule, applicability, and maximal uninterrupted occurrence identity.

An assignment occurrence supplies one participant value for each slot. In particular, it supplies one local system-role-kind value from the AssignedSystemRoleKindSlot domain; the value does not replace or narrow that declared domain.

A simple assignment may have only holder and kind. A project appointment may also have ReviewCommissionSlot. F.6 accepts both through the family ValueKind and holder projection while retaining the declared species and all participants that distinguish the assignment occurrence. Those participants and the assignment rule still do not establish that the Work was performed under the assignment; the case must establish that link separately. F.6 never creates a two-participant generic assignment beside the appointment.

Taxonomy, scheme, KindSignature, assertion, and assignmentInterval can interpret or describe RA without becoming participants by default. Verify temporal coverage from whether the assignment rule actually holds, not merely from a recorded interval.

Do not replace the species with one Context value. Recover what the source token denotes and use its direct pattern. It can denote a system or Work locus, claim scope, or selected BoundedModelUseStructure; those objects are neither interchangeable nor optional participants of generic assignment or attribution signatures.

#Attribution Check Sequence

1. Start from the exact U.Work occurrence already admitted by A.15.1 without an F.6 premise.
2. Recover the assignment occurrence, including its declared species, identity-bearing participants, rule, applicability, and time span.
3. Find the case fact that directly links this Work to this assignment; do not infer that link merely because the holder and interval match.
4. Confirm that the assignment holder is the actual performer.
5. Confirm that the assignment predicate obtains throughout the attributed Work interval.
6. When all five checks pass, state the F.6 relation or say plainly that the holder System performed the Work under that assignment. If the direct link, a participant, or a required constraint is missing, retain the admitted Work and leave only this assignment-bound attribution unresolved; do not select another covering assignment.
7. Keep assertions and evidence separate: they can support reliance on the attribution claim but do not make the relation obtain.
8. Send classification, assignment state, capability, Method, evidence, source use, result, acceptance, publication, bridge, responsibility, and authority questions to their subject patterns.

This sequence is application guidance, not a new check record or workflow object. Its first useful result is the readable exact relation, an unresolved exact pair with the missing fact named, or a corrected route to the direct neighboring claim.

#Method and Work Boundary

performedUnderAssignment has no Method participant. A separate claim may say that the Work enacts one exact semantic Method. The holder System performs the Work; the Work, not the performer or assignment, enacts the Method.

The assignment, system-role kind, capability, Method, and MethodDescription do not act or perform Work. Citing a description can identify, constrain, or support a receiving use of the Method, but it neither enacts the description nor establishes D : U.MethodDescription; use A.3.2 to test that membership separately.

#Direct Neighboring Relations

#Source Shorthand and RoleEnactment

Holder#Role:Context@Window is readable source notation only. Recover the actual system, local system-role kind, assignment species and occurrence, and the object denoted by Context. The source spelling is not a signature.

When source wording says RoleEnactment or RoleEnactmentFact, recover dated Work and performedUnderAssignment. Do not retain a second enactment kind, fact object, or relation occurrence.

#Lightweight Use

After the Work–assignment link and its necessary constraints are established, ordinary use can stop at:

InspectionWork-17 was performed by Robot-7 under InspectionAssignment-17.

Expose declarations and occurrence keys only when a dependent use must distinguish occurrences, cite one as a participant, compare assertions, or preserve provenance. If the assignment cannot be recovered, lower the claim to “Robot-7 is named as performer in record R” and state the source, reliance, and evidence claims under their direct predicates.

Another pattern may require a complete A.13/A.15.1/F.6 basis when its receiving use needs both admitted Work and precise assignment-bound performer attribution, and may point here instead of repeating this declaration and check sequence. That combined basis has a fixed order: A.13 first supplies every performer's exact System, local agential kind and criterion, classification, obtaining assignment, needed scope, working situation, window, and adequate core evidence; A.15.1 independently admits the dated Work from its performance history, at least one obtaining enactsMethod relation, extent, and at least one obtaining locally declared Work-to-System containment relation; only then does F.6 test every required exact Work-assignment pair through the same obtaining A.13 assignment. The phrase is never an A.15.1 membership test. A missing F.6 relation preserves W : U.Work and leaves only the precise attribution unresolved. A characteristic profile remains conditional, and another enactment or containing-system relation is named only when the receiving use relies on it.

#Invariants

1. Every positive performed-Work attribution links one dated U.Work occurrence to one assignment occurrence of a declared U.SystemRoleAssignment species.
2. SystemRoleAssignmentSlot accepts the family and preserves the assignment's declared species, all participants, rule, applicability, and occurrence identity.
3. The actual performer is the admitted System in RA.HolderSystemSlot; the assignment and kind do not act.
4. RA's predicate obtains throughout the attributed Work interval; a declared window alone does not establish coverage.
5. The species declaration, occurrence participant identity, holder match, and time coverage constrain but do not establish the Work–assignment link.
6. Overlapping assignments are checked pair by pair; an unresolved basis never licenses attribution to every covering assignment.
7. Every positive precise assignment-bound performer attribution starts from an already admitted Work whose actual performer has the A.13 core for the exact action, scope, working situation, and window, then adds its own F.6 link through the same covering assignment occurrence. A characteristic profile remains conditional on its receiving use. A lead, team, member, coordination, allocation, or responsibility claim substitutes for none of these.
8. A passive assigned System is not thereby a performer. Any claimed passive participation needs a rule that defines it; otherwise A.6.RCD returns missing-governor.
9. Assignment does not prove performance, and attribution proves neither classification, capability, state, Method validity, result quality, responsibility, authority, nor acceptance.
10. RoleEnactment wording is repaired to Work plus performedUnderAssignment; no duplicate object remains.
11. Assertions, logs, rosters, evidence, identifiers, and publications can support or designate an attribution but do not constitute it.
12. Missing evidence leaves reliance unresolved; a missing case fact linking Work and assignment leaves the positive attribution unasserted.
13. An episteme does not fill HolderSystemSlot because it describes or supports Work.
14. Cross-context correspondence changes neither assignment identity nor Work attribution.
15. Reduced prose may omit only an assignment identifier unused by the receiving claim, and only after the complete Work–assignment basis remains recoverable.
16. The Method enacted by W remains a separate fact; only the admitted holder System performs W.

#Reasoning Rules

• Accept the attribution only when the case establishes that W was performed under RA, W is a dated Work occurrence, RA is a named assignment occurrence with its participants and rule recovered, the assignment holder performed the Work, and the assignment rule covers the Work interval. A short account may then say that the holder System performed W under RA.
• If W and RA exist, the holder performed the Work, and the assignment covers the interval, do not infer the Work–assignment link. Check the case fact that establishes the link or leave it unresolved.
• If current support for an attribution statement is inadequate, reliance on that statement is unresolved. Do not infer that the Work was not performed under the assignment, and do not treat the statement or evidence as what makes the link true.
• If a source episteme merely names a performer or role, do not claim attribution until the Work and assignment are identified, the case establishes their link, the holder matches the performer, and coverage is checked.

#Archetypal Grounding

#Robot Inspection

MaintenanceInspectionAssignment is a declared species under U.SystemRoleAssignment. Its participants include a HolderSystemSlot for the assigned System and a local AssignedSystemRoleKindSlot whose value is an InspectorSystemRole. Its rule applies within the Plant A maintenance scheme and says that the fixed holder is assigned under that kind to supply the inspection contribution; one occurrence is the maximal uninterrupted interval for which that rule stays true for the same participants.

InspectionAssignment-17 : MaintenanceInspectionAssignment
  HolderSystemSlot: Robot-7
  AssignedSystemRoleKindSlot: InspectorSystemRole
  predicateTrueInterval: [2026-07-13T09:00, 2026-07-13T17:00]

InspectionWork-17 was performed under InspectionAssignment-17.

The case basis directly links that Work to that assignment; the matching holder and interval only confirm necessary conditions. Robot-7 is the actor. Separately, the inspection Work enacts TurbineInspection@Maintenance-2026 as its Method. InspectorSystemRole, a sensor capability, algorithm-possession wording, the Method, and TurbineInspectionProcedure-v3 do not perform the inspection. Use A.3.2 to decide whether that last episteme is a MethodDescription. Calibration state, Method adequacy, report quality, and acceptance remain separate.

#Two Review Commissions

ProjectReviewAppointmentAssignment is a declared species. It declares three participant positions: HolderSystemSlot, local assigned kind, and ReviewCommissionSlot. ReviewAssignment-A and ReviewAssignment-B are two occurrences with Alice and ReviewerSystemRole in common but different commissions, and both cover the same interval. The case says that Alice performed ReviewWork-A under assignment A and ReviewWork-B under assignment B; it does not establish either crossed pairing. If the facts say only that Alice performed review Work while both appointments covered the interval, leave the attribution unresolved. The readable projection “Alice is reviewer” selects neither assignment and creates no generic assignment.

#Reviewer and Review Report

CommissionReviewAssignment is a declared species. It declares three participant positions: holder, local reviewer kind, and commission. Its rule applies to admitted review commissions and says that the fixed holder is appointed under the identified commission to supply the review contribution; one occurrence is the maximal uninterrupted interval for which that rule stays true. ReviewAssignment-82 is its occurrence for Alice and Commission-82, and it covers ReviewWork-82. The case identifies this as the assignment under which Alice performed that Work. ReviewReport-82 is a separate U.Episteme; it may state the attribution, and evidence may support reliance on that statement, but neither creates the Work–assignment fact. Use A.15.PROD only for a current report-inception claim. The report is neither the performer nor the attribution.

#Standard Used during Safety Work

A safety MethodDescription cites a standard, and source prose says that the standard has a “normative role”. Do not create an assignment for the standard. The standard remains an episteme in the external-rule, source-use, specification-use, or evidence relation selected by the claim.

A safety engineer or tool System can separately hold a covering safety-analysis assignment and perform dated safety Work. Attribution names the assignment occurrence and the case fact linking it to the Work; it does not use the standard as performer.

#Access Label and Approval Work

An access directory says Alice has DB-Admin. That entry describes an access or policy relation under its own scheme; it is not automatically an ApproverSystemRole assignment.

ApprovalCommissionAssignment is a declared species. It declares three participant positions: holder, local approver kind, and ApprovalScopeSlot. Its rule applies to admitted release scopes and says that the fixed holder is commissioned to supply approval within the identified scope; one occurrence is the maximal uninterrupted interval for which that rule stays true. ApprovalAssignment-481 is its occurrence for Alice and the current release scope. If it covers ApprovalWork-481 and the case identifies it as the assignment under which Alice performed that Work, the attribution is grounded. The directory entry may support a separate authorization claim but cannot substitute for the assignment or its link to the Work.

#Distributed Performers and Child Work

A.13 first recovers ReviewTeam-9 and Alice as the two exact actual performers through TeamReviewAssignment-9 and MemberReviewAssignment-A9, and A.15.1 independently admits JointReviewWork-9. Because this example expressly represents assignment-bound attribution for each performer, F.6 afterward establishes one relation for each Work-assignment pair through those same assignments. Neither assignment identifies or stands for the other performer. If AliceFindingCheckWork-9 is separately admitted as child Work after its own A.13/A.15.1 basis passes, add its covering assignment and F.6 link only because this example also expressly attributes that child Work, and keep its Work-part relation to JointReviewWork-9 separate.

#Passive Test Article

TestArticle-7, admitted as a U.System, holds TestSubjectAssignment-7 throughout ValidationWork-7. ValidationRig-2, also admitted as a U.System, actually performs the Work under its own ValidationPerformerAssignment-7; only that Work-attribution link is established. The test article's assignment and presence during the interval do not make it a performer. If the project needs to say that the article participated passively in the validation, use the domain rule that defines that participation; while no such rule is current, return the A.6.RCD missing-governor result rather than treating the assignment as participation.

#Bias Annotation

#Conformance Checklist

1. WorkOccurrenceSlot names one dated U.Work occurrence already admitted by A.15.1 without relying on F.6; its actual performers already have the A.13 core for the exact action, scope, working situation, and window, and any characteristic profile is required only by its own Grade, autonomy, criterion-dependent, profile, or assurance use.
2. SystemRoleAssignmentSlot names one assignment occurrence of a declared species under U.SystemRoleAssignment through U.RelationRef.
3. The assignment's declared species, all identity-bearing participants, rule, applicability, and uninterrupted occurrence identity remain recoverable. Each species keeps its SlotSpec ValueKind domains distinct from the participant values supplied by the occurrence; AssignedSystemRoleKindSlot takes one kind value from its declared local system-role-kind domain.
4. The case establishes that W was performed under RA; the assignment's existence, matching holder, and temporal overlap do not establish that link.
5. The assignment holder is the System that actually performed W.
6. The assignment predicate covers the selected Work interval; attribution to a Work part first identifies that part as U.Work.
7. Checks 2, 3, 5, and 6 constrain a valid attribution but do not by themselves establish it.
8. Overlapping assignments are distinguished by all their participants and by checking each Work–assignment link from the case; an unresolved case yields no blanket attribution.
9. Every positive precise attribution for a top-level or child Work occurrence has its own covering assignment and F.6 link to that already admitted Work; lead, team, member, allocation, coordination, and responsibility claims do not substitute.
10. A passive assigned System receives no performer attribution from assignment or overlap; any claimed passive participation uses the rule that defines it or returns the A.6.RCD missing-governor result.
11. F.6 uses performedUnderAssignment and introduces no RoleEnactmentFact or generic assignment duplicate.
12. Assertions and evidence may support reliance on the attribution claim but do not make it true.
13. Classification, assignment state, capability, Method, result, evidence, source reliance, publication, responsibility, authority, gate, and decision claims use direct patterns.
14. Any selected model-use structure is designated by the receiving assertion or use, not by an optional generic slot.
15. Missing evidence leaves reliance unresolved rather than proving non-attribution; missing pair grounding leaves the positive relation unasserted.
16. Source shorthand is unfolded before a receiver depends on hidden values.
17. The Method enacted by W remains a separate fact, and no kind, assignment, capability, Method, or description is made the actor.
18. A short practitioner sentence may omit declaration and occurrence detail only after the Work–assignment link and its constraints are established.

#Common Anti-Patterns and Repairs

#Consequences

Benefits. Assignment and Work remain independently identifiable, while attribution becomes a direct relation that can be cited, supported, corrected, or left unresolved. People, teams, organizations, machines, services, and software systems use the same pattern because every assignment occurrence exposes its admitted holder through the species-declared holder slot.

Costs. Reliance-bearing use must recover both the assignment occurrence and its declared species rather than stop at a familiar label. A compact sentence can split into assignment assertion, Work occurrence, attribution, Method enactment, change or production claim, result episteme, and evidence relation when the receiving use needs them.

Limits. F.6 determines neither classification, capability, readiness, Method validity, Work success, result acceptance, permission, authorization, responsibility, access, nor evidence sufficiency. It governs only attribution of one Work occurrence through one assignment occurrence.

#Rationale

The direct relation is needed because assignment and Work have different occurrence identities. performedUnderAssignment is an additional world-side fact, not a field stored inside either participant. A separate assertion can say that the assignment obtains, the Work occurred, or their attribution relation obtains.

Using the family ValueKind in F.6 does not license a family-wide assignment signature. It lets F.6 project the actual holder from each occurrence through its species-declared holder slot while preserving any commission, position, locus, or other real participant. Creating a generic assignment for F.6 would duplicate the episode and weaken attribution identity.

Making a log, status, decision, or evidence item a participant would confuse attribution with knowledge of attribution. Creating RoleEnactmentFact would duplicate Work and the same relation. Treating a matching holder and temporal coverage as enough would instead attribute one Work to every overlapping assignment held by its performer. The two-participant relation avoids both errors: the case fact linking Work to assignment is checked separately, while assertions and evidence can change without rewriting the Work, assignment, or their link.

#SoTA-Echoing and Source Use

Internal basis, not an external SoTA claim. A.2.1 and A.6.5 supply the declaration-local slot, domain, and participant-value discipline. A.2.5 keeps assignment state distinct from the assignment occurrence. A.6.REL supplies relation obtaining and occurrence identity. A.15.1 supplies dated Work and the actual-performer basis. F.6 uses these as its governing FPF neighbours; they do not replace comparison with external work.

The comparison is qualified on 2026-08-15 for this question and these source editions. gUFO is the current comparator because it directly addresses the classification–relational-aspect–occurrence separation at issue; PROV-O and OCEL answer narrower representation and logging questions and therefore serve as lineage and stress tests. A new edition number, publication status, or harmless wording change does not reopen the comparison. A material change to a distinction used above, or a competitor that offers a better direct Work–assignment attribution solution with at least the same exactness, readability, and use cost, reopens only the affected row and F.6 loci.

Refresh by meaning, not by publication. If A.2.1 or A.6.5 changes how an assignment species declares slot domains or how an occurrence supplies participant values, revisit §§4.3, 5, 7.1, and 9. If A.6.REL changes relation obtaining or occurrence identity, revisit §§4.1–4.2, 5, 7, and 9. If A.15.1 changes the actual-performer or covering-assignment basis, revisit §§4.4–4.6, 7, and 9. If a better direct Work–assignment solution changes the source decision, revisit §13 and only the solution or examples that depend on it. Wording or publication changes that leave these meanings intact require no refresh.

#Relations

Builds on: A.6.REL for relation obtaining and occurrence identity; A.2 for system-role kinds; A.2.1 for direct assignment species; and A.15.1 for dated Work.

Uses when current: A.2.5 for assignment state; A.2.2 for capability; A.3 and A.15 for Method and Work alignment; A.10 for evidence; A.15.4 for encountered-material reliance; C.3.3, F.9, and A.6.9 for cross-context use; and A.1.1 only when a selected model-use structure changes the receiving interpretation.

Coordinates with: F.4 for system-role-kind descriptions; F.5 and F.18 for names; E.17 for publication; and E.10.ROLE for ambiguous source wording.

#Completion Conditions

F.6 use is complete when the reader has one of these results:

• one direct performedUnderAssignment relation between exact Work and assignment occurrences;
• an unresolved attribution assertion naming the missing exact-pair fact, assignment species or participant, coverage, performer, or support claim; or
• a corrected route because the current claim concerns classification, assignment, state, capability, Method, evidence, source reliance, result, publication, permission, authority, responsibility, access, gate, or decision rather than performed-Work attribution.

#F.6:End

#Concept-Set Table

“Put exact local meanings and already established relations side by side; let the table display the argument, never create it.”

Status. Architectural pattern. Depends on. E.10.D1 Recovering What “Context” Means in Use; F.0.1 Source-Local Meaning Recovery; F.1 Question-Relative Source Selection; F.2 Term Harvesting; F.3 Source-Local Sense Clustering; F.17 for optional exact cells; F.5 Naming Discipline; F.9 for actual semantic relations and their separate bounded-use claims. Coordinates with. F.4 SystemRoleKindDescription; F.6 SystemRoleAssignment and Performed-Work Attribution Check; direct Part C patterns for the compared values; C.16 for characteristics; A.6.9 when umbrella sameness wording must be repaired before a relation is asserted. Aliases (informative). Concept-Set table; comparison grid; Giants’ table.

#Intent & applicability

Intent. Give a reader one compact surface for comparing exact source-local claims, optional F.17 cells, and any relations that already obtain between them. The table also shows the stated comparison or receiving use, direction, losses, evidence, and counterexamples. It makes a distributed argument readable without turning row membership into sameness or permission.

Use this when. Two or more selected sources must be compared for one named question, teaching contrast, designation choice, or receiving use, and prose alone scatters the relevant distinctions.

Do not use this when. One local claim is enough, or no receiving comparison is named. A table is optional. It creates no value, kind, relation, classification, assignment, evidence use, reliance, verdict, or authorisation.

#Problem frame

Cross-source comparison commonly fails through:

1. Silent equivalence: similar labels are treated as one meaning.
2. Loss denial: an actual relation is shown without direction or limitation.
3. Name inflation: a new umbrella label is coined merely because several entries share a row.
4. Cognitive scatter: source meanings, relations, evidence, and the receiving question are separated across documents.

#Forces

#Core idea (didactic)

A Concept-Set row is a didactic grouping for one stated comparison or use. It contains:

• the exact sources and editions;
• each source-local claim, or its F.17 SchemeSenseCell when durable addressability is useful;
• every already obtaining relation that matters here, with direction and declared loss;
• the separate conclusion about the named receiving comparison or use;
• the evidence or direct pattern that supports each substantive claim;
• a counterexample or boundary showing where the comparison stops.

The word set names the entries collected for display. It does not assert that they are one value. A row may show an identity, overlap, ordering, incompatibility, disjointness, or no relation at all, but only because that claim is established outside the layout. F.9 is used only when the actual relation is between distinct local meanings. For every other relation, cite the pattern that defines, constrains, or tests it.

#Minimal vocabulary

• Local entry — an exact LocalSenseClaim or optional F.17 SchemeSenseCell, with its source and edition and effective scheme.
• Obtaining relation — a relation already supported under its direct pattern; it is not inferred from co-placement.
• Direction — which participant is source and which is target when the relation is asymmetric.
• Loss or limit — what the relation or receiving use does not preserve.
• Receiving-use conclusion — the separate claim that judges whether and how the entries and relations may be used for one named purpose.
• Contrast row — a row that teaches a difference or an unresolved comparison and expressly asserts no sameness.
• Characteristic — a comparandum defined by its direct characteristic pattern; a table may display measured or target values but does not define the characteristic.

#The table

Use the smallest columns that make the current argument recoverable:

For a teaching contrast, the relation column may say none asserted and the conclusion may say keep distinct. For an F.9 relation, show its declared relation kind, direction, CL if that relation actually defines one, and loss. Do not compute a row-wide CL or replace the separate bounded-use claim with a table label.

Reading rules:

1. Entries stay local. A cell cites the source’s expression and claim; it is not a translation supplied by the table.
2. Relations stay direct. For each relation, cite the pattern that defines, constrains, or tests it and the evidence supporting the claim.
3. Use stays separate. “These may be compared for this report” is a claim with its own basis, not a property of the row.
4. Unknown stays unknown. A blank or unresolved relation is not an invitation to infer similarity.
5. Loss stays visible. If the limit needs more than one line, link to the underlying relation or evidence rather than compressing it away.

The nickname Giants’ table recalls that comparison relies on prior source work. It signals humility toward those sources, not authority supplied by the table.

#Conceptual construction

• Start from a question. State the comparison or receiving use before selecting entries.
• Bring exact local meanings. Use F.0.1, F.2, F.3, and F.17 only as needed.
• Bring relations, do not manufacture them. Cite the direct pattern and evidence for each relation that matters.
• State the receiving-use conclusion separately. Say what the current comparison permits, with its basis and limits.
• Keep the row small. Usually two to four entries are enough; add another only when it changes the answer.
• Use contrast honestly. When no adequate relation is established, show the difference rather than forcing a unification.

#Invariants

1. Exact entries. Every filled source-local cell identifies the exact source and edition and claim, or an exact F.17 cell.
2. No row-created relation. Co-placement, matching labels, or a shared FPF designation establishes nothing about the entries.
3. Direct relation basis. Every stated relation cites its direct pattern and available evidence; F.9 is conditional, not universal.
4. Separate receiving use. Any conclusion about comparison, substitution, reporting, or reuse is stated and supported separately.
5. Direction, time stance, and loss. Asymmetric relations show direction; any design-time, run-time, or other temporal difference that changes the comparison is explicit; every material limitation remains visible.
6. No automatic closure. Relations are not completed pairwise or transitively merely to fill a row.
7. No universal row type. A senseFamily label is not required and cannot substitute for an intensional account of what is being compared.
8. Parsimony. Keep only entries and columns that change the current answer.
9. Didactic bound. Split a row that a careful reader cannot understand in about thirty seconds.

#Micro-illustrations

The examples show table shapes. Every positive relation still requires its own evidence in an actual use.

#(a) Class-order comparison

#(b) Measurement comparison

#(c) Contrast: process

#Anti-patterns & remedies

#Worked examples

#Actor wording across BPMN and PROV

#Runtime occurrence comparison

Performed-Work attribution remains an A.15.1 and F.6 claim about actual Work and system-role assignment. The table supplies neither.

#Measured value and target

#Class inclusion and FCA order

A contrast row may show OWL class inclusion, FPF subtype, and FCA concept order together while stating that FCA order is not class inclusion. A positive relation between the first two is still a separate claim with its own semantics and evidence.

#Role trigger word

Show NIST RBAC role as a permission grouping and a local system-role-kind claim as a kind whose instances are Systems. Mark them distinct subjects. Use E.10.ROLE to recover other uses such as relation participation or signature position; do not assign them one senseFamily merely because the spelling matches.

#Safe reasoning moves

1. Name the comparison. What question or receiving use makes the row worth having?
2. Recover each entry. Cite its exact source, scheme, expression, and local claim.
3. List only obtaining relations. For each, state direction when relevant, the pattern that defines, constrains, or tests it, the supporting evidence, the loss, and any temporal difference that changes the comparison.
4. Judge the use separately. Explain what the named use may conclude and why.
5. Expose absence. When no relation is established, say so and use a contrast row.
6. Resist closure. Do not invent missing pairwise or transitive relations.
7. Extend cautiously. Add a source only when its claim or relation changes the answer; re-evaluate the use conclusion.
8. Keep evidence visible. A table cell never replaces the evidence-use or reliance relation.

#Relations

Builds on:

• Use F.1 for the exact source cut and receiving question, and use F.2 and F.3 for exact expressions and source-local claims.
• Use F.17 only when durable local-meaning addresses are needed.
• Use F.5 for selected designations without making them the values being named.
• Use F.9 to define and test a relation between exact local meanings and to state the separate bounded-use claim when that is the actual relation family. A table creates none of these facts.

Constrains:

• F.4 may cite a table for reader navigation, but the direct kind description and C.3 membership criterion remain the basis for a local system-role-kind claim.
• F.6 may reuse a designation from the table; the row supplies neither classification, assignment, Work, nor performed-work attribution.

Used by. Part C patterns may use the table as a didactic comparison surface. B.3 may rely only on exact evidence and obtaining relations, never on row position or a computed row score.

#Migration notes

1. Relation changes. Update the exact relation cell and re-evaluate only the receiving-use conclusions that depended on it.
2. New source. Do not auto-expand rows; add it only if it changes the stated comparison.
3. Local claim splits. Replace the old entry with the relevant child claim or split the comparison.
4. Use widens. Re-evaluate the new use directly; a former row label grants no promotion.
5. Designation changes. Update F.5 wording without changing source-local entries or relations.
6. Edition changes. Recover the successor claim and recheck affected relations; preserve the earlier source identity where historical claims remain relevant.

#Acceptance tests

#Static conformance

• SCR-F7-S01 (exact entries). Every local entry identifies an exact claim or F.17 cell and its source and edition.
• SCR-F7-S02 (no row-created fact). No relation or permission is inferred from co-placement, label similarity, or layout.
• SCR-F7-S03 (relation basis). Every positive relation cites the pattern that defines, constrains, or tests it, states direction where relevant, and cites its evidence.
• SCR-F7-S04 (receiving use). Every practical use conclusion is separate from the row and has its own basis.
• SCR-F7-S05 (loss disclosure). Material limitations and counterexamples remain visible.
• SCR-F7-S06 (parsimony). Every extra entry changes the current comparison or use.

#Regression

• RSCR-F7-E01 (relation drift). A changed relation triggers re-evaluation of dependent use conclusions, not a global row score.
• RSCR-F7-E02 (sense split). A split local claim leaves no ambiguous cell reference.
• RSCR-F7-E03 (use integrity). No consumer treats a row label as licence outside the stated conclusion.
• RSCR-F7-E04 (no stealth growth). New entries create no silent relation, closure, or widened use.

#Didactic distillation

“A Concept-Set table is a comparison surface. Put the exact source-local claims in it, then list only relations that have already been established, with direction and loss. State separately what one named comparison or use may conclude and why. A shared row, a shared label, or a minimum score proves nothing. If no relation is known, show a contrast. The table makes the reasoning easier to read; it never supplies the reasoning.”

#F.7:End

#Mint-or-Reuse Decision

Type: Architectural pattern Status: Stable Normativity: Normative unless marked informative

#Use This When

Plain name. Keep, reuse, or strengthen a name.

Use F.8 after the subject is known and a project must decide the smallest naming treatment for one expression and one use. Start only when these four facts are available: the expression, the governed value or relation, its subject pattern, and the proposed naming use.

Typical triggers include:

• a familiar source word may be useful locally but would import the source ontology if promoted;
• a role-like word such as ReviewerRole, AccessRole, or EvidenceRole may name a system-role kind, another governed value or relation, or only ordinary wording;
• an alias, subject-pattern name, or F.17 row may already serve the use, but only within its stated meaning and scope;
• a governed value may need a durable name, public row, or policy identifier; and
• pressure for a new U-kind appears. That last case stops before naming until E.24.UK has returned a stable admission disposition.

Primary working object. One F.8 disposition for the expression and proposed use. Ordinary use creates no decision occurrence or result episteme. If a later claim must cite, replay, or assign accountability to the decision itself, use the separately triggered branch in §4.5.

Primary working reader. An engineer-manager, analyst, method author, pattern author, or terminology steward choosing whether an expression should stay local, reuse a name, or open a stronger naming path.

First useful move. Write the four starting facts. Then try, in order, a local phrase, an existing designation, an alias, the subject pattern's name, and an admitted F.17 row. Stop at the first sufficient result. Open a cell, NameCard, public row, or policy identifier only when the receiving use needs it.

What goes wrong if missed. A convenient expression is treated as the subject it merely names. Local or source wording becomes durable ontology; a row or alias gains uses it never admitted; a role-like word hides a kind, description, assignment, Work occurrence, or another governed relation; or a record is mistaken for the decision it describes.

What this buys. Teams get short usable names without creating duplicate kinds or naming records. Stronger names are harder to introduce but easier to trust because the governed subject and use remain visible.

Not this pattern when.

• For one-off wording repair, use F.19; use E.10, E.10.ARCH, A.6.P, or the subject pattern when a meaning still needs recovery.
• If the governed subject or relation is not yet known, recover it first. For an unsettled U-kind proposal, use E.24.CD when the object is unclear and E.24.UK for admission.
• To constitute a SystemRoleKindDescription, use F.4. To assign a system, use A.2.1. For precise performed Work, recover each exact actual performer through A.13 and let A.15.1 independently admit the dated occurrence; add F.6 only when the naming case or receiving use expressly consumes precise assignment-bound attribution through the same obtaining A.13 assignment.
• For an obtaining relation between different local-sense projections, use F.9. Use F.17 when a public, Core-facing, durable, or cross-local row is needed.
• For a status, evidence use, policy, Method, Work, publication, or any other governed subject, use its subject pattern before naming it.
• After F.8 has selected a name family, use F.5 for its naming discipline and F.18 only for a durable naming settlement.

#Problem Frame

Name pressure often reveals an unresolved subject. One word may be offered for different things—for example, a designation, local system-role kind, optional description of that kind, assignment occurrence, status value, policy identifier, or Work label. Shared spelling proves none of these identities.

F.8 therefore asks what the expression will designate and for which use before judging the wording. It is the gate from a local expression to a stronger naming treatment. It neither defines the governed value nor performs the later naming work.

#Problem

Without this pattern:

1. Local or source wording becomes durable ontology. A temporary phrase or familiar standard term survives without a recovered subject and use.
2. Role-like wording collapses different objects. A local system-role kind, its optional F.4 description, an A.2.1 assignment, performed Work, or another governed relation receives one misleading label.
3. Reuse widens silently. An alias changes meaning, or an F.17 row admitted for naming is reused for equivalence, assignment, measurement, or structural inference.
4. Naming is asked to admit ontology. A proposed U-kind enters F.8 before E.24.UK has settled whether the result is an admitted kind, reused kind, local kind, or recovered non-kind object.
5. Identifiers and records act by proxy. A policy identifier lacks a resolvable specification, or a filled record is treated as the decision occurrence or result it describes.
6. Locality labels become subjects. A review, team, project, or date label is used as if it created Work, assignment, evidence, status, or authority.

#Forces

#Solution

Treat mint-or-reuse as a decision about an already recovered subject, not a vote on wording. Start with four facts:

1. the candidate expression;
2. the governed value or relation;
3. the subject pattern that defines or tests that value or relation; and
4. the proposed naming use.

If any fact is missing, stop at the subject-recovery route; naming cannot supply it. Otherwise try the dispositions in this order and stop at the first one that supports the proposed use:

1. keep a local phrase;
2. reuse an existing designation;
3. use an alias without changing the governed meaning;
4. reuse the subject pattern's name;
5. reuse an admitted F.17 row within its stated use;
6. name a separately justified SystemRoleKindDescription when that is the governed object;
7. open a durable naming settlement;
8. propose a public row;
9. introduce a policy identifier for an already recovered policy specification; or
10. block or lower the naming use.

The smallest result is one readable sentence, not a mandatory record: state the governed subject, proposed naming use, selected disposition, resulting name when any, and the change that would reopen the decision. Add a non-use boundary only when F.19's grounded-contribution test admits it. For example, when no lighter disposition supports a needed durable local designation: “Under PatternReviewReferenceScheme-2026, use ReviewerRole as the Plain designation of ReviewerSystemRole for local review-method prose; select openDurableNamingSettlement and revisit the decision if the naming use becomes public or cross-local.”

The corresponding F.8 result labels are localPhraseOnly, reuseExistingDesignation, aliasOnly, reuseDirectPatternName, reuseAdmittedTermRow, nameSystemRoleKindDescription, openDurableNamingSettlement, proposePublicTermRow, introducePolicyIdentifier, and blockOrLowerUse. They are not new U.* kinds. A stronger result opens its subject pattern; it does not itself create a card, row, identifier, policy specification, or relation occurrence.

#Decision Targets

#Decision Sequence

Use this order and stop at the first disposition that supports the proposed use without hiding a governed distinction.

1. Recover the four starting facts. Name the expression, governed value or relation, its subject pattern, and the proposed use. If the value or relation is not available, stop and use its subject-recovery route; F.8 cannot establish it.
2. Split mixed candidates. If one expression covers more than one governed subject or use—for example, a kind, assignment, evidence use, policy, Method, or Work—make separate naming decisions.
3. State the naming locality. Carry the naming U.ReferenceScheme by value and state the local-sense claim. Cite a SchemeSenseCell, an obtaining LocalSenseBasisRelation, or a selected bounded-model-use Structure only when the naming use needs that object.
4. Apply F.14 and try a local phrase. If ordinary local wording supports the use, choose localPhraseOnly and stop.
5. Try an existing designation. Reuse it only when the value, kind, scope, occurrence identity, local sense, and proposed use match.
6. Try an alias. Use aliasOnly when the governed meaning is unchanged and lineage can expose the wording variation. An alias may not change kind, scope, occurrence identity, use, or authority.
7. Try the subject's existing name. Use the name supplied for the governed subject. A.2 and C.3 govern a local system-role kind and F.5 governs its designation; use F.18 only for a durable settlement and F.4 only for a separately needed SystemRoleKindDescription. A.2.1 continues to govern any assignment. For precise performed Work, A.13 first recovers each exact actual performer and A.15.1 independently admits the occurrence; F.6 follows only when the naming case or receiving use expressly consumes precise assignment-bound attribution through the same obtaining A.13 assignment.
8. Try one admitted F.17 row. Reuse only the row's declared AdmissibleUse. Local-sense reuse does not imply cross-local sameness; a row and equal spelling create no F.9 Bridge.
9. Open only the next naming object that pays for itself. A stable local address may justify a cell; an enduring naming settlement may justify a NameCard; a public/Core/durable/cross-local need may justify an F.17 row. None implies the next object.
10. Introduce a policy identifier only for a recovered policy specification. A local identifier can stop with that specification and its scope. If the mint history is cited, replayed, normative, cross-local, or accountable, recover its decision or choice occurrence through the subject pattern; otherwise return missing-governor for that stronger history claim. Keep any C.11 result, decision-making Work, result episteme, and record separate.
11. Stop before naming an unsettled U-kind proposal. Select blockOrLowerUse. If the governed object is still unclear, use E.24.CD; otherwise send the recovered proposal episteme or source construct to E.24.UK. F.8 does not test or admit the candidate. After E.24.UK returns a stable root, same-individual-dependent, identity-dependent, reuse, local-kind, or reject disposition, re-enter F.8 only if the admitted or reused kind, local kind, or recovered non-kind object needs a designation.
12. Block or lower. If no disposition is justified, keep the expression local, quote it as source wording, or lower the claim.

#Role Expression Boundary

A role expression is not enough to choose the object. For a system-role naming case, keep these four objects distinct:

Under the effective naming scheme, L designates K. Needing L does not create or require D; D may receive its own designation when a separate description is justified. Naming either object creates no A. The naming ReferenceScheme interprets the expression; it neither defines the kind nor assigns a system.

After A.2 and C.3 have recovered K, apply the naming ladder. Keep a one-off expression local when that is enough, and reuse an existing designation when it fits. If the kind needs a durable designation, select openDurableNamingSettlement, use F.5 to name K, and use F.18 for the durable settlement. Use nameSystemRoleKindDescription and F.4 only when the governed object is a separately justified description episteme D.

#F.17 Row-Scope Consumption

F.8 consumes one named F.17 row and its declared use; it neither constitutes the row nor defines Bridge strength. F.17 keeps the row episteme, governed value, designations, cell, basis relation, any F.9 Bridge, edition relation, and publication package distinct. F.8 asks only whether AdmissibleUse covers the proposed naming use.

If the row does not admit the proposed use, lower the name's use or repair the F.17 row and any needed F.9 relation. Attractive wording supplies neither a stronger use nor cross-local sameness.

#Accountable Decision Branch

Open this branch only when a receiving claim needs to cite, replay, or assign accountability to the mint-or-reuse decision occurrence itself. First recover that occurrence through the decision or choice pattern that admits it. The ordinary naming result remains valid without this branch.

Keep these objects distinct in the accountable branch:

• the governed value or relation and its subject pattern;
• the candidate expression, selected designation, and any alias;
• the effective naming U.ReferenceScheme, local-sense claim, optional SchemeSenseCell, and any obtaining two-participant LocalSenseBasisRelation;
• the decision or choice occurrence and the pattern that admits it;
• any C.2.1 decision-result episteme and the record or carrier that designates it;
• any F.18 NameCard, F.17 row, policy specification, policy identifier, publication occurrence, form, or carrier; and
• a selected bounded-model-use Structure only when its organization changes interpretation for this naming use.

When a result episteme is needed, use the full projection below:

MintReuseDecisionResultEpisteme:
  DecisionResultEpistemeId:
  EntityOfConcernRef: [decision or choice occurrence already admitted by its direct pattern]
  DecisionGovernorLocator:
  DecisionPredicateRef:
  DecisionParticipantRefs: [actual participants with their meanings]
  DecisionApplicability:
  DecisionOccurrenceIdentityBasis:
  DecisionMakingWorkRef?: [separate A.15.1 Work only when current]
  DecisionOrChoiceResultRef?: [separate result, such as a C.11 ChoiceResult, only when current]
  CandidateExpression:
  GovernedValueOrRelationRef:
  GovernedKindOrRelationKindRef:
  GovernedValueSubjectPatternLocator:
  ProposedNamingUse:
  EffectiveNamingReferenceScheme: [U.ReferenceScheme carried by value]
  LocalSenseClaim:
  LocalSenseCellRef?: [only when a current SchemeSenseCell is needed]
  LocalSenseBasisRelationRef?: [only when the cell-to-basis-episteme relation obtains]
  SelectedModelUseStructureRef?: [only when a selected Structure changes this use]
  ReuseCandidateRefs?:
  SelectedDisposition:
  ResultingNamingRefs?: [only objects current after the disposition]
  NonAdmissibleOverread?: [only when admitted by `F.19`'s grounded-contribution test]
  ReopenCondition:

The block describes the result episteme. EntityOfConcernRef resolves to the decision or choice occurrence admitted through DecisionGovernorLocator; the predicate, participants, applicability, and identity basis show why that occurrence exists. GovernedValueSubjectPatternLocator identifies the pattern for the value being named. NonAdmissibleOverread is included only when admitted by [F.19](/generated/patterns/F.19)'s grounded-contribution test. A C.11 ChoiceResult and dated decision-making Work keep their direct identities and relations. If the occurrence and its governor cannot be recovered, do not instantiate the block: return the A.6.RCD missing-governor result. If no result episteme is needed, state the ordinary result and stop.

#Invariants

1. Four facts, one use. Every disposition names the expression, governed value or relation, its subject pattern, and one proposed use. Split an expression that covers more than one governed subject or use.
2. Lightest sufficient result. Try the ordinary reuse ladder before creating a cell, NameCard, row, or policy identifier. An unsettled U-kind proposal stops before naming.
3. Reuse preserves meaning. Reuse or aliasing changes no kind, scope, occurrence identity, local-sense claim, admitted use, authority, or lineage. Shared spelling under another scheme establishes neither sameness nor an F.9 Bridge.
4. Kind, description, assignment, and Work stay distinct. A designation may name a recovered local system-role kind K without creating the optional F.4 description D. Neither name classifies a candidate, creates an A.2.1 assignment A, or demonstrates Work. Other governed uses remain with their subject patterns.
5. Rows stay within admitted use. Reusing an F.17 row supplies only its AdmissibleUse and no equivalence.
6. Ordinary and accountable decisions stay distinct. Ordinary F.8 use needs no decision occurrence or result episteme. The §4.5 branch opens only after the decision or choice pattern admits the occurrence; otherwise it returns missing-governor.
7. Naming objects imply none of one another. A designation, cell, basis relation, NameCard, row, identifier, publication occurrence, form, or carrier is created only for its receiving use. A selected Structure appears only when its organization changes interpretation of this naming use.
8. Admission precedes naming. Before E.24.UK returns a stable disposition, F.8 can only block or lower the proposed naming use. Afterward it may name only the admitted, reused, local, or recovered non-kind object identified by that result.
9. Policy identifiers remain references. Every identifier resolves a policy specification. Its mint occurrence and history are required only for the stronger uses stated in §8.1 and remain distinct from any C.11 result, decision-making Work, result episteme, or record.
10. Labels grant no authority. A source title, suffix, row, record, or identifier creates no governed subject, obtaining relation, permission, evidence, equivalence, or publication authority.

#Reasoning Checks

Use these as reading checks, not as a required notation or record.

#Archetypal Grounding - worked cases

#ReviewerRole Expression vs Review Report

The source label PatternReview_2026 is not a context object. Classify the actual claim before using it:

• ReviewWork-82 can be one dated U.Work occurrence under A.15.1;
• ReviewPlan-2026-v3 can be a separately constituted plan episteme or edition under its subject pattern;
• PatternReviewReferenceScheme-2026 can be an effective by-value U.ReferenceScheme for interpreting review terminology; and
• "used while deciding the label for the 2026 review method" can be claim content describing the decision-use setting without minting any context entity.

If the recovered ReviewerSystemRole kind needs a durable local designation, F.8 returns openDurableNamingSettlement: A.2 and C.3 keep governing the kind, F.5 governs its designation, and F.18 supplies the settlement. The recovered kind is the governed subject; F.4 enters only for a separately needed description, A.2.1 for an assignment, and A.15.1 for performed review Work.

The expression "review report has reviewer role" is a different case. ReviewReport-82 is an episteme. An evidence, source, or publication relation may later use it for an adequacy claim about a reviewed pattern; the report is not a U.System, is not classified by the review-system-role kind, and cannot enter its assignment relation. Its title establishes neither evidence use nor publication authority.

#Actor Across BPMN and PROV

A manager wants one word, "actor", for a BPMN participant and a PROV agent in a diagram. First recover the two local senses under their ReferenceSchemes. If an obtaining F.9 Bridge relates the named cells and an F.17 row admits naming-only use, F.8 returns reuseAdmittedTermRow for prose and diagram labels only. This supports no governed-value identity, substitution, system-role assignment, or Work.

If the project later needs a local system-role kind under one scheme, it first recovers the kind through A.2 and C.3. F.5 then governs any new designation, with F.18 only for durable reuse; F.4 is added only if a separate description episteme is needed.

#Access Role

An access-control source says ApproverRole. Under its naming ReferenceScheme, the expression may designate a permission grouping or policy relation. First recover the access, policy, status, or deontic claim and predicate. Only if A.2 and C.3 recover a local approval-system-role kind does F.8 consider a name for that kind. F.5 governs its designation, F.18 applies only for durability, and F.4 remains optional for a separately needed description.

Otherwise any needed durable designation belongs to the access, policy, status, or gate pattern. The Role suffix, a source card, or a selected model-use Structure creates no local system-role kind or assignment.

#Policy Identifier

A gate profile proposes Aut-Guard-2026. F.8 treats this as a policy-identifier question only after the policy specification is recovered. Ordinary reuse resolves the identifier and specification. Recover the mint decision or choice occurrence only when reuse relies on that history for citation, replay, accountability, supersession, or another named relation. If a new introduction makes that stronger claim without an occurrence basis, return missing-governor. Any C.11 result, decision-making Work, result episteme, or record stays separate.

The identifier is not the specification, local system-role kind, Method, gate result, evidence value, permission, or source authority. It is a reference used by the pattern that defines or constrains the governed policy claim.

#New U-kind Candidate

A team proposes U.InfluenceEdge because many documents use "influence". At F.8 entry there is no recovered governed value with a stable admission disposition, so F.8 returns blockOrLowerUse and stops naming. If the expression still hides whether the subject is an existing relation or claim—for example, a causal, evidence, Method, or Bridge relation—or a characteristic, structural name, publication form, local frame, or another object, E.24.CD recovers that object or the unresolved proposal. A recovered governed object returns to its subject pattern; a surviving U-kind proposal goes to E.24.UK for root, same-individual-dependent, identity-dependent, reuse, local-kind, or reject. Only after that result is stable may F.8 reopen for a name of the admitted or reused kind, bounded local kind, or recovered non-kind object. F.8 creates neither the proposal object nor a public spelling and admits no kind.

#Readable Disposition and Explicit Stops

The ReviewerRole case closes with one readable result. The recovered kind is a local U.Kind for U.System candidates, distinguished by its stable review contribution and tested by its KindSignature; any assignment remains separate. The result is:

Under PatternReviewReferenceScheme-2026, use ReviewerRole as the Plain designation of ReviewerSystemRole for local review-method prose. No existing designation or alias supports that use, so select openDurableNamingSettlement: A.2 and C.3 continue to govern the kind, F.5 governs its designation, and F.18 supplies the durable settlement. Reopen it if the proposed use becomes evidential, status-bearing, access-related, source-facing, published, or cross-local, or if another change of use or audience exceeds this local settlement's scope.

That sentence is the F.8 result. It needs no decision occurrence or result episteme. If a later claim must cite, replay, or assign accountability to the decision, use §4.5. No naming-decision governor is available in this case, so that branch returns missing-governor rather than inventing ReviewerSystemRoleNamingDecision-2026-07-31. C.11 applies only to a genuine local choice among available options. For any precise decision-making Work, A.13 first recovers the exact actual performer and A.15.1 independently admits the dated Work; F.6 follows only when the later claim expressly consumes precise assignment-bound attribution through the same obtaining A.13 assignment.

EvidenceRole stops earlier and does not enter F.8. The known subject is ReviewReport-82 : U.Episteme, proposed for evidence use concerning an adequacy claim. Still missing are the target claim and polarity, the evidence-use relation and relation kind, the provenance and any assurance or reliance use and validity window, and one subject pattern that defines the relation. Apply that pattern and keep the wording local until those facts are recovered. PatternReviewReferenceScheme-2026 may interpret the source wording, but the review label creates no evidence relation, system-role kind, description, assignment, authority, or publication. No SchemeSenseCell, LocalSenseBasisRelation, or selected Structure is needed merely to record this stop.

Re-enter F.8 only after one governed relation, its kind, its subject pattern, and the proposed naming use are available. If the target claim, polarity, provenance, assurance or reliance use, or validity window changes, reopen the subject claim rather than the name.

#Bias-Annotation

F.8 counters two shortcuts: a familiar word is treated as proof that a stronger name is needed, or a record is treated as the subject or decision it describes. Recover the four starting facts, choose the lightest disposition, and add a Structure, decision result, NameCard, row, or publication object only when its own receiving use requires it.

#Policy-Identifier Mint-or-Reuse Discipline

FPF treats policy identifiers such as Phi(CL), Phi_plane, Psi(CL^k), Aut-Guard, EmitterPolicyRef, insertion-policy identifiers, and acceptance-clause identifiers as versioned references whose meaning must be recoverable. They are not "just strings", system-role-kind names, gate decisions, permissions, or policy specifications.

PolicyIdentifierReference:
  PolicyIdentifier:
  PolicySpecificationRef:
  MintDecisionOrChoiceOccurrenceRef?: required only for cited, replayed, normative, cross-local reuse, or accountable mint history
  MintDecisionSubjectPatternLocator?: paired with MintDecisionOrChoiceOccurrenceRef
  MintDecisionPredicateRef?: paired with MintDecisionOrChoiceOccurrenceRef
  MintDecisionParticipantRefs?: [actual participants with their meanings]
  MintDecisionApplicability?:
  MintDecisionOccurrenceIdentityBasis?:
  MintDecisionMakingWorkRef?: [separate A.15.1 Work only when current]
  MintDecisionOrChoiceResultRef?: [separate result, such as a C.11 ChoiceResult, only when current]
  MintDecisionResultEpistemeRef?:
  ScopeOrNamespaceRef:

PolicyIdentifier is the selected designator. PolicySpecificationRef resolves to the separate policy-definition episteme and pins an edition or equivalent digest when needed. A local non-accountable introduction can stop there with explicit local scope. The conditional mint-occurrence fields are required when the use cites, replays, makes normative, reuses across the local boundary, or assigns accountability to the mint history; together they resolve one admitted decision or choice occurrence and the pattern, predicate, actual participants, applicability, and identity rule that establish it. If that stronger use is requested and those facts are absent, return missing-governor for it rather than inventing an occurrence. A C.11 ChoiceResult and any dated decision-making Work remain separate. MintDecisionResultEpistemeRef, when current, resolves to a C.2.1 episteme or accepted record describing the occurrence; the record does not perform the decision.

For FPF normative policy identifiers, the durable result episteme is usually an accepted [E.9](/generated/patterns/E.9) decision record, but only after the decision or choice pattern has admitted the occurrence that record describes. A local non-exported and non-accountable identifier needs only its separately recoverable specification and explicit scope; it need not create a decision or result episteme. In every branch, the policy specification, identifier, any decision or choice occurrence, any C.11 result, any decision-making Work, and any record remain distinct.

Rules:

1. No silent policy-identifier introduction. Every new identifier resolves the separate PolicySpecificationRef and states its scope. A local non-accountable introduction stops there. A cited, replayed, normative, cross-local, or accountable mint history additionally resolves the decision or choice occurrence plus the pattern, predicate, participants, applicability, and identity rule that establish it; without that basis, return missing-governor for the stronger branch and do not claim it.
2. Reuse is reference use. Reusing an existing identifier resolves the same identifier and policy specification. Resolve the original mint occurrence only when the current reuse consumes or asserts that history; it does not restate policy semantics, turn a record into the occurrence, or silently create another decision.
3. Gate checkability. A gate, crossing, Bridge, assurance, or publication claim that depends on a policy identifier includes PolicyIdentifierReference or an equivalent resolvable structure admitted by its subject pattern.
4. Policy authority stays with the subject pattern. F.8 selects introduction or reuse of the identifier; it does not decide whether the policy permits Work, passes a gate, makes a relation obtain, or provides evidence.
5. The identifier grants nothing by itself. Name, namespace, suffix, source prestige, specification publication, or decision record grants no permission, status, equivalence, or authority beyond the policy claim defined by its subject pattern.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

Good consequences:

• vocabulary grows only when a receiving use needs a stronger name;
• role-like, source, and record-like expressions return to their governed subjects before naming;
• aliases and F.17 rows retain their admitted meaning and scope;
• F.5 and F.18 receive a recovered subject and a selected naming path; and
• accountable decisions and policy identifiers remain inspectable without making their records act.

Costs:

• authors must recover the subject, pattern, use, scheme, and local sense before naming;
• mixed expressions need separate decisions, and some attractive words stay local or remain aliases;
• durable or public use may require its own NameCard, Bridge, row, reliance, decision result, or publication object; and
• a proposed U-kind receives no F.8 name before E.24.UK settles admission.

Refresh by meaning, not by neighbour edition.

• If F.14, F.5, F.17, or F.18 changes the lightest-sufficient naming ladder, row-entry threshold, AdmissibleUse, or escalation to a stronger naming object, revisit §§0 and 4.1–4.4, case 7.2, checks 03–09, and the compact corpus entry.
• If A.2, C.3, F.4, A.2.1, A.13, A.15.1, or F.6 changes how a local system-role kind is recovered, how L, K, D, and A relate, how an exact actual performer and Work are admitted, or when precise assignment-bound attribution enters, revisit the corresponding target rows, step 7, §4.3, cases 7.1, 7.3, and 7.6, invariant 4, and checks 06–08.
• If A.6.RCD, C.11, C.2.1, or A.15.1 changes how a decision or choice occurrence, result, result episteme, decision-making Work, or missing governor is established, revisit §4.5, the accountable stop in 7.6, invariant 6, and check 10.
• If E.24.CD, E.24.UK, A.8, or A.11 changes object recovery, admission dispositions, or the admission-before-naming order, revisit the entry and ordinary conditions for use, stopping, or returning, the pre-admission target and step 11, case 7.5, invariant 8, and check 12.
• If the policy subject pattern, E.9, A.6.RCD, C.11, or C.2.1 changes the policy specification–identifier distinction or the support required for mint history, revisit the policy target, step 10, case 7.4, §8.1, invariant 9, and checks 10 and 13.
• If a source used in §12 changes a distinction that F.8 adopted, or a better current source preserves the needed precision and readability at lower use cost, revisit that source row and only the F.8 loci named by it.

A new edition number, publication status, link, harmless wording repair, or added example does not reopen F.8 when these meanings stay unchanged. A changed disposition, governed subject, kind or relation, admitted use, ordering dependency, or better solution reopens only the dependent loci named above.

#Rationale

A naming mistake is often a subject or use mistake. Asking “what name should we use?” too early lets wording decide ontology, scope, or authority. F.8 therefore recovers the subject and proposed use before selecting a naming treatment.

F.8 is narrower than F.18. It decides whether the expression stays local, reuses something available, or opens one stronger naming path. F.18 runs a durable settlement, candidate comparison, NameCard, lineage, and any later public-row gate. F.8 creates neither the governed value nor the objects produced by the stronger path.

The system-role branch shows why the ordering matters. A designation L, local system-role kind K, optional F.4 description D, and any assignment A are different objects. The word role can also point to another governed subject. Recovering that subject first keeps naming from creating a false kind or assignment.

The accountable branch follows the same rule. A decision occurrence, C.2.1 result episteme about it, C.11 result, decision-making Work, and rendered record answer different questions. Section 4.5 opens only when a receiving claim needs that stronger traceability; ordinary F.8 use stops earlier.

#SoTA-Echoing - Source-Use

Qualification and selection rule. These decisions are qualified on 2026-08-15 for the cited editions and the F.8 questions below. The set is deliberately small. ISO 704 and SKOS are current standards or durable lineage, not claimed as research frontiers. The gUFO–OBO row combines a current formal comparator with an operational ontology-maintenance practice. The Cedar row is a current research-and-practice comparator. A source belongs here because it changes an F.8 disposition or boundary, not because it is official, popular, or easy to find.

Internal FPF basis, not external SoTA.

• F.14, F.5, F.17, and F.18 supply the local-phrase, designation, alias, row-use, and durable-naming ladder.
• A.2, C.3, and F.4 keep designation L, local system-role kind K, and optional description D distinct; A.2.1 governs assignment A. For precise performed Work, A.13 recovers each exact actual performer and A.15.1 independently admits the dated occurrence; F.6 is a later separate relation only when precise assignment-bound attribution is expressly consumed.
• E.24.CD, E.24.UK, A.8, and A.11 recover an unclear object and decide kind admission before F.8 names the result.
• A.6.RCD, C.11, C.2.1, and E.9 govern any accountable decision occurrence, separate result, result episteme, and policy-history record.
• F.1–F.3 and F.9 govern local-sense discovery and an obtaining Bridge; A.1.1 and A.22 govern any selected bounded-model-use Structure. F.8 cites those objects only when the naming use needs them.

Source-use boundary. External sources can supply candidate expressions, a comparison pressure, or a narrow representation test. They do not select the F.8 disposition, establish the governed subject, make a relation obtain, admit a kind, or grant authority. Those results remain with the named FPF pattern and the recovered facts.

#Relations

Builds on. A.7, E.24.UK, A.8, A.11, E.10, E.10.ARCH, F.19, F.1, F.2, F.3, F.5, F.9, F.14, F.17, and F.18.

Coordinates with. A.2, A.2.1, A.2.5, A.2.7, A.6.5, A.6.RCD, A.15, A.15.1, C.11, F.4, F.6, F.10, F.13, F.15, C.2.1, C.3, E.9, E.24.CD, and E.24.PUB, plus the subject pattern for any other governed value.

Constrains.

• F.5 names only after F.8 has selected the naming case.
• Use F.4 only for a separately needed SystemRoleKindDescription; naming the local kind itself does not require that episteme.
• F.9 governs an obtaining Bridge between F.17 cells; F.17 governs admitted public-row use before F.8 reuses it.
• F.18 expands durable naming only after lighter dispositions have failed.
• F.14 supplies the anti-explosion stop before every stronger F.8 disposition.
• F.15 may check the resulting distinctions; it neither chooses the disposition nor creates a naming object.

Does not replace. The subject pattern for any governed value or relation. For example, it does not replace the rules for a system-role kind, assignment, performed Work, decision occurrence, status, evidence use, policy, relation slot, selected Structure, or description episteme.

#Didactic Memory

Name the subject and use before judging the word. Try the light naming ladder and stop at the first sufficient result. An unsettled U-kind goes to E.24.UK before naming; an accountable decision opens §4.5 only when the decision occurrence itself must be used. A name, card, row, identifier, publication, or record creates neither the subject nor any relation or authority it mentions.

#F.8:End

#Alignment and Bridge across Contexts

Type: Pattern Status: Stable

"Translate across contexts; never collapse them."

Type: Architectural pattern. Status: Stable. Normativity: Normative. Builds on: F.17 for exact scheme-based SchemeSenseCell identity and SenseCellAddressRef; F.18 for designation selection; C.2.1 for assertion and description-episteme identity; F.0.1 for senseFamily and bridge-only crossing discipline; F.7 and F.8 for downstream naming and reuse decisions.

Coordinates with: A.6.REL for demand-driven occurrence individuation; C.2.1 for assertion, occurrence-description, and Card identity; E.24.PUB for publication occurrence, form, and carrier; A.10 for evidence-provenance relations and local reliance dispositions; B.3 for actual named assurance claims and their bounded AssuranceResult values; E.10.ROLE for claim-bearing source wording with role; A.2, C.3, F.4, F.5, and A.2.1 for local system-role kinds and assignments; A.13 and A.15.1 for exact actual performers and independently admitted Work; F.6 only for a precise assignment-bound attribution expressly consumed by the Bridge use; A.6.5 for relation-slot discipline; C.29 for mathematical-lens use; A.6.3.CSC for controlled coarsening; C.26.1 and C.26.2 for quantum-like export boundaries.

Plain entry cues (informative). Context-to-context translator; sense bridge.

#Intent and applicability

Intent. Govern one actual semantic Bridge relation between two exact F.17 SchemeSenseCell values from different semantic contexts. Keep that occurrence separate from every assertion, Bridge description episteme, Bridge Card, registry record, publication occurrence, publication form, presentation carrier, bounded-use claim, evidence or assurance relation, and object created when a proposed use is actually performed.

Applicability. Use this pattern when an author needs to compare local senses across contexts, reuse a familiar label, connect design-time and run-time senses, compare two standards' terms, or justify a cross-context row. A shared word or available mapping is only a reason to ask whether a Bridge obtains.

Primary EntityOfConcern in plain terms. One actual correspondence or difference between two exact local senses. This pattern concerns the direct Bridge occurrence, not a card, context, transport chain, work process, local system-role kind, assignment occurrence, evidence item, or global meaning layer.

Admissible move in plain terms. First resolve the two local senses. Then state and test the correspondence or difference between them. If the Bridge obtains, state the proposed use separately: what the reader will do, direction, correspondence rule, and tolerated loss. A current C.2.1 claim answers whether the Bridge suits that bounded use. Check ordinary reliance under A.10; use B.3 only when an actual named assurance claim is current. If the use happened, recover its Work, assertion, publication, relation, operation application, or other object under its subject pattern. Add a Bridge Card only when a reusable package is worth maintaining.

Primary working reader. An author, checker, or practitioner deciding first whether a cross-local semantic relation actually obtains and then whether it supports one named use.

Use this when. Use F.9 when a receiving claim needs an exact semantic relation between two local senses whose <ReferenceScheme, LocalSenseClaim> interpretation bases differ. Different schemes, identical spelling, a mapping implementation, or a request for comparison does not establish that relation.

What goes wrong if missed. Teams turn shared labels and convenient mappings into silent equivalence, substitution, structural inference, status transfer, classification under a local system-role kind, or assignment to it. They also mistake evidence about a proposed use, or a polished card, for the relation itself.

What this buys. A reader can see which relation is true, which proposed use is being judged, what evidence supports reliance on that judgement, and whether any downstream act actually happened. Those facts can change independently without silently merging local meanings.

Not this pattern when. Not F.9 when the case is still inside one semantic context, or when the live question is a local system-role kind, assignment occurrence, performed-work attribution, evidence use, status use, source use, publication, assurance, authorization, a gate, a decision, or a mathematical-lens operation. Use the subject pattern for that object; cite F.9 only when cross-context semantic correspondence is also needed.

Recognition versus assurance note. Resolving the endpoint senses and testing the direct Bridge predicate recognizes the semantic relation. A separate C.2.1 claim judges one bounded use. A.10 states whether ordinary evidence reliance passes. When an actual named assurance claim is current, B.3 supplies its bounded result for the same use. None of those steps supplies legal, policy, or deontic authorization.

#Problem frame

Cross-context work fails in predictable ways:

1. String-equals fallacy. Identical spellings such as "process", "role", "accuracy", or "ready" are taken as identical meaning.
2. Relation-to-use jump. A true semantic correspondence is treated as sufficient for whatever comparison, substitution, translation, or publication is wanted next.
3. Design-run jumping. Design artefacts are substituted for run-time occurrences, or run-time occurrences are treated as design definitions.
4. Direction amnesia. A symmetric relation is read as two use licences, or narrower and broader senses are used in the unsafe direction.
5. Loss blindness. The proposed use does not name which differences it tolerates.
6. Evidence and permission collapse. A score, card, or assurance record is treated as the semantic relation, authorization, or proof that the use occurred.

F.9 answers these failures by separating the direct relation, the bounded-use proposition, reliance on that proposition, optional packaging, authorization, and any actual receiving object.

#Problem

A shared label across contexts can look like identity or permission before any semantic relation is tested. Even after a Bridge obtains, its truth does not answer whether one particular comparison or substitution is suitable. The problem is to preserve useful cross-context work while keeping the relation, the proposed use, its evidence, and the downstream act individually testable.

#Forces

#Solution

Start with the two exact local senses, not with a context object, mapping table, or card. Resolve each endpoint as an F.17 SchemeSenseCell coordinate:

<ReferenceScheme by value, LocalExpression, LocalSenseClaim>

For F.9, semantic bounded context is a Plain practice name for the local interpretation basis recovered from one exact cell's <ReferenceScheme, LocalSenseClaim> projection. It is not an entity, relation participant, selected model-use structure, project situation, scope, viewpoint, description, designator, or reference. Two expressions under the same projection remain with ordinary designation and scope operations. Different projections make a Bridge question possible but do not make a Bridge obtain.

When the two cells are from different semantic contexts, declare one relation-semantic BridgePredicateProfile and test it against their current meanings. Shared spelling, different schemes, a mapping implementation, a card, a registry entry, evidence, an assessment score, or publication establishes none of those facts by itself.

#Direct Bridge relation

Bridge is a direct species of U.Relation. Its reusable RelationSignature has exactly two participant meanings:

Only the two endpoint meanings are RelationSignature participants. CL, Loss Notes, U.ClaimScope, an admitted-use qualifier, evidence, counterexamples, policy, time or as-of values, BoundedModelUseStructure, description, Card, publication, registry identifier, form, and carrier are qualifiers or neighboring objects. No proposed-use field, use direction, use-specific rule, permitted-loss tolerance, assertion, or reliance result is a third participant.

The reusable Bridge declaration is one independently constituted C.2.1 episteme whose exact EntityOfConcern is the direct Bridge relation kind. The same declaration episteme is used relation-facing as the compatible RelationSignature; its two SlotSpecs declare participant meanings but create neither endpoint nor occurrence. The relation kind, declaration episteme, RelationSignature use, SlotSpecs, actual cells, obtaining occurrence, assertion, occurrence-description episteme, Card, and publication remain distinct.

An F.9-local BridgePredicateProfile is a by-value predicate declaration, not a U-kind, participant, card, claim, or evaluation result. Direction is stated in the Bridge kind and endpoint orientation when the predicate is asymmetric. Its identity-bearing content is only:

1. the BridgeKind and its kind-defined symmetry or endpoint orientation;
2. the exact source and receiving endpoint-sense readings, including their senseFamily readings where material;
3. the relation-kind-specific congruence, difference, or loss condition, distinct from observed Loss Notes and a proposed use's permitted-loss tolerance;
4. the applicability and as-of basis for testing that condition;
5. the Boolean truth condition; and
6. every stop dependency whose absence prevents a truthful result.

The profile contains no proposed-use field, use direction, use-specific correspondence rule, permitted-loss tolerance, bounded-use proposition, assertion polarity, evidence-reliance classification, assurance claim, authorization, or receiving object.

Bridge(SourceSenseCell, ReceivingSenseCell; BridgePredicateProfile) obtains exactly when:

• both endpoint references resolve to exact F.17 SchemeSenseCell values;
• their semantic-context projections differ;
• the profile applies to those endpoint readings at its stated as-of basis;
• the current endpoint meanings satisfy its kind-specific correspondence or difference condition and Boolean truth condition; and
• every required dependency is present.

If an endpoint is unresolved, the projections are the same, a dependency is missing, or the predicate is false or unresolved, assert no positive occurrence and state the exact exit: ordinary designation, unresolved SenseCell endpoint, same semantic context, missing Bridge dependency, Bridge predicate false, or Bridge predicate unresolved.

Admitted-use qualifier. The Bridge declaration admits this relation only as the semantic-correspondence or semantic-difference premise for a comparison, explanation, translation, naming, or other bounded-use claim. Its nearest non-use is equally explicit: the Bridge alone licenses no substitution and creates no scope result, model-use crossing, local system-role kind, assignment occurrence, Work, evidence authority, status transfer, U-kind admission, publication, or other subject relation. This readable use boundary is a declaration or description qualifier; it is neither a participant nor profile identity and grants no specific use.

Non-optional occurrence identity and recurrence rule. BridgeOccurrenceIdentityRule identifies the occurrence by the exact endpoint cells together with the exact profile. For an asymmetric kind, the ordered source-to-receiving tuple is identity-bearing and an inverse relation requires another profile and directed occurrence. For a symmetric kind, swapping only the readable presentation of the same canonical endpoint pair does not create another occurrence. A changed endpoint or changed relation-semantic profile identifies another candidate.

A Bridge is non-recurrent for one fixed canonical endpoint tuple and exact profile: at most one occurrence has that identity. Repeated tests, assertions, descriptions, Cards, registry rows, or publications neither split nor repeat it. A later applicability or as-of basis changes the profile and therefore opens another occurrence candidate. If a claimed lapse and resumption cannot be represented by an endpoint or profile change, stop at missing Bridge recurrence basis rather than inventing two occurrences with one identity. Changed proposed use, direction, rule, tolerance, evidence path, reliance disposition, assurance claim, Card, registry entry, publication, form, or carrier never reidentifies or recurs the fixed Bridge.

#Judge a bounded use separately

Once exact Bridge b obtains, state the proposed use in ordinary language before introducing FPF terms. Name:

• u: what the reader proposes to compare, substitute, translate, publish, or otherwise do;
• d: the exact source-to-receiving direction for that use;
• r: the use-specific correspondence rule;
• t: the semantic-loss tolerance for that use; and
• whether the claim is affirmative or negative.

The resulting C.2.1 claim asks whether b is suitable for <u,d,r,t>. Its exact EntityOfConcern is b; its ClaimGraph designates u, d, r, t, and polarity; its effective ReferenceScheme makes those designations interpretable. That C.2.1 triple identifies the claim episteme. Changing u, d, r, or t changes the claim, not the Bridge.

An affirmative claim is one premise for the proposed use. It is not a permission, authorization, evidence-provenance relation, reliance classification, assurance claim, decision, or occurrence of that use. A negative claim says that the Bridge is not suitable for the named use; it does not make the Bridge cease to obtain.

For ordinary evidence reliance, recover the exact A.10 evidence-provenance relation and local RelianceDisposition for the same bounded use. Only pass supports reliance on the affirmative claim for that use; degrade supports only its named narrower use, while abstain, reopen, evidence-needed, assurance-needed, or blocked-current-use supplies no passing classification.

Use B.3 only when an actual named assurance claim about the proposed use is current. Require its result for the same bounded assurance use; a non-positive disposition stops or narrows that use. A direct domain rule may require the claim, but the Bridge, display, consequence, or A.10 disposition does not create it.

Neither an A.10 passing disposition nor a B.3 AssuranceResult with disposition=supported-for-use is legal, policy, or deontic authorization. If authorization is needed, recover it under its direct pattern. If a later claim says the use happened, recover the actual Work, assertion episteme, publication occurrence, direct relation, operation application, or other object under its own pattern; the u designation in the ClaimGraph names the proposed use and is not that occurrence.

#Minimal vocabulary

• Semantic context - Plain shorthand for the interpretation basis <ReferenceScheme, LocalSenseClaim> recovered from an exact F.17 cell; it is not a separate entity or participant.
• SchemeSenseCell - the exact F.17 local composite value <ReferenceScheme by value, LocalExpression, LocalSenseClaim>.
• SenseCellAddressRef - an address that resolves one exact SchemeSenseCell; the address is not the cell.
• Bridge - an obtaining direct semantic relation between two exact SchemeSenseCell values from different semantic contexts under one exact profile.
• BridgePredicateProfile - the F.9-local by-value declaration of the direct relation's kind, symmetry or orientation, endpoint readings, correspondence or difference condition, applicability and as-of basis, Boolean truth condition, and stop dependencies.
• Bounded-use claim - an ordinary C.2.1 claim that says whether one exact obtaining Bridge is suitable for one named use, direction, use-specific rule, and loss tolerance. This phrase is descriptive, not a new public kind name.
• Relation orientation - how the Bridge kind orders or symmetrically relates its endpoint slots; it is not a use licence.
• Use direction - the ordered <UseSourceSenseCell, UseReceivingSenseCell> designated inside one bounded-use claim.
• Observed semantic loss - a difference or counterexample found in evidence. It can bear on a bounded-use claim but is not the use's permitted-loss tolerance.
• Permitted-loss tolerance - the maximum named loss accepted by one proposed use; it is content of that use's C.2.1 claim.
• Bridge occurrence description - an independently constituted C.2.1 episteme whose exact EntityOfConcern is one already individuated Bridge occurrence. It describes; it neither makes the predicate true nor supplies occurrence identity.
• Bridge Card - optional claim-bearing packaging. A filled Card may itself be a Bridge description episteme when its C.2.1 triple concerns an actual occurrence; a candidate Card instead modally describes the admitted relation kind and proposed endpoints. The reusable Card layout, registry row, publication form, and carrier remain separate.
• CL (Congruence Level) - optional F.9-local shorthand for the strength of evidence about a stated correspondence. It is neither a participant nor a use threshold and never grants a use.
• senseFamily - the local meaning family used by Part F. A senseFamily label is not a durable U-kind.

#Bridge kinds

A Bridge kind classifies the direct semantic relation tested by a profile. It says what correspondence or difference obtains; it does not settle any proposed use.

#Same-family relation kinds

1. Equivalence - the endpoint senses have the same extension and relevant intension under the stated relation condition. The relation is symmetric and should be rare. A later use still names its direction, rule, and tolerance.
2. Narrower-than - the source sense is properly included in the receiving sense. The relation is asymmetric.
3. Broader-than - the source sense properly includes the receiving sense. The relation is asymmetric.
4. Partial-overlap - the senses have a non-empty intersection, while each has cases excluded by the other. The relation is symmetric.
5. Disjoint - the senses have no common admissible case under the stated readings. The relation is symmetric.

For inclusion, a narrower-to-broader proposed use is usually easier to justify than the reverse, but neither direction follows from the relation alone. A broader-to-narrower proposal normally needs refined endpoint cells and a separately tested Bridge plus a separately warranted bounded-use claim.

#Cross-family relation kinds

These kinds state semantic correspondence across different senseFamily readings. They explain a connection; they do not create substitution, evidence authority, policy force, or a receiving occurrence.

6. Design-spec-to-run-occurrence - a design sense corresponds to a run-time occurrence sense while remaining different in temporal and realization status.
7. Measurement-evidence-for - a measurement sense corresponds to the measured aspect of another sense. The kind is semantic; actual evidential support remains with A.10 or B.3.
8. Policy-constraint-on - a policy or deontic sense corresponds to a constrained behavioral sense. Actual obligation, permission, or authority remains with the policy or deontic governor.
9. Viewpoint-correspondence - a sense used in one view corresponds to a sense used in another view over an EntityOfConcern. View, description, publication, and source-use claims keep their subject patterns.

#Evidence about relation and use

Evidence must answer the question it actually bears on:

CL may summarize evidence strength for a stated correspondence: 0 contradicted, 1 weakly comparable, 2 bounded support with explicit counterexamples, and 3 matched stated invariants with no current material counterexample. It is optional and never serves as a use threshold. A CL=3 label does not make a type-structure use suitable; the separate claim must still name the rule and tolerance, and reliance must still pass under A.10 or B.3.

Observed losses, unit differences, counterexamples, and invariant checks belong in the evidence path or card. The proposed use's permitted-loss tolerance belongs in its ClaimGraph. A loss observation can change without reidentifying either the fixed Bridge or the bounded-use claim; it may instead reopen the claim's polarity or the current reliance disposition.

#Bridge occurrence, description, Card, and publication

Recover and, when needed, individuate the direct relation before describing it. A Bridge may obtain without any assertion, description, Card, registry row, or publication.

A Bridge occurrence description is constituted independently under C.2.1 from exact claim content, the already individuated occurrence as EntityOfConcern, and an effective U.ReferenceScheme. A proposal may instead be a modal C.2.1 episteme whose EntityOfConcern is the admitted direct Bridge relation kind and whose ClaimGraph designates proposed endpoints and profile; it supplies no positive occurrence reference and makes no relation obtain.

Use a Bridge Card only when durable reuse, delayed handoff, evidence review, audit, publication, or costly reversal makes reusable packaging worthwhile. A particular filled Card can be the description episteme when its C.2.1 triple supports that exact use. Its reusable layout remains separate and functions as a publication form only while the exact E.24.PUB PublicationFormExpressionRelation obtains for the selected edition and bounded use. When availability matters, publish one selected description/Card edition through E.24.PUB: its EpistemePublicationRelation occurrence, publication form, and U.PresentationCarrier remain distinct from the selected episteme and from the Bridge.

BridgeCard:
  ClaimMode: actual | candidate | negative
  BridgeOccurrenceRef?: exact ref, actual mode only
  EntityOfConcern: exact obtaining Bridge, or admitted F.9 Bridge relation kind for candidate or negative mode
  ProposedSourceSenseCellRef?: SenseCellAddressRef
  ProposedReceivingSenseCellRef?: SenseCellAddressRef
  ProposedBridgePredicateProfile?: by-value profile
  BoundedUseClaims?: each with u, d, r, t, polarity, and effective ReferenceScheme
  A10EvidenceUse?: exact evidence-provenance relation plus local RelianceDisposition
  B3Use?: exact AssuranceResult for the same bounded assurance use
  ObservedLossAndCounterexamples?:
  EvidenceWarrantAndCurrentness?:
  NearestNonUse?:
  CardReferenceScheme:

For ClaimMode: actual, the description/Card episteme's exact EntityOfConcern is the already individuated Bridge occurrence. It may package the Bridge assertion, one or more bounded-use propositions, their evidence and polarity, the exact A.10 relation and local disposition, or the exact B.3 AssuranceResult when an actual named assurance claim is current, plus currentness and nearest non-use. Its C.2.1 identity is not the occurrence identity.

For ClaimMode: candidate or negative, no positive occurrence reference exists. The modal description/Card episteme's EntityOfConcern is the admitted F.9 direct Bridge relation kind; its ClaimGraph designates the proposed endpoints and profile. candidate says the proposed Bridge may obtain; negative says its predicate does not obtain. Any bounded-use proposition in the same graph keeps its own polarity. Completing, approving, registering, or publishing the description/Card creates no Bridge.

The exact <ClaimGraph, EntityOfConcern, effective ReferenceScheme> triple identifies each description/Card episteme. A changed description or Card edition, evidence path, reliance disposition, B.3 AssuranceResult, registry record, E.24.PUB publication occurrence, publication form, carrier, or layout does not reidentify a fixed Bridge. Publish only the selected description/Card edition needed by the named audience and bounded use; publication changes availability, not relation truth.

#Boundary to coarsening and quantum-like export

Open F.9 when a receiving use needs an actual semantic relation between exact local senses. A lossy or approximate export is not thereby a Bridge, and an actual Bridge is not thereby a quantum-like state transition.

Use this order:

1. resolve the exact F.17 cells, state the relation-semantic profile, and test whether the Bridge obtains;
2. state the proposed use separately as <u,d,r,t> and give the C.2.1 claim its polarity;
3. recover the exact A.10 evidence-provenance relation and local disposition or, when an actual named assurance claim is current, its B.3 AssuranceResult for the same use;
4. if the use happened, identify the actual governed object and apply its subject pattern;
5. add a Bridge Card only if durable packaging pays;
6. open A.6.3.CSC, C.26.1, or C.26.2 only when coarsening, probe effects, or failure of any faithful-enough report is the live question.

When a state, metric, option, causal reading, or viability claim crosses the semantic boundary, its subject pattern states what survives and what is lost. The Bridge supplies only the semantic-correspondence premise; the bounded-use claim supplies only the named suitability proposition.

#Invariants

1. Exact endpoints first. A Bridge has exactly two F.17 SchemeSenseCell participants.
2. No context object. Semantic context is recovered from endpoint content and is not a relation participant.
3. Different context is not enough. Different projections trigger the question but do not establish the relation.
4. Profile contains relation semantics only. Receiving use, direction, use rule, loss tolerance, polarity, reliance, authorization, and receiving objects are absent from profile identity.
5. Obtaining before occurrence reference. A positive Bridge reference appears only after the fixed predicate is true and its dependencies are present.
6. Use claim is separate. Every proposed use names u, d, r, t, and polarity in a C.2.1 claim about the exact Bridge.
7. Reliance is separate. A.10 says whether ordinary evidence supports relying on the bounded-use claim. When an actual named assurance claim is current, B.3 supplies its bounded AssuranceResult. Neither answer comes from F.9 or the Card.
8. Proposed use is not an occurrence. The u designation in the ClaimGraph names the proposed use; any actual Work, assertion, publication, relation, or operation application keeps its own identity; apply the relevant pattern to each claim about it.
9. Card separation. Card identity, completion, approval, registration, and publication neither make the relation obtain nor make the use happen.
10. Loss separation. Observed semantic loss is evidence; permitted loss is tolerance inside the bounded-use claim.
11. No authorization by implication. Semantic suitability, evidence reliance, and assurance are not legal, policy, or deontic permission.
12. No silent inverse or composition. An inverse asymmetric relation and any direct A-to-C relation are tested independently.
13. Two-SlotSpec declaration. The reusable RelationSignature declares only source and receiving SenseCell participant meanings; CL, Loss Notes, scope/admitted use, evidence, counterexamples, policy, time, model-use structure, description, publication, and registry values remain qualifiers or neighbors.
14. Recurrence and identity. The non-optional identity rule uses the canonical exact endpoints and exact profile; one fixed tuple/profile is non-recurrent, and a changed applicability/as-of basis changes the profile before another candidate is admitted.
15. Description and publication separation. A Bridge description/Card is independently constituted under C.2.1, and E.24.PUB independently governs any selected edition's publication occurrence, form, and carrier. None establishes relation truth or identity.

#Micro-examples

The labels below are readable aliases. An actual case resolves exact F.17 cells and tests one profile before stating a proposed use.

1. Participant versus Agent. A Partial-overlap Bridge may obtain between the exact BPMN and PROV senses. A separate claim may affirm use of the label "actor" in one orientation table under a rule that preserves the stated participation distinction. That claim creates no local system-role kind or assignment occurrence.
2. Process design versus Activity occurrence. A Design-spec-to-run-occurrence Bridge may explain the semantic connection. A separate claim can bound an explanatory use; it does not identify a run occurrence from a design artefact.
3. Observation versus SLO fulfilment. A Measurement-evidence-for Bridge can relate the exact senses. A separate claim asks whether the observation sense is suitable for interpreting one named SLO comparison. A.10 handles ordinary evidence reliance; when an actual named assurance claim is current, B.3 supplies its bounded result for that use.
4. Subtype across OWL and a curated taxonomy. An Equivalence Bridge obtains only under a profile whose relation condition includes the required class-level invariants. A separate claim asks whether one exact type-structure row may use that Bridge under its stated rule and zero material-loss tolerance.
5. Accuracy in metrology versus data quality. A Partial-overlap Bridge can make the shared word intelligible. A bounded-use claim may affirm that the label is suitable in one explanatory table while rejecting transfer of measurement methods or values.

#Worked examples

#Service target and monitoring observation

A service team resolves two exact cells: the ITIL sense of an availability target and the SOSA sense of an availability observation. Profile P-SLO-OBS-v2 states a Measurement-evidence-for semantic relation: the observation sense concerns a measured availability quantity relevant to the target sense, while observation and target remain different kinds of claim. The profile names the endpoint readings, direction of the semantic relation, applicability to the cited editions, Boolean condition, and required quantity-definition dependency. Current meanings satisfy it, so Bridge b-slo-obs obtains.

The team next proposes use u-slo-check: compare one observation result with the target. Direction d-slo is observation-to-target; rule r-slo requires the same quantity kind, aligned windows, and the stated unit conversion; tolerance t-slo permits the named rounding loss but no quantity-kind change. A C.2.1 claim with EntityOfConcern b-slo-obs states affirmative polarity for <u-slo-check,d-slo,r-slo,t-slo>.

Because this is an ordinary bounded evidence use and no assurance claim is made, the team recovers the exact A.10 evidence-provenance relation for the observation record and states RelianceDisposition=pass only for u-slo-check. That supports reliance within its boundary. It does not make the SLO fulfilled, authorize acceptance, or prove that comparison Work occurred.

#Behavioral participant and access role

An exact Partial-overlap Bridge obtains between a BPMN participant sense and a named RBAC role sense when the profile's overlap and difference conditions are satisfied. A separate bounded-use claim proposes the label "actor" for one glossary row, in the stated direction, under a rule that preserves assignment moment, enforcement locus, multiplicity, and accountability differences, with zero tolerance for reading the label as a local system-role kind or assignment occurrence. Current evidence can support that label use under A.10.

When a later claim uses the RBAC source word role, apply E.10.ROLE and first say whether it concerns access, permission, authority, a work-facing classification, an assignment, or performed Work. For access, permission, or authority, use the direct pattern for that relation. Use A.2.8.PER for granted permission while keeping actual access separate. If access wording still hides the subject or relation, use A.6.P:4.11a; if the participants and predicate are clear but no direct pattern defines the relation, return A.6.RCD missing-governor[direct access relation].

A work-facing classification separately requires an admitted System, one exact local system-role kind with its KindSignature, and the C.3.2 classification judgment under A.2 and C.3. Use F.4 only when the receiving use separately needs a SystemRoleKindDescription episteme, and F.5 only when it needs a durable designation. An assignment claim then separately identifies an occurrence of a directly declared species under U.SystemRoleAssignment through A.2.1.

If performed Work is also claimed, recover every exact actual performer through A.13 and use A.15.1 to identify the dated Work, exact Method, time, and containing System independently. Add an assignment occurrence and F.6 only when the Bridge account or receiving use expressly represents precise assignment-bound attribution and can supply the direct case fact linking the exact Work-assignment pair. Missing or failed F.6 leaves the Work intact. The Bridge, bounded-use claim, and reliance result establish none of these facts.

#Subtype notions in one structural row

The endpoint senses are OWL2:SubClassOf under a cited OWL profile and curated-taxonomy is-a under one named taxonomy edition. The Bridge profile states Equivalence and makes its direct relation predicate true only when both endpoint meanings use compatible class-level reasoning and satisfy the stated acyclicity and anti-symmetry conditions. When those facts and dependencies are current, the exact Bridge obtains.

A second premise is still required. The C.2.1 claim names the proposed type-structure row, its source-to-receiving direction, the rule that preserves the three invariants, and zero material-loss tolerance. Only an affirmative current claim with passing A.10 reliance, or, when an actual named assurance claim is current, a B.3 AssuranceResult for the same use with disposition=supported-for-use, supports relying on the row. A contradicted relation invariant makes the Bridge predicate false; a use-specific tolerance failure can instead make the bounded-use claim negative while the Bridge remains unchanged.

#Setpoint versus service target

CTRL:setpoint and ITIL:target share a familiar word but usually have only Partial-overlap or are Disjoint under the exact readings. A proposed substitution in a control calculation receives a negative bounded-use claim because its rule and tolerance cannot preserve the physical-reference meaning. A didactic comparison may receive a different affirmative claim. Neither claim changes which Bridge obtains.

#Common Anti-Patterns and How to Avoid Them

#Reasoning primitives

These are conceptual judgements, not work-enactment, card-completion, registry, publication, permission, or authorization rules.

#Direct Bridge occurrence

P = <kind, symmetry-or-orientation, endpoint-readings,
     relation-condition, applicability-and-as-of,
     Boolean-truth-condition, stop-dependencies>

Bridge(A, B; P) obtains
iff
  A and B resolve to exact F.17 SchemeSenseCell values,
  semanticContext(A) != semanticContext(B),
  applicable(P, A, B, asOfBasis),
  bridgePredicate(P, A, B) = true,
  and requiredDependencies(P) are present.

No proposed use, direction, use-specific rule, loss tolerance, claim polarity, reliance result, or card is a component of P.

#Bounded-use proposition

Bridge(A,B;P) obtains as b
and C is a C.2.1 claim with
  EntityOfConcern = b,
  ClaimGraph designating <u,d,r,t,polarity>,
  and an effective ReferenceScheme interpreting those designations
=> C says whether b is suitable for exactly <u,d,r,t>.

Changing u, d, r, or t changes C; it does not change b. Affirmative polarity is not evidence reliance, assurance, authorization, or occurrence.

#Ordinary A.10 reliance

C is current and affirmative for <u,d,r,t>
and EP is the exact A.10 evidence-provenance graph relation for C and u
and RelianceDisposition(EP,u,d,r,t) = pass
=> the reader may rely on C only for that bounded evidence use.

A non-passing or narrower disposition supplies no support for the attempted use. The disposition is a local A.10 classification statement, not a new result kind.

#B.3 assurance branch

C is current and affirmative for <u,d,r,t>
and an actual named assurance claim about this use is current
and its B.3 AssuranceResult carries the same bounded assurance use
and disposition = supported-for-use
=> assurance supports only that bounded use.

A narrowed disposition supports only its stated narrower use. abstain, evidence-needed, reopen, or blocked stops the attempted use. If no assurance claim is current, do not open B.3. A consequence, display, or local threshold creates no assurance claim.

#Receiving occurrence stays separate

Bridge b obtains
and C is affirmative for proposed use u
and current reliance supports C for u
=> no Work, assertion, publication, relation, or operation application follows.

An actual receiving object exists only when its subject pattern supplies its participants or arguments, obtaining or performance facts, and identity.

#Direction guard

Relation symmetry or orientation does not select d. Each proposed direction receives its own bounded-use claim. For an inclusion relation, a broader-to-narrower proposal normally requires refined endpoint senses and a separately tested Bridge; it cannot borrow safety from the inverse reading.

#Chained-use guard

Bridge(A,B;P1) obtains
and Bridge(B,C;P2) obtains
=> no Bridge(A,C;P3) follows.

A composite proposed use must cite each obtaining Bridge, state one exact composite rule and accumulated tolerance in its own claim, and recover current reliance for that claim. If a direct A-to-C correspondence is needed, test it independently.

#Candidate-card guard

candidate or negative Bridge Card exists
=> no positive Bridge occurrence follows.

The card concerns the admitted direct Bridge relation kind and places proposed endpoints, profile, ClaimMode, and polarity in its ClaimGraph. It creates neither relation nor receiving occurrence.

#Relations

Builds on: F.17, F.18, C.2.1, F.0.1, F.7, and F.8.

Coordinates with:

• A.10. Use it for the exact evidence-provenance graph relation and local RelianceDisposition for ordinary bounded evidence use.
• B.3. Use B.3 only after an actual named assurance claim is current; it states the bounded AssuranceResult or non-positive disposition and does not create the claim, authorization, or use.
• E.10.ROLE, A.2, C.3, F.4, F.5, A.13, A.15.1, A.2.1, and F.6. Use E.10.ROLE first when source wording leaves role ambiguous. Use A.2 and C.3 for the local system-role kind and any separate System-classification judgment. Use F.4 only when a description of that kind is current, and F.5 only when its durable naming is current. Recover each exact actual performer through A.13 and admit dated Work independently through A.15.1. Use A.2.1 and F.6 only when the receiving Bridge use expressly consumes precise assignment-bound attribution. A Bridge establishes none of these facts.
• F.8. A mint-or-reuse decision may consume an obtaining Bridge plus a separately warranted bounded-use claim; it does not strengthen either.
• A.2.6. Scope translation may use an obtaining Bridge only together with an affirmative claim naming the exact direction, scope-correspondence rule, and loss tolerance. Use A.2.6 for the translated scope and membership.
• A.6.1. Use it to identify any actual operation application. The u designation in a Bridge claim names a proposed use and is not an application binding.
• A.6.5. Relation-position labels and SlotSpec claims remain governed by slot discipline.
• C.29. Mathematical-lens use may cite a Bridge and bounded-use claim; C.29 still governs its mathematical object, preserved and lost structure, and actual lens use.
• C.34. Structural correspondence or morphism adequacy may cite an obtaining Bridge and a bounded-use claim but states its own preserved and lost architecture structure.
• A.6.REL. Applies the F.9 recurrence and occurrence-identity rule only when a receiver must distinguish or reference the occurrence.
• C.2.1. Independently constitutes assertions, modal proposals, occurrence-description epistemes, and filled Cards; none supplies the Bridge predicate or occurrence identity.
• E.24.PUB. Use it for any EpistemePublicationRelation occurrence, publication form, and presentation carrier for a selected description/Card edition. Publishing creates neither Bridge nor receiving use.
• A.6.3.CSC, C.26.1, and C.26.2. Govern coarsening, probe effects, and no-faithful-enough-report cases when those questions are live.

#Revision law

1. Endpoint change. A changed by-value scheme, local expression, or local-sense claim identifies another F.17 cell and requires another Bridge test.
2. Profile change. A changed kind, symmetry or orientation, endpoint reading, relation-specific correspondence or difference condition, applicability or as-of basis, Boolean truth condition, or stop dependency identifies another profile and occurrence candidate.
3. Use-content change. A changed proposed use u, direction, use-specific rule, or permitted-loss tolerance identifies another C.2.1 claim while the fixed Bridge remains unchanged.
4. Polarity change. Affirmative versus negative is changed claim content; it is not a changed reliance disposition.
5. Evidence or reliance change. A changed evidence item, path, currentness window, A.10 relation, local RelianceDisposition, or B.3 AssuranceResult reopens reliance without reidentifying the fixed Bridge or fixed C.2.1 claim.
6. Obtaining change. New endpoint facts may establish, refute, or leave unresolved the predicate for a fixed occurrence candidate without silently changing its identity.
7. Description, Card, registry, or publication change. Apply C.2.1 to description/Card identity and E.24.PUB to publication occurrence, form, and carrier; none creates, removes, reidentifies, or recurs the Bridge.
8. Receiving occurrence change. Reidentify or revise the Work, assertion, publication, relation, application, or other receiving object under its subject pattern.

#Acceptance tests

#Static conformance

• SCR-F9-S01 (Well-typed direct relation). Each actual Bridge has exactly two resolved F.17 SchemeSenseCell endpoints and one exact relation-semantic profile.
• SCR-F9-S02 (Different semantic contexts). The endpoint <ReferenceScheme, LocalSenseClaim> projections differ; same-context aliases stay with designation resolution.
• SCR-F9-S03 (Profile boundary). The profile contains only kind, symmetry or orientation, endpoint readings, relation condition, applicability and as-of basis, Boolean truth condition, and stop dependencies.
• SCR-F9-S04 (Obtaining). Current endpoint facts satisfy the exact profile and all required dependencies are present. Scheme difference, spelling, implementation, evidence score, card, registry, or publication alone fails this test.
• SCR-F9-S05 (Separate bounded use). Every use claim identifies exact Bridge b, names u, d, r, t, polarity, and an effective ReferenceScheme under C.2.1.
• SCR-F9-S06 (Reliance branch). The same bounded use has the exact A.10 relation plus a passing local disposition or, when an actual named assurance claim is current, its exact B.3 AssuranceResult; only supported-for-use supports the attempted assurance use, while narrowed supports only its stated narrower use.
• SCR-F9-S07 (No authorization overread). Semantic fit, A.10 reliance, and B.3 assurance are not described as legal, policy, or deontic permission.
• SCR-F9-S08 (Receiving-object boundary). A named proposed use is never treated as performed Work, assertion, publication, relation, or operation application.
• SCR-F9-S09 (Card truthfulness). An actual card concerns an already individuated occurrence; a candidate or negative card concerns the admitted relation kind and has no positive occurrence ref.
• SCR-F9-S10 (Plain action). A practitioner can tell what relation to test, what use is proposed, what would stop reliance, and which downstream claim still needs an applicable pattern.
• SCR-F9-S11 (Non-optional identity and recurrence). The declaration states BridgeOccurrenceIdentityRule, asymmetric ordering or symmetric canonicalization, and the non-recurrence of one fixed endpoint/profile tuple; a later basis changes the profile before another candidate is admitted.
• SCR-F9-S12 (Description and publication boundary). Every actual description/Card concerns an already individuated occurrence under C.2.1; every modal proposal has no positive occurrence ref; E.24.PUB publication, form, carrier, and registry identity establish neither.
• SCR-F9-S13 (No adjacent fact by Bridge). No Bridge creates a local system-role kind or assignment, Work, evidence authority, status transfer, U-kind admission, publication, model-use crossing, or another subject relation.

#Regression checks

• RSCR-F9-E01 (Same Bridge, changed use). Reversing direction, changing the use rule, or changing tolerance reidentifies the C.2.1 claim, not the Bridge.
• RSCR-F9-E02 (Same claim, changed evidence). Stale or stronger evidence changes the A.10 relation or disposition, or the B.3 branch, without reidentifying the fixed claim.
• RSCR-F9-E03 (Required but missing assurance claim). If a direct domain rule requires an assurance claim and none is current, return RelianceDisposition=assurance-needed or block the use. Do not manufacture a positive claim or a generic safety-case record.
• RSCR-F9-E04 (Profile change). A changed relation condition or endpoint reading identifies another profile and occurrence candidate.
• RSCR-F9-E05 (Packaging change). A changed card, registry entry, publication, form, or carrier leaves the Bridge and fixed bounded-use claim unchanged unless their own discriminators changed.
• RSCR-F9-E06 (Positive proposal versus occurrence). An affirmative claim with passing reliance proves no comparison Work, assertion, publication, direct relation, or operation application.
• RSCR-F9-E07 (Polarity versus reliance). Negative claim polarity and a non-passing reliance disposition remain different facts.
• RSCR-F9-E08 (Reliance versus authorization). A.10 pass or B.3 supported-for-use does not imply permission.
• RSCR-F9-E09 (No inverse or composition). Neither an asymmetric inverse nor a direct A-to-C Bridge follows without its own profile and obtaining test.

#Didactic distillation

Use this five-part script:

1. Find the two exact local senses.
2. Say what semantic relation holds and test whether that Bridge obtains.
3. State the proposed use separately: action, direction, rule, tolerated loss, and polarity.
4. Check whether current evidence or assurance supports relying on that claim; recover authorization separately if needed.
5. If the use happened, identify the actual object and apply the relevant pattern to the claim about it. Make a card only when reuse is worth the maintenance.

The short memory aid is: relation first, use second, reliance third, receiving occurrence last; packaging is optional.

#Archetypal Grounding

#Tell

A Bridge is an actual semantic relation, not a synonym claim or enactment edge. Its profile says what correspondence holds. A separate claim says whether that relation suits one proposed use. Evidence, authorization, packaging, and actual performance remain separate.

#Show: service lane

The observation sense can bear a semantic relation to the target sense without being the target status. The team then states and warrants one comparison use; status and acceptance remain separate claims.

#Show: access-control lane

A process team and an access-control team both use operator. An obtaining overlap Bridge plus an affirmative, warranted label-use claim can support one glossary row. It establishes no access, permission, authority, local system-role kind, assignment, performer, or Work. Recover whichever fact is actually claimed under its direct pattern; preserve the source term access-control role only when referring to the external scheme.

#Show: episteme lane

An actual card can package the relation claim, bounded-use claim, evidence path, and reliance disposition. It remains an episteme about the Bridge and creates neither the relation nor the receiving act.

#Bias-Annotation

Lenses tested: governance, architecture, ontology and episteme, pragmatics, didactics. Scope: universal for cross-context correspondence and reuse.

• Governance bias. The pattern adds a separate use claim and reliance check. Mitigation: keep them in ordinary sentences when durable packaging has no payoff.
• Architecture bias. Typed relation profiles can look heavier than synonym prose. Mitigation: the five-part script begins with the practical action and introduces exact terms only where they stop a real overread.
• Ontology and episteme bias. F.9 resists global meaning claims and keeps claims separate from their subject. Mitigation: explicit Bridges still permit practical cross-context comparison.
• Pragmatic bias. Conservative separation can feel slower than reusing a mapping table. Mitigation: a fixed Bridge can support many independently stated uses without being reidentified.
• Didactic bias. The four-object split can become bureaucratic if written only in internal nouns. Mitigation: every use starts by saying what a person will do, what rule they will follow, and what result would make them stop.

#Conformance Checklist

An F.9 use conforms iff:

1. both endpoints resolve to exact F.17 SchemeSenseCell values;
2. their semantic-context projections differ;
3. the Bridge has exactly two participants and one relation-semantic profile;
4. the profile contains no receiving-use or reliance content;
5. the profile applies, its Boolean predicate is true, and its dependencies are present before a positive occurrence is cited;
6. every proposed use is a separate C.2.1 claim naming u, d, r, t, polarity, and effective scheme;
7. observed loss stays in evidence while permitted loss stays in the bounded-use claim;
8. current ordinary reliance uses the exact A.10 branch for the same bounded use; when an actual named assurance claim is current, use its exact B.3 AssuranceResult;
9. no reliance or assurance statement is read as authorization;
10. any actual receiving object is recovered under its subject pattern;
11. description episteme, Card, registry record, E.24.PUB publication occurrence, form, and carrier remain distinct from Bridge occurrence and receiving-use occurrence;
12. inverse and composed relations are tested independently;
13. the reusable RelationSignature declares only two endpoint SlotSpecs, while every CL, Loss Note, scope/admitted-use, evidence, counterexample, policy, time, model-use, description, publication, or registry value remains a qualifier or neighbor;
14. the non-optional occurrence identity and non-recurrence rule is stated and applied before a Bridge occurrence is referenced; and
15. same-context designation remains outside F.9; claim-bearing source wording with role first uses E.10.ROLE, and each recovered system-role kind, assignment, access, permission, authority, Work, evidence-authority, status, U-kind, publication, structure-crossing, or other subject claim returns to its direct pattern.

#Consequences

Benefits. F.9 permits comparison, translation, and bounded reuse without collapsing local senses. One stable Bridge can support several differently directed or differently tolerant use claims, and evidence can change without silently changing relation identity.

Costs. A reader must state two premises instead of one: the semantic relation and the bounded-use proposition. Ordinary evidence reliance may require A.10 work. An actual named assurance claim additionally requires a B.3 result. This cost is paid only when a real cross-context use is proposed; a Card remains optional.

Failure mode avoided. A Bridge, score, or card can no longer act as a quiet substitute for a local system-role kind or assignment, status transfer, evidence authority, authorization, publication, or performed-work attribution.

#Rationale

Cross-context comparison is unavoidable, but the truth of a semantic relation and the suitability of one action are different claims. Putting direction, a use rule, and tolerated loss into BridgePredicateProfile would reidentify the relation whenever the proposed use changed. Putting them in a separate C.2.1 claim lets one Bridge remain fixed while several uses are affirmed, rejected, narrowed, or reopened independently.

The same separation keeps evidence honest. A.10 or B.3 can reopen reliance without erasing the relation. A card can travel without becoming the relation. A proposed use can be warranted without being authorized or performed. These boundaries preserve practical reuse and make each failure local and repairable.

#SoTA-Echoing